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 the Clojure source code for yourself, but it is
probably already doing what you are hoping, or at least close to it.
Andy
On Tue, Sep 3, 2013 at 10:19 PM, Mikera <mike.r.anderson...@gmail.com>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,
>>
>> (== 1M 1.0M) ; => false
>>
>> because the scale properties of these numbers are different. So then of
>> course:
>>
>> [(== 1 1N 1.0) (== 1 1N 1.0 1M) (== 1 1N 1.0 1.0M) (== 1 1.0 1N 1.0M)]
>> ; => [true true true false]
>> and
>> [(== 1.0M 1.0) (== 1.0 1) (== 1 1N) (== 1N 1.0M)]
>> ; => [true true true false]
>>
>> I find your lack of transitivity (and commutativity) ... disturbing.
>>
>> The issue is that there are two notions of equality for BigDecimal,
>> equals and compareTo, where equals compares value *and* scale while
>> compareTo compares numerically.
>>
>> The other numeric types use equals for equivalence, quite reasonably.
>> But in class BigDecimalOps in clojure/lang/Numbers.java, I propose
>> that
>>
>> public boolean equiv(Number x, Number y){
>> return toBigDecimal(x).equals(**toBigDecimal(y));
>> }
>>
>> should be
>>
>> public boolean equiv(Number x, Number y){
>> return toBigDecimal(x).compareTo(**toBigDecimal(y)) == 0;
>> }
>
>
> Ouch, is that really what Numbers.equiv is doing?
>
> No wonder some of our idiomatic numerical code is so slow - a coercion to
> BigDecimal is really expensive!
>
> It really needs instanceof checks and branches to handle the different
> cases efficiently. I'll have a go at a ticket/patch that addresses this.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
