Re: Contagious BigDecimals?
Reviving a thread from three years ago (feel free to point me to something more recent) ... In Clojure 1.6: (class (+ 1 1.0M)) ; == java.math.BigDecimal (class (+ 1.0 1.0M)) ; == java.lang.Double So combining a BigDecimal with a Long produces a BigDecimal, but combining it with a Double produces a Double. The demotion to Double is implied by the statement about contagion the Clojure data structures pagehttp://clojure.org/data_structures#Data%20Structures-Numbers, although nothing is said about the promotion from Long to BigDecimal: Contagion BigInts and floating point types are contagious across operations. That is, any integer operation involving a BigInt will result in a BigInt, and any operation involving a double or float will result in a double. To me, the fact that BigDecimal is contagious sometimes but not always, seems confusing in a way that could encourage bugs. The fact that BigInts are contagious would also lead one to assume that BigDecimals are contagious. puzzler's post in this thread explained that the rationale for making Doubles rather than BigDecimals contagious is that numeric type contagion should reflect the contagion of imprecision in calculations, which is going to happen no matter type is given to the result, once you introduce any imprecise number into the calculations, i.e. in this case, a Double. And I see that when combining a Long with a BigDecimal, imprecision is not introduced. I understand the point, but I'm not sure that I agree: If you used a Double, you knew (or should have known) that you were getting imprecision. And pmbauer's question about Floats wasn't answered. It's still true in Clojure 1.6 that Doubles are contagious over Floats: (class (+ (float 1.0) 1.0)) ; == java.lang.Double I think that at the very least, if BigDecimals are contagious only some of the time, it would be worth putting big warning signs in the documentation announcing this fact. (I understand, though, that Clojure documentation is a work in progress, and is lagging in some ways behind the language, as suggested by other recent threads.) -- 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: Contagious BigDecimals?
On May 7, 2014, at 12:11 PM, Mars0i marsh...@logical.net wrote: To me, the fact that BigDecimal is contagious sometimes but not always, seems confusing in a way that could encourage bugs. The fact that BigInts are contagious would also lead one to assume that BigDecimals are contagious. I don't think it's a case of sometimes but not always. Instead there's a contagion precedence order such that any type earlier in the order combined with a type later in the order yields the type later in the order. Here's the order: Long BigInt Ratio BigDec Double Before applying the contagion order, narrower integer types are promoted to Long, and float is promoted to Double. See for reference the many implementations of opsWith in Numbers.java: https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/Numbers.java#L411 --Steve -- 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: Contagious BigDecimals?
On Wednesday, May 7, 2014 1:00:01 PM UTC-5, squeegee wrote: On May 7, 2014, at 12:11 PM, Mars0i mars...@logical.net javascript: wrote: To me, the fact that BigDecimal is contagious sometimes but not always, seems confusing in a way that could encourage bugs. The fact that BigInts are contagious would also lead one to assume that BigDecimals are contagious. I don’t think it's a case of “sometimes but not always”. Instead there’s a contagion precedence order such that any type earlier in the order combined with a type later in the order yields the type later in the order. Here’s the order: Long BigInt Ratio BigDec Double Before applying the contagion order, narrower integer types are promoted to Long, and float is promoted to Double. Thanks Steve. That's very clear, and very helpful. It's no longer confusing to me. I still would say that it would be a good thing if precedence order were documented explicitly at clojure.org or another obvious documentation source. There's still some potential for confusion. The rule is not what I would have expected. -- 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.
Contagious BigDecimals?
Bigints are contagious, so (+ 1 XXXN) = XXYN. It occurred to me to ask, Why aren't BigDecimals contagious as well? As things stand, (+ 1.0 1e400M) = Infinity — doubles are contagious, even when operated over with BigDecimals. I've never seen any discussion of BigDecimal contagion, so I assume my raising this question is merely revealing (again) my lack of understanding of floating-point representations and such. The quorum in #clojure came up with some suggestions for why contagious BigDecimals might not be desirable/practical: The management of precision is fundamentally too complicated and/or expensive. For example, providing a proper treatment of the differing levels of precision in e.g. (+ 1.0 1.15e400M) properly and efficiently may not be practical. Big ints subset the set of longs, so the promotion is straightforward. That's not the case for BigDecimals/doubles, where the latter's NaN and infinity values cannot be represented (AFAIK) by BigDecimal. The semantics around scale and rounding aren't easily reconciled with Clojure's existing operators. e.g.: = (/ 1M 3M) #CompilerException java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result. These all seem like plausible rationales, but I thought I'd poll the list to see if anyone wanted to offer additional / further explanations. Continuing in my streak of numerics-related ignorance, - Chas -- 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
Re: Contagious BigDecimals?
doubles are inherently inexact; they are approximations of a real number. If you add an inexact number and an exact number, the only thing that makes sense is to return something that is inexact. BigInt contagion is different, because you are adding two exact things, it's just a question of internal representation. -- 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
Re: Contagious BigDecimals?
If you add an inexact number and an exact number, the only thing that makes sense is to return something that is inexact. So why then are double's contagious when mixing double and float values in a calculation? Doubles and floats are both inexact, but floats are at least less exact than doubles. -- 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
Re: Contagious BigDecimals?
(re: why then...) P.S. I mean in more general context of how double contagion is handled in most languages. Clojure 1.3 alphas auto-promote floats to doubles in almost every case eg. exception: (type (float 1.0)) On Monday, May 23, 2011 4:16:48 PM UTC-7, pmbauer wrote: If you add an inexact number and an exact number, the only thing that makes sense is to return something that is inexact. So why then are double's contagious when mixing double and float values in a calculation? Doubles and floats are both inexact, but floats are at least less exact than doubles. -- 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
