Mike, the equiv method that was shown was what Clojure does if it compares
a BigDecimal value with any other numeric type, except if the BigDecimal
value is compared with a Double. Between a BigDecimal and a Double it
converts the BigDecimal to a Double before comparing.
Check out Numbers.java in
On Wednesday, 4 September 2013 13:19:16 UTC+8, Mikera wrote:
> On Friday, 2 August 2013 12:28:51 UTC+8, CGAT wrote:
>
>> My understanding of == is that it is intended to establish numerical
>> equivalence
>> across types. But I think that basic contract fails with BigDecimal.
>> For instance
On Friday, 2 August 2013 12:28:51 UTC+8, CGAT wrote:
> My understanding of == is that it is intended to establish numerical
> equivalence
> across types. But I think that basic contract fails with BigDecimal. For
> instance,
>
> (== 1M 1.0M) ; => false
>
> because the scale properties of
Thanks for the experience report. I've copied it into the ticket's
description along with a link to this discussion.
If you have an account on JIRA, you can vote for the ticket. More votes
might get the ticket some attention earlier than fewer votes. If you don't
already have one, you can creat
It'd be great if this got fixed - we met an ugly bug yesterday due to this
on our project.
(Our system validates that the sum of two monetary fields A and B equals
the sum of two monetary fields C and D. We parse the fields via Cheshire
with conversion to bigdecimal turned on - but any fields wit
Terrific, Andy, thanks. I will definitely take a look.
On Friday, August 2, 2013 1:16:14 AM UTC-4, Andy Fingerhut wrote:
>
> I agree, which is why I wrote a patch for the ticket
> http://dev.clojure.org/jira/browse/CLJ-1118
>
> (Depending on when you read this, dev.clojure.org may not be accessib
You can also see the patch at this link, in case it is a while before JIRA
is back up:
https://github.com/jafingerhut/clj-prescreen/blob/master/eval-results/2013-08-01/ticket-info/CLJ-1118-attachments/clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v3.txt
On Thu, Aug 1, 2013 at 10:16
I agree, which is why I wrote a patch for the ticket
http://dev.clojure.org/jira/browse/CLJ-1118
(Depending on when you read this, dev.clojure.org may not be accessible due
to a recent DNS update made by the Clojure folks. Wait a while and try
again.)
It makes not only the change you suggest, bu
My understanding of == is that it is intended to establish numerical
equivalence
across types. But I think that basic contract fails with BigDecimal. For
instance,
(== 1M 1.0M) ; => false
because the scale properties of these numbers are different. So then of
course:
[(== 1 1N 1.0)
