support for Big numeric types in Reflector
trptcolin
Reflector - CLJ-666 (gasp!) - (http://dev.clojure.org/jira/browse/
CLJ-666). It's relatively straightforward to add support for these in
clojure.lang.Reflector.paramArgTypeMatch, but it causes a difference
in bit-shift-left's behavior, breaking a test:
;; current master
user=> (bit-shift-left 1 10000)
65536
user=> (bit-shift-left 1N 10000)
19950631168807583848837421626835....etc.
user=> (bit-shift-left 1N 10000N)
19950631168807583848837421626835....etc.
;; after adding Reflector support for BigInt, BigInteger, and
BigDecimal
user=> (bit-shift-left 1 10000)
65536
user=> (bit-shift-left 1N 10000)
65536
user=> (bit-shift-left 1N 10000N)
19950631168807583848837421626835....etc.
So upon adding reflection for BigInt => int, bit-shift-left picks the
primitive version of Numbers.shiftLeft(long, int).
So it seems like there are 3 questions here:
1) Should bit-shift-left overflow silently for primitive math? If not,
might an overflow guard for this primitive version of shiftLeft be a
way forward, as a symmetry with the way addition and multiplication
work in 1.3?
2) Is there a problem with (BigInt, Long) dispatching to (long, int)
here instead of (Object, Object)?
3) I caught this potential problem because it was the one test case
that failed, so I'm concerned there might be other changes exposed as
well that just aren't in the test suite. Are there other places to
look out for?
Thoughts? I have a patch with tests for the initial change, which
might clarify anything I haven't explained well, but wanted to get
feedback on the bit-shift-left stuff before submitting. I'll
certainly link any discussion here to the issue.
Thanks!
- Colin
ataggart
get around to applying it).
Regarding overflow, I'm disinclined to view bit-twiddling ops as
precision math ops. Shifting bits on a fixed-length integer means
pushing them off one end or the other.
Rich Hickey
primitives, and the negative shift support.
I'd like to remove both - does anyone care?
Rich
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure Dev" group.
> To post to this group, send email to cloju...@googlegroups.com.
> To unsubscribe from this group, send email to clojure-dev...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en
> .
>
ataggart
How should this fit with "contagious bigints" policy? E.g., should
(bit-shift-left 1N 1) return 2N or 2?
Should all bit ops be limited to a 64-bit long?
Rich Hickey
On Apr 1, 2011, at 12:27 AM, ataggart wrote:
> It wouldn't negatively impact any of the bit-twiddling code I have.
>
> How should this fit with "contagious bigints" policy? E.g., should
> (bit-shift-left 1N 1) return 2N or 2?
>
> Should all bit ops be limited to a 64-bit long?
>
Shift ops would be limited to primitives only. Default versions 64-
bit, but explicit shift-int versions for 32 bits.
Rich
ataggart
desirable behaviour. Since only the bottom 5-bits of the shift
distance are used, negative numbers behave oddly, e.g., 1 << -2 is
processed as 1 << 30. Leaving it in, or erroring on negatives might
be preferable.
Also, do you want primitives-only for all bit operations, e.g., bit-
and, test-bit.
Rich Hickey
On Apr 4, 2011, at 1:28 AM, ataggart wrote:
> Regarding the negative shift support, removing it might have less
> desirable behaviour. Since only the bottom 5-bits of the shift
> distance are used, negative numbers behave oddly, e.g., 1 << -2 is
> processed as 1 << 30. Leaving it in, or erroring on negatives might
> be preferable.
>
The goal is to get rid of the conditional. People that are using
shifts as nature intended are doing so for the utmost performance, and
any conditional test kills it. I'm fine with following:
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.19
People looking for mathematical purity should avoid bit ops, they are
mechanical.
> Also, do you want primitives-only for all bit operations, e.g., bit-
> and, test-bit.
>
I'd like primitive-only to be the default, but BigInteger has and/or
etc and there's no reason to hide them. Perhaps we need prime versions
for that?
Rich
ataggart
On Apr 4, 4:36 am, Rich Hickey <richhic...@gmail.com> wrote:
> I'd like primitive-only to be the default, but BigInteger has and/or
> etc and there's no reason to hide them. Perhaps we need prime versions
> for that?
behaviour is the same as ours currently. Assuming we don't want to
hide that as well, is it acceptable to have BigIntegers behave
differently from other Numbers and primitives?
Aside: was there a reason the clojure.unchecked namespace [1] was
abandoned? Seems like that would be a good place for all these
changes.
[1] http://dev.clojure.org/jira/browse/CLJ-441
ataggart
On Apr 4, 4:36 am, Rich Hickey <richhic...@gmail.com> wrote:
> On Apr 4, 2011, at 1:28 AM, ataggart wrote:
>
> > Regarding the negative shift support, removing it might have less
> > desirable behaviour. Since only the bottom 5-bits of the shift
> > distance are used, negative numbers behave oddly, e.g., 1 << -2 is
> > processed as 1 << 30. Leaving it in, or erroring on negatives might
> > be preferable.
>
> The goal is to get rid of the conditional. People that are using
> shifts as nature intended are doing so for the utmost performance, and
> any conditional test kills it. I'm fine with following:
>