Re: How to coerce to bigint ?
Just for the records You can still use auto-promotion with primed operators like *', +' etc. => (* 10 100) java.lang.ArithmeticException: integer overflow => (*' 10 100) 1000N -- 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/d/optout.
Re: How to coerce to bigint ?
On Saturday, April 4, 2015 at 1:00:46 PM UTC-4, Michael Gardner wrote: > > On Sat, Apr 4, 2015 at 11:36 AM, Paul Roush > wrote: > >> (range 5N) => (0 1 2 3 4) ; i.e. the "bigint-ness" is lost >> >> So in this particular case I needed to "inject" bigint into the process >> later in some way. >> > > You could try (range (* 0 n) n). A little silly, but does avoid the > conditional. > > You could consider also creating a JIRA issue asking for range to match > the type of its argument in the 1-arity case. No idea whether it would be > accepted, though. > Interesting. My code was actually calling range with 2 args, as I want a 1-based range. The 1 was a literal, and to support the non-bigint case I don't want to hardwire it to 1N. Now I see that: (range 1N 5N) => (1N 2N 3N 4N) (range 1 5N) => (1 2 3 4) So I could pass (/ n n ) as my first arg to range and I'll get the desired type in all cases. But this behavior of 'range' now feels quirky to me. -- 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/d/optout.
Re: How to coerce to bigint ?
On Sat, Apr 4, 2015 at 11:36 AM, Paul Roush wrote: > (range 5N) => (0 1 2 3 4) ; i.e. the "bigint-ness" is lost > > So in this particular case I needed to "inject" bigint into the process > later in some way. > You could try (range (* 0 n) n). A little silly, but does avoid the conditional. You could consider also creating a JIRA issue asking for range to match the type of its argument in the 1-arity case. No idea whether it would be accepted, though. -- 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/d/optout.
Re: How to coerce to bigint ?
On Saturday, April 4, 2015 at 12:09:36 PM UTC-4, Andy Fingerhut wrote: > > > > On Sat, Apr 4, 2015 at 8:52 AM, Paul Roush > > wrote: > >> I have 2 questions related to bigints. >> >> 1) I've read things suggesting Clojure auto-converts between int, long, >> and bigint to prevent overflow. That isn't the behavior I've experienced. >> Did something change from an older release of Clojure to more recent ones? >> > > Clojure 1.2 and earlier auto-promoted, if I recall correctly, but that has > not been the case since Clojure 1.3, released in Sep 2011. You may have > found something published before then. > > Clojure 1.3 and later do give a bigint result for integer arithmetic if > any of the arguments are bigints, e.g. (+ 1N 1) => 2N > Thanks for the historical info. > >> >> 2) I found myself wanting to write a function that would use bigint math >> vs not depending on whether I passed a bigint in as arg. Internally I >> wanted to "seed" a reduce call with either 1 or 1N as appropriate. So I >> wanted to write something like this (except I'd like it to work): >> >> (defn foo [n] >> (cast (type n) 1)) >> >> ; (foo 3) => 1 >> ; (foo 42N) => 1N >> >> The following works, but I'd like to understand if I can avoid the >> conditional: >> >> (defn foo [n] >> (if (= clojure.lang.BigInt (type n)) 1N 1)) >> > > More commonly I have seen (instance? clojure.lang.BigInt n) rather than (= > clojure.lang.BigInt (type n)), but I do not know any way to avoid the > conditional here. > > I would ask that you consider whether you really do need this check, > though, since if your argument is BigInt and is combined with any > arithmetic operation with a local long value in the function, the result > will be BigInt. > > Andy > I like your conditional better, so seeing that is welcome. Regarding the last point, I understand that what you say is generally true, but in this specific case my function arg was defining the end of a 'range' call that was fed into other logic. (range 5N) => (0 1 2 3 4) ; i.e. the "bigint-ness" is lost So in this particular case I needed to "inject" bigint into the process later in some way. -- 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/d/optout.
Re: How to coerce to bigint ?
On Sat, Apr 4, 2015 at 8:52 AM, Paul Roush wrote: > I have 2 questions related to bigints. > > 1) I've read things suggesting Clojure auto-converts between int, long, > and bigint to prevent overflow. That isn't the behavior I've experienced. > Did something change from an older release of Clojure to more recent ones? > Clojure 1.2 and earlier auto-promoted, if I recall correctly, but that has not been the case since Clojure 1.3, released in Sep 2011. You may have found something published before then. Clojure 1.3 and later do give a bigint result for integer arithmetic if any of the arguments are bigints, e.g. (+ 1N 1) => 2N > > 2) I found myself wanting to write a function that would use bigint math > vs not depending on whether I passed a bigint in as arg. Internally I > wanted to "seed" a reduce call with either 1 or 1N as appropriate. So I > wanted to write something like this (except I'd like it to work): > > (defn foo [n] > (cast (type n) 1)) > > ; (foo 3) => 1 > ; (foo 42N) => 1N > > The following works, but I'd like to understand if I can avoid the > conditional: > > (defn foo [n] > (if (= clojure.lang.BigInt (type n)) 1N 1)) > More commonly I have seen (instance? clojure.lang.BigInt n) rather than (= clojure.lang.BigInt (type n)), but I do not know any way to avoid the conditional here. I would ask that you consider whether you really do need this check, though, since if your argument is BigInt and is combined with any arithmetic operation with a local long value in the function, the result will be BigInt. Andy -- 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/d/optout.
How to coerce to bigint ?
I have 2 questions related to bigints. 1) I've read things suggesting Clojure auto-converts between int, long, and bigint to prevent overflow. That isn't the behavior I've experienced. Did something change from an older release of Clojure to more recent ones? 2) I found myself wanting to write a function that would use bigint math vs not depending on whether I passed a bigint in as arg. Internally I wanted to "seed" a reduce call with either 1 or 1N as appropriate. So I wanted to write something like this (except I'd like it to work): (defn foo [n] (cast (type n) 1)) ; (foo 3) => 1 ; (foo 42N) => 1N The following works, but I'd like to understand if I can avoid the conditional: (defn foo [n] (if (= clojure.lang.BigInt (type n)) 1N 1)) -- 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/d/optout.
