Hi Ben, thanks for the answer. Yes, I understand the problems with representing float-point numbers using iee7654 and now I understand that returing BigDecimal would not solve the actual problem. However, we don't talk about 0.33333(3) in my example, which is non-terminating decimal. Entered 0.1 is actually a very precise number and the fact that it gets imprecise somewhere internally should now affect, IMHO, the result of multiplying two very precise numbers. What's the point of having a possibility to build a very high-level language on top of Clojure, when you still need to know the internals? Yes, having 1.1D for doubles and fractions or bigdecimal for 1.1 probably would be the best solution.. I don't know, if this is achievable now? Will there be a impact on the perfomance or on a backward compatibility?
If is this is never to be fixed by some reason (which one can it be?), then let me ask another question. I wonder, if there is a requirement for user to write custom business rules himself (lets say he wants to increase the price on 10%) and he uses 1.1, can I solve this issue with Clojure core without using external parsers/preprocessors? Something like replacing the 1.1 with 1.1M or 11/10 before evaluating the code? Wbr, Jevgeni On Jan 17, 7:47 pm, B Smith-Mannschott <bsmith.o...@gmail.com> wrote: > 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
