Re: rounding in haskell

2000-02-10 Thread Ronny Wichers Schreur
Another kind of rounding can occur when a floating number is converted between different formats, for example with processors that internally use a higher precision. Consider the following two almost identical programs. - small powerOf2 exp |

RE: rounding in Haskell -- a bug in hugs

2000-02-09 Thread John Hughes
Frank Christoph writes: It seems to me there is a tension between using show as a way of doing quick and dirty pretty-printing, and as a way of getting a portable representation of data. This is a "bug" in hugs. To illustrate the problem, the next floating point number after 5.0 is

RE: rounding in Haskell -- a bug in hugs

2000-02-09 Thread Mark P Jones
Hi John, | This is a "bug" in hugs. | | To illustrate the problem, the next floating point number after | 5.0 is 5.0047, | which hugs also prints as 5.0. One might argue that to display it | as 5.005 would | be misleading, since this number is the closest representable to |

Re: rounding in Haskell -- a bug in hugs

2000-02-09 Thread Fergus Henderson
On 09-Feb-2000, Mark P Jones [EMAIL PROTECTED] wrote: The Numeric.showFloat function is there for the more expert programmers who care about the last few bits after the floating point. That's the function that a Haskell programmer should use if they need this kind of functionality. I can

Re: rounding in haskell

2000-02-08 Thread George Russell
(LONG and about floating point, so I suspect many Haskellers are not going to be interested in this message . . .) Julian Assange wrote: The precission and or rounding used by hugs/ghc seems strange, to wit: Prelude sin(pi) -8.74228e-08 Prelude pi 3.14159 sin(3.14159265358979323846)

Re: rounding in haskell

2000-02-08 Thread George Russell
Jerzy Karczmarczuk wrote: but one should always try to perform all the needed reductions before the floating precision gets out of control. There are nice recurrences which simplify the computations with trigonometric functions. But between 0 and Pi/4 it should be well done. No one should

Re: rounding in haskell

2000-02-08 Thread Ian . Stark
Prelude 1.0 - 0.8 - 0.2 -1.49012e-08 Since the Paleozoic Era Hugs is distributed with HAS_DOUBLE_PRECISION desactivated (can some gurus explain why?...), and the first thing I do with, is its recompilation. Such nasties as above become then less dangerous. "less dangerous" ... perhaps I

Re: rounding in haskell

2000-02-08 Thread John Hughes
Prelude 1.0 - 0.8 - 0.2 -1.49012e-08 Taking Ian Stark's example a little bit further, Main let x=6.0e-8 in (1.0,1.0+x,1.0==1.0+x) (1.0,1.0,False) is a useful reminder that show isn't one-to-one. John Hughes

Re: rounding in haskell

2000-02-08 Thread George Russell
George Russell wrote: Julian Assange wrote: Once you are within a few UDP, the underlaying grainyness of the representation is going to get you, so that smoothe, monotonic line segment you have below, will look like an appalling zigzag at best. This is my point. Near the limits of

RE: rounding in haskell

2000-02-08 Thread Karlsson Kent - keka
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] ... George rightly points out how tricky trig functions are. My own favourite curious operation is subtraction: Prelude 1.0 - 0.8 - 0.2 -1.49012e-08 Yes, floating point arithmetic is fascinating, isn't it!

RE: rounding in haskell

2000-02-08 Thread Karlsson Kent - keka
(LONG and about floating point, so I suspect many Haskellers are not going to be interested in this message . . .) This one too. -Original Message- From: George Russell [mailto:[EMAIL PROTECTED]] ... Let's summarise what IEEE 754 gives you. IEEE 754 only

Re: rounding in haskell

2000-02-08 Thread Koen Claessen
Hello ASCII artists, Maybe the rounding issue, which doesn't seem to have much to do with Haskell anymore at this point, can be taken offline? Regards, Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 e-mail:[EMAIL PROTECTED]

Re: rounding in haskell

2000-02-08 Thread David Lester
I had at first thought that this might be a discussion of the US style definition of round in the standard prelude that always bites me... ... Then that it might be the bug in floor within the standard issue of GMP. Instead its a discussion of FP problems. (1) My friend Jean-Michel Muller at

RE: rounding in haskell

2000-02-08 Thread Julian Seward (Intl Vendor)
Since the Paleozoic Era Hugs is distributed with HAS_DOUBLE_PRECISION desactivated (can some gurus explain why?...), and the first thing I do with, is its recompilation. Such nasties as above become then less dangerous. The newer STG Hugs which we are developing has "real" Doubles as

RE: rounding in haskell

2000-02-08 Thread Karlsson Kent - keka
a straight line, EG for example XX X XX X X XX X XX (blah blah) the point being that this is a straight line with slope a bit less than 1/3. Code to test this attached. Try (in Hugs) plotSin pi 100. You should a

Re: rounding in haskell

2000-02-08 Thread Julian Assange
George Russell [EMAIL PROTECTED] writes: (LONG and about floating point, so I suspect many Haskellers are not going to be interested in this message . . .) Excellent, thanks george. Now I think the original suggestor wanted the library to spot that the answer is "very close to" 0 and

RE: rounding in haskell

2000-02-08 Thread Frank A. Christoph
John Hughes wrote: Taking Ian Stark's example a little bit further, Main let x=6.0e-8 in (1.0,1.0+x,1.0==1.0+x) (1.0,1.0,False) is a useful reminder that show isn't one-to-one. Dunno much about FP arithmetic, but maybe there should be a primitive showFloatExact which yields the

Re: rounding in haskell

2000-02-07 Thread Lennart Augustsson
Julian Assange wrote: The precission and or rounding used by hugs/ghc seems strange, to wit: Prelude sin(pi) -8.74228e-08 Prelude pi 3.14159 sin(3.14159265358979323846) -8.74228e-08 ghc: module Main where main = do print pi print (sin pi) ./a.out

Re: rounding in haskell

2000-02-07 Thread Julian Assange
Lennart Augustsson [EMAIL PROTECTED] writes: Haskell performs no worse or better than C. Your comment about how math libraries round might be accurate for some languages, but for C it's pure nonsense. It seems that you are right in this instance. However I recall seeing comments about error