== is not transitive?

[Ben Wolfson]

user> [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)]
[true true false]
user> [(== 0 0.0 0.0M) (== 0 0.0M 0.0) (== 0.0 0 0.0M) (== 0.0 0.0M 0)
(== 0.0M 0.0 0) (== 0.0M 0 0.0)]
[true false false false true false]

--
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure." [Larousse, "Drink" entry]

[JvJ]

The only reason for this that I can think of is incomplete rules for casting numbers.

[Jean Niklas L'orange]

On Friday, October 5, 2012 2:39:05 AM UTC+2, Ben wrote:

user> [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)]
[true true false]

When passing two arguments to ==, == will be transitive.

 

user> [(== 0 0.0 0.0M) (== 0 0.0M 0.0) (== 0.0 0 0.0M) (== 0.0 0.0M 0)
(== 0.0M 0.0 0) (== 0.0M 0 0.0)]
[true false false false true false]

This is more of a problem with number equality, not the transitivity of ==. (== x1 x2 x3 ... xn) can be rewritten as (and (== x1 x2) (== x2 x3) ... (== xn-1 xn)). 

So if you compare (== x y z), then if x = y, then the result of (== x z) and (== y z) should be equivalent, considering the numbers are, well, numbers.

I believe the issue lies within the bigdec-parsing, which seems to have two zeroes: (== 0M 0.0M) returns false, and their hashcode (0 and 1, respectively) are different.

 

[Ben Smith-Mannschott]

Yea, I think this is the peculiar definition of BigDecimal.equals()
biting us here.

http://docs.oracle.com/javase/1.4.2/docs/api/java/math/BigDecimal.html

# Note: care should be exercised if BigDecimals are to be used as keys in a
# SortedMap or elements in a SortedSet, as BigDecimal's natural ordering is
# inconsistent with equals. See Comparable, SortedMap or SortedSet for more
# information.

equals():
# Compares this BigDecimal with the specified Object for equality. Unlike
# compareTo, this method considers two BigDecimals equal only if they are
# equal in *value* and *scale* (thus 2.0 is not equal to 2.00 when compared by
# this method)

[Patrick Houk]

I was bitten by this a year ago and posted here:
http://groups.google.com/group/clojure/browse_frm/thread/9091ad790fc96b24

My workaround is to call BigDecimal#stripTrailingZeros before passing
it to code that might compare it to some other number.

user> (== 1 (.stripTrailingZeros 1.0M))
true

However, there is an edge case:

user> (== 0 (.stripTrailingZeros 0.0M))
false

Which is due to this Java bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6480539

So I use a function like the following instead of bigdec to parse
BigDecimals.

(defn parse-stripped-bigdec [^String value-str]
;; Note that bigdec uses reflection (at least in Clojure 1.2.1)
(let [n (java.math.BigDecimal. value-str)]
(if (zero? n) 0M (.stripTrailingZeros n))))

Be aware that stripping the zeros changes how the BigDecimal is
formatted by #toString.

user> (str (parse-stripped-bigdec "10"))
"1E+1"

So, I have a special case for BigDecimal that calls #toPlainString in
the places where I do not want exponential format.

user> (.toPlainString (parse-stripped-bigdec "10"))
"10"

I hope that helps.
- Pat

[Ben Wolfson]

On Fri, Oct 5, 2012 at 2:08 AM, Jean Niklas L'orange
<jean...@hypirion.com> wrote:
>
> On Friday, October 5, 2012 2:39:05 AM UTC+2, Ben wrote:
>>
>> user> [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)]
>> [true true false]
>
> When passing two arguments to ==, == will be transitive.

I'm not sure what you mean by this. Transitivity means that for all x,
y, and z, (Fxy & Fyz) => Fxz. But there are values of x, y, and z for
which that does not hold.

[Jean Niklas L'orange]

On Friday, October 5, 2012 7:17:50 PM UTC+2, Ben wrote:

I'm not sure what you mean by this. Transitivity means that for all x,
y, and z, (Fxy & Fyz) => Fxz. But there are values of x, y, and z for
which that does not hold.

Yeah, sorry. What I meant was that == is only commutative if you pass it two arguments as of right now.