@ 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... 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 wrote:

@ Dan Stromberg: Thanks, understood.

On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits 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....

@ Kostiantyn: Thank you again for the links to Decimal and Data.Fixed @ Iustin: You're absolutely correct, I was abusing succ. I blame myself. @ Rein: Thank you, I'd previously shared the goldberg paper; it's illuminating. Fwiw, prior to adventures with succ, I'd noticed that simple operations on certain simple real numbers would give "exciting" results. (Undoubtedly, I should have just gone with that instead of posting about succ; apologies again for confusing Iustin.) ghci> map (+ 0.01)[0.01,0.02 .. 1.00] for example, gave me a nice list of visually stimulating values for the reasons Rein and Kostiantyn pointed out. With succ, I wondered what I would see if I did something "wrong." My assumption was that it would flail and give me an error message, something along the lines of "Fool, that is not the proper way to succ. Go play with natural numbers." That I'd get occasionally expected values with either the above or succ was.....peculiar, until reading Kostiantyn's replies and finding and reading the Goldberg paper, not to mention having a "Forth moment" and remembering scaled integer...... I (foolishly or not) made the assumption that Haskell would do something different with floats "out of the box." I do realize the same issues are inherent in other languages, but I wondered if it might be "smart," recognize I was calculating with real numbers and automagically either load what I needed or point me in that direction. That said, I really appreciate Rein's reply and recognize that picking Double for the extended default rules is "a good choice." Anyway, after loading Data.Fixed, this produces reasonable output: ghci> map (+ (0.01 :: Fixed E2)) [0.01,0.02 .. 1.01] Back to reading and learning by cutting myself. Thanks again all. On Sun, Oct 18, 2015 at 8:57 AM, Frothy Bits 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...

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

...

@ Dan Stromberg: Thanks, understood.

On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits 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....

That said, I really appreciate Rein's reply and recognize that picking Double for the extended default rules is "a good choice."

To follow up a bit, the reason that it's a good choice is pragmatic: we usually prefer to work with such numbers using native floating point math for speed rather than using rational or computable real or other representations which are more accurate but many orders of magnitude slower. If I said 3.5 + 1 in any general purpose language, I would be surprised if it did anything other than an immediate floating point calculation, and so it is (by default) in Haskell. If we want another representation then we must reach for it, but we don't need to reach very far. On Sun, Oct 18, 2015 at 10:05 PM Kim-Ee Yeoh wrote:

On Sun, Oct 18, 2015 at 10:57 PM, Frothy Bits wrote:

...

Is the behavior I'm seeing actually related to a bug in parsec?

If you're interested in digging deeper, I'd say look at the output, not the input end. Almost certainly the machine floating-point double for 3.14 and (3.14+1.0) are identical across ghc, C, and python.

What's not identical is how different languages choose to display 4.14.

C and python do some display rounding so you don't see the issue. The display algorithm in Haskell probably goes for the simple, naive approach.

-- Kim-Ee _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners