CODEWITHSUNDEEP
clojurenanequality
Sam Estep
Sam Estep

Reputation: 13304

Is it expected that identity returns something different from its argument?

Here is an example where calling identity changes the returned value, which seems to me to indicate that the docstring "Returns its argument." isn't entirely true:

(let [x Double/NaN] (identical? x x)) ;=> false
(let [x (identity Double/NaN)] (identical? x x)) ;=> true

Is this expected? Or is it a bug with the identity function somehow?

Upvotes: 5

Views: 155

Answers (3)

Thumbnail
Thumbnail

Reputation: 13473

Does identity "return its argument"?

It depends what you mean by the argument.

  • If it is the evaluated expression in the function call form, then not always.
  • If it is what the body of the function sees on the stack upon entry, then yes, it does.

The anomaly arises because of the way that Clojure calls functions.

  • Clojure functions are objects that comply with the IFn interface.
  • A Clojure function call translates into one of the many invoke methods - overloaded for arity - of the function object.
  • All of the invoke methods have Object parameters.

The upshot of all this is that every Clojure function call translates its every argument into some kind of Object - an identity operation except on primitives, which are wrapped in the corresponding Java class: long into Long, and so on.

So even the identity function, essentially (defn identity [x] x), does not return a primitive argument. It can't, because it never sees it.

For example, let's consider the expression 

(inc 3)

The number 3 is surely a long. What type is (inc 3)? Let's ask Clojure:

(type (inc 3))
=> java.lang.Long

... a boxed Long object.

Hang on, are we sure that 3 is a primitive long?: 

(type 3)
=> java.lang.Long

Aaaaaaagh! It's boxed too!

Not necessarily! You can't tell, because by the time the body of type sees 3, it is boxed, whether or not it was so to the reader/compiler. The Clojure documentation is silent on the point. It just says that numeric literals are generally represented as per Java.

So - in general - it's the evaluation mechanism, not a particular function (such as identity) that's responsible for boxing primitive arguments. This is auto-boxing.

What your example shows is that primitives are held as such, un-boxed, at least in let forms:

(let [x 1.0] (identical? x x)) ;=> false
(let [x (identity 1.0)] (identical? x x)) ;=> true

The fact that identical? is able to distinguish between the two boxings of 1.0 shows that it is held as a primitive double. (I've used an ordinary double, just to show that the behaviour is nothing to do with the special value Double/NaN).

Now let's try putting the number in a var:

(def x 1.0)

(identical? x x) ;=> true
(let [x (identity x)] (identical? x x)) ;=> true

It's boxed.

While we're here, auto-boxing is idempotent:

(identical? x (identity x)) ;=> true

The above adds little to what Alan Thompson's and Josh's answers and Alan Malloy's and Lee's comments comprise. I just felt they had hooked and played the fish, without actually landing it.

Upvotes: 0

Alan Thompson
Alan Thompson

Reputation: 29958

You appear to have found an edge case involving identity, identical?, and primitive vs object equality. Note that in Java, java.lang.Double/NaN is a primitive:

public static final double NaN

But identical compares Java Objects:

; clojure.core
(defn identical?
  "Tests if 2 arguments are the same object"
  {:inline (fn [x y] `(. clojure.lang.Util identical ~x ~y))
   :inline-arities #{2}
   :added "1.0"}
  ([x y] (clojure.lang.Util/identical x y)))

// clojure/lang/Util.java
static public boolean identical(Object k1, Object k2){
    return k1 == k2;
}

Try this trick to force the NaN into a Double object instead of an unboxed primitive:

tupelo.core=> (let [x (Double. Double/NaN)] 
  (spyxx x) 
  (identical? x x))

x => java.lang.Double->NaN
true

I suspect that autoboxing of the primitive NaN which may/may not occur with different use-cases is the cause of the differences you are seeing.

Upvotes: 8

Josh
Josh

Reputation: 4806

To add a little color to Alan's answer on boxing:

You may want to look into the == function, which is implemented this way:

public boolean equiv(Number x, Number y){
    return x.doubleValue() == y.doubleValue();
}

This performs a primitive comparison of two actual doubles. Your example, with ==:

(let [x (identity Double/NaN)] (== x x))
=> false
(let [x (identity Double/POSITIVE_INFINITY)] (== x x))
=> true

What's going on? Why is NaN == NaN false? Well, a primitive comparison using == should actually return false for NaN. It's strangely specified this way in IEEE 754 and Java behaves this way. It's the only "number" which, when compared to itself, does not equal itself.

As an aside, to see how object equality can be a strange thing in Java, see this:

(identical? 127 127)
=> true
(identical? 128 128)
=> false

This is because java caches the first 2^8 unsigned ints, so the 127s being compared are the same object in the first example, but the 128s in the second example are different objects. So, there are some gotchas to be aware of with checking for equality!

But the main takeaway here is: identity is working as it should! Just be careful when comparing things, as the notion of "equality" is not so straightforward!

Upvotes: 3

Related Questions