Re: [Haskell-beginners] truncate results depend on strict/lazy

Whenever I have to deal with precision issues I try to remove floats and doubles from the equation entirely.

toRational (0.12 :: Float) 16106127 % 134217728 toRational (0.12 :: Double) 1080863910568919 % 9007199254740992>

truncate $ (toRational (0.12 :: Float)* 100) 11 truncate $ (toRational (0.12 :: Double)* 100) 11 Wrong, but at least it is consistently wrong and should not be interpreted differently regardless of optimizations. On Tue, Sep 10, 2013 at 1:14 PM, Bryan Vicknair wrote:

On Mon, Sep 09, 2013 at 08:28:48PM -0400, Brandon Allbery wrote:

...

On Mon, Sep 9, 2013 at 8:03 PM, Bryan Vicknair wrote:

...

Whatever the behavior of truncate is, given the same input it should give the same output.

An ideal, but unlikely when floating point is involved; optimization can result in altered evaluation order or removal (or even addition in some cases) of load/stores which can modify the internal representation. Note that ghci is completely unoptimized.

Thanks everyone for the help. I think I'll write my own parsing code instead of using reads and truncate. I really don't like floats. The whole reason this parsing code exists is so that the DB can store a simple integer instead of a float, but I still need to show the value as a float to the users.

This is scary though. This is the first leak I've found in the referential transparency abstraction in Haskell (besides unsafePerformIO). And the problem is, if I don't have referential transparency for 100% of pure functions, then I have to be suspicious of every one. I can use some heuristics to narrow down the suspects, such as questioning floating point functions first, but I just had my bubble burst nonetheless.

Is there any resource that compiles all the potential exceptions to the Haskell abstract machine? _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners