[Haskell-beginners] ghci: inconsistent return values for succ
Kostiantyn Rybnikov
k-bx at k-bx.com
Sun Oct 18 16:56:51 UTC 2015
> Is the behavior I'm seeing actually related to a bug in parsec?
No, I don't think GHC relies on parsec at all.
> Yes or no, why wouldn't it be the default behavior of ghc to load the
Decimal package?
Decimal is very inefficient, because it's implemented as a pair of
numbers: Word8 to describe a position of a dot, and Integer to describe
number itself. E.g., (3.14 :: Decimal) is the same as directly writing
(Decimal 2 314).
Integer, unlike Int and Double, is very inefficient for computation-heavy
code.
Interesting find!
Ghc (its base library) provides Data.Fixed [0] module with similar purposes
to Decimal. Initially I couldn't recommend it, since I thought it has the
same Double-related behavior, but when I digged into it now, I found out
that it's probably a bug (or a "feature") in "succ" implementation:
λ succ (3.14 :: Fixed E12)
3.140000000001
λ (3.14 :: Fixed E12) + 1
4.140000000000
So, if you don't want to use Decimal, you can just use Data.Fixed (I find
Decimal a bit more elegant though).
[0]: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Fixed.html
On Sun, Oct 18, 2015 at 6:57 PM, Frothy Bits <neuralpancake at gmail.com>
wrote:
> @ Kostiantyn: Thank you.
>
> Is the behavior I'm seeing actually related to a bug in parsec?
>
>
> http://stackoverflow.com/questions/29820870/floating-point-numbers-precision-and-parsec
>
> Yes or no, why wouldn't it be the default behavior of ghc to load the
> Decimal package?
>
> OTOH, the current default floating point behavior certainly got me
> thinking and digging:
>
> http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
>
>
>
>
>
> On Sat, Oct 17, 2015 at 7:48 PM, Frothy Bits <neuralpancake at gmail.com>
> wrote:
>
>> @ Dan Stromberg: Thanks, understood.
>>
>> On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits <neuralpancake at gmail.com>
>> wrote:
>>
>>> Greetings,
>>>
>>> Absolutely brand new to Haskell. Taking ghci v7.10.2 out for a spin,
>>> and I find I get inconsistent return values for succ n:
>>>
>>> ghci> succ 3.14
>>> 4.1400000000000001
>>>
>>> for example instead of the expected 4.14
>>>
>>> succ 2.14 and 4.14 give the expected results. but succ 2.14 returns
>>> 2.1399999999999997. This anomalous behavior runs through the range of
>>> n.nn; in the n.01 range, for example, 16.01 and 63.01 return wonky results
>>> per above.
>>>
>>> I tested this on Windows and Linux (various flavors) and I get the same
>>> results there and in the interactive test code space on haskell.org.
>>>
>>> I'm not familiar enough with the language, yet, to go debugging this on
>>> my own, but it would seem to be at least a problem with how succ is
>>> implemented, if not how values are handled in general.....which could
>>> potentially be bad if you were trying to do anything requiring precise
>>> calculations....
>>>
>>>
>>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20151018/84caf3e8/attachment.html>
More information about the Beginners
mailing list