[Haskell-cafe] Re: Is logBase right?

[Ketil Malde]

Lennart Augustsson <lennart at 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