On Sunday, March 05, 2000 10:06 AM, Reuben Thomas
[SMTP:[EMAIL PROTECTED]] wrote:
>
> ...except there were rounding problems. Floating-point numbers are simply
> difficult. Representing them is bad, displaying them is worse, and there
> are questions I don't know the answer to about how the list is
> calculated: if by repeated addition, rounding errors will build up (it
> looks like that, since 8.0 can certainly be represented in the machine
> accurately, but wasn't in your list), and if by multiplication, they
> should be one-off errors.
>
> My own experiment (running Hugs September 1999 on a Psion Revo) suggest
> that in fact the list is formed by repeated addition, as I get:
>
> [1.0, 1.1,...,6.3,6.4,6.499999999999,6.599999999,...,9.2999999998,...,
> 9.99999999998]
>
> (adjust no. of 9's to taste)
>
> which looks like a rounding error is gradually building up. This is a
> silly way to calculate such lists in FP, but perhaps there's a good
> reason? (I suppose speed of calculation might be one!)
>
The Prelude definition of EnumFromToThen for floats is by iterating
addition. There is also the following note:
-- The Enum instances for Floats and Doubles are slightly unusual.
-- The `toEnum' function truncates numbers to Int. The definitions
-- of enumFrom and enumFromThen allow floats to be used in arithmetic
-- series: [0,0.1 .. 1.0]. However, roundoff errors make these somewhat
-- dubious. This example may have either 10 or 11 elements, depending on
-- how 0.1 is represented.
These things are arithmetic progressions, so one would expect addition by
fixed steps equal to whatever floating point number most closely
corresponds to the difference between the floating point numbers denoted by
"1.0" and "1.1". This will inevitably produce approximate results. In
early versions of Haskell, Enum was a subclass of Ix, which prevented Float
being an instance of Enum (you can't sensibly do range (1.0,2.0)), and this
kind of problem was avoided.
--brian
> http://sc3d.org/rrt/ | certain, a. insufficiently analysed
