On Sat, Jan 16, 2010 at 23:13, Jevgeni Holodkov <jevgeni.holod...@gmail.com> wrote: > Currently, if the result of the multiplication is too small, then the > type will be double, despite the fact that one of the parameter was > BigDecimal: > > Clojure 1.1.0 > user=> (* 100M 1.1) > 110.00000000000001 > user=> (class (* 100M 1.1)) > java.lang.Double > > Such thing are really hard to find and this can be easily produced by > non-technical person, if he is using some kind of DSL which is based > on Clojure. Shoudn't it be BigDecimal instead?
IMO: No it should not. (Maybe someone else can explain this more succinctly, I feel like I'm muddling the point I'm trying to make.) The whole point of using BigDecimal is to avoid the non-intuitive funkyness that will result from using binary floating point (Double, Float) while expecting decimal behavior. Furthermore, BigDecimal can be arbitrarily precise, while Double has limited precision. Returning a BigDecimal from a (* 100M 1.1) would be pretending that the calculation is more precise than it actually is. Your example is well chosen for my line of argument. Are you aware that 0.1 can't be represented exactly as a Double? (It has a non-terminating representation in binary, just as 1/3 = 0.33333333333333... does in decimal.) 0.1M, however can be represented exactly as a BigDecimal. People can be awfully picky about predictable arithmetic behavior when it comes to Money, which is what BigDecimal is often used for. (From a DSL standpoint, it might have been better if Clojure had chosen 1.1 as the syntax for BigDecimal and 1.1D (or similar) for Double, but there's no fixing that now.) // Ben
-- 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
