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
| powe
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.
Mark P Jones 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
I don't agree. Numeric.showFloat is for the novice who
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
| everything
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 5.0
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 yiel
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
> 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
s
> > 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) plotSi
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 Ly
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]
---
Karlsson Kent - keka wrote:
> ?? Let me for a moment assume that I haven't completely
> lost my mind... (which I might have...)
No, I don't think you've lost your mind; indeed I agree with everything you
say.
(ASCII art clipped). I would write that as something like
X
X
X
X
(and
> (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 on
> -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'
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 limit
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 precession, the error
> introd
> > 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
Ian.Stark about:
>
> > > Prelude> 1.0 - 0.8 - 0.2
> > > -1.49012e-08
> ... I don't quote
> this example because it is a fault with single vs double precision,
> a mistake in Hugs, or indeed a problem at all. It's just
> interesting to see how our perception of real numbers can clash with
> the
I remarked:
> > Since the Paleozoic Era Hugs is distributed with HAS_DOUBLE_PRECISION
> > desactivated (can some gurus explain why?...), ...
and Julian Seward (Intl Vendor) answers:
> The newer STG Hugs which we are developing has "real" Doubles as
> standard, so you should get the same(ish) re
> > 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" ... p
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 shoul
Ian Stark:
> 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
Since the Paleozoic Era Hugs is distributed with HAS_DOUBLE_PRECISION
desactivated (can some gurus explain why?...), and the f
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
Ian Stark http://www.dcs.ed.ac.uk/home/stark
LFCS, Divis
George Russell wrote:
> (LONG and about floating point, so I suspect many Haskellers are not
> going to be interested in this message . . .)
Thank you George for your message. You said it better than I could (and did).
-- Lennart
(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.1415926535897932
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 err
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.ou
27 matches
Mail list logo
