Lennart Augustsson <lenn...@augustsson.net> writes: > Prelude> toRational 697.04157958259998 > 3065621287177675 % 4398046511104 > Prelude> toRational 697.0415795826 > 3065621287177675 % 4398046511104
> As you can see, both numbers are represented by the same Double. > Haskell prints a Double with the simplest number that converts back to > the same bit pattern. > So there's no "keep more decimals", just a matter of string conversion. What puzzled me (and the parent article indicated), was that Python appeared to be able to work with more precision, and thus be more "numerically correct" than GHC. Since it's all machine precision floating point, this is even more strange, and I couldn't reproduce the behavior for any other numbers than the one used in the example. One test that I *didn't* make is this one: Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 697.0415795826 697.04157958259998 So yes - it's just a matter of Python printing the number as 697.04157958259998, while GHC prints it as 697.0415795826. Thanks for clarifying, and apologies for the confusion. >>> Its been fixed in the latest versions of Python: >>>>>> round(697.04157958254996, 10) >>> 697.0415795825 I get (Python 2.6.2): >>> round(697.04157958254996,10) 697.04157958259998 >>> ghci> roundN 697.04157958254996 10 >>> 697.0415795826 I suppose it is likely that 697.04157958254996 is closer to the real decimal value of this particular number than GHC's representation, which is 697.04157958255. Whether this is a problem is a different matter, and I'm curious what programs usefully depend on one behavior or the other in decimal rounding near the limit of precision. -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe