From: Rick DeNatale Date: 2010-05-11T21:11:29+09:00 Subject: Re: ruby 1.9+ , floats, and decimal On Mon, Apr 19, 2010 at 1:24 AM, Christopher Dicely wrote: > On Sun, Apr 18, 2010 at 8:07 PM, botp wrote: >>> 0.2-0.1 >> => 0.1 >> >>> 1.2-0.1 >> => 1.1 >> >>> 1.2-1.1 >> => 0.0999999999999999 >> >> gotcha! >> >> ok, i know what you're thinking. this dead horse is double dead.. >> >> in the spirit of advancing to a better computing env, shouldn't it be >> time for ruby to default to "real" decimal instead of float? > > I think decimal floating point (as supported in the 2008 version of > IEEE 754) would > be a good idea. OTOH, to reduce the potential impact on existing code > -- including > on performance, where binary floating point, since it has more > prevalent hardware > support, is likely to outperform in most cases -- it might be better > to introduce a > simple syntax for decimal floating point literals, e.g. an integer or > floating point > expression with a trailing (no intervening whitespace) "d" like 1.0d > would be treated > as a decimal floating point value. I'm afraid that this idea of making BigDecimal the default is based on a naive view that BigDecimal is some kind of Panacea. It's not. And a Fixed length decimal float would be even worse, for example: 1). Just because BigDecimal has what seems like better behavior in some cases compared to a binary float, it has just as many problems in other cases. (BigDecimal("1") / BigDecimal("3")).to_s => "0.333333333333333333333333333333333333E0" Both binary and decimal floats have an infinite number of real numbers which they can't express exactly. 2) Rounding errors in floating pt get bigger when the base is bigger http://docs.sun.com/source/806-3568/ncg_goldberg.html Although the latter point is somewhat obviated by BigDecimal which uses a variable length, variable length does nothing for the first point, and the length of a BigDecimal is practically bounded, since it has to be represented in the finite storage of the platform. And the variable length is a major reason why the performance of BigDecimal arithmetic is so inferior to other representations. There's no getting around the fact that different number representations have different trade-offs, and in many cases any programmer will need to make choices based on those trade-offs. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale