<div dir="ltr">> <span style="font-size:12.8px">Is the behavior I'm seeing actually related to a bug in parsec?  </span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">No, I don't think GHC relies on parsec at all.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">Yes or no, why wouldn't it be the default behavior of ghc to load the Decimal package?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Integer, unlike Int and Double, is very inefficient for computation-heavy code.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Interesting find!</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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:</span></div><div><span style="font-size:12.8px"><br></span></div><div><div><span style="font-size:12.8px">λ succ (3.14 :: Fixed E12)</span></div><div><span style="font-size:12.8px">3.140000000001</span></div><div><span style="font-size:12.8px">λ (3.14 :: Fixed E12) + 1</span></div><div><span style="font-size:12.8px">4.140000000000</span></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So, if you don't want to use Decimal, you can just use Data.Fixed (I find Decimal a bit more elegant </span><span style="font-size:12.8px">though</span><span style="font-size:12.8px">).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">[0]: <a href="https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Fixed.html">https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Fixed.html</a></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 18, 2015 at 6:57 PM, Frothy Bits <span dir="ltr"><<a href="mailto:neuralpancake@gmail.com" target="_blank">neuralpancake@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@ Kostiantyn: Thank you.<div><br></div><div>Is the behavior I'm seeing actually related to a bug in parsec?  </div><div><br></div><div><a href="http://stackoverflow.com/questions/29820870/floating-point-numbers-precision-and-parsec" style="font-size:12.8px" target="_blank">http://stackoverflow.com/questions/29820870/floating-point-numbers-precision-and-parsec</a><br></div><div><br></div><div><div>Yes or no, why wouldn't it be the default behavior of ghc to load the Decimal package?</div><div><br></div><div>OTOH, the current default floating point behavior certainly got me thinking and digging:</div></div><div><br></div><div><a href="http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html" style="font-size:12.8px" target="_blank">http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html</a><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 17, 2015 at 7:48 PM, Frothy Bits <span dir="ltr"><<a href="mailto:neuralpancake@gmail.com" target="_blank">neuralpancake@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@ Dan Stromberg:  Thanks, understood.  </div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 17, 2015 at 7:17 PM, Frothy Bits <span dir="ltr"><<a href="mailto:neuralpancake@gmail.com" target="_blank">neuralpancake@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Greetings,<div><br></div><div>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:</div><div><br></div><div>ghci> succ 3.14</div><div>4.1400000000000001  </div><div><br></div><div>for example instead of the expected 4.14</div><div><br></div><div>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.</div><div><br></div><div>I tested this on Windows and Linux (various flavors) and I get the same results there and in the interactive test code space on <a href="http://haskell.org" target="_blank">haskell.org</a>.</div><div><br></div><div>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....</div><div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br></div>