> 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@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@gmail.com> wrote:
@ Dan Stromberg: Thanks, understood.

On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits <neuralpancake@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners