[Haskell-beginners] ghci: inconsistent return values for succ

[Kostiantyn Rybnikov]

> 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>