24 Oct 2001 08:47:41 +0200
George Russell <firstname.lastname@example.org> writes:
> (1) succ & pred. These appear for float to correspond to adding or subtracting
> 1.0. (I am finding this out by testing with ghci; it's not specified where
> it should be, in section 6.3.4 of the standard). Because of rounding errors,
> succ and pred fail many of the properties for float they have for integers, EG
> succ . pred = pred . succ = id
> succ x > x
> and so on.
Here's some interesting results from Hugs:
Prelude> succ 1.45
Prelude> succ 1.99
Prelude> succ 1.99999
Prelude> succ (-0.2)
Prelude> succ (-0.99999)
Prelude> succ (-1.1)
So, apparently, succ jumps to the smallest integer larger than the
argument for positive argument values, and to the smallest integer
larger than the argument plus one for negative values. Or something.
Here's a sampling from GHCi:
Main> succ 1.45
Main> succ 1.99
Main> succ (-0.2)
Main> succ (-1.1)
Apparently, GHC simply adds 1.0.
What was the argument for having Float and Double be part of Enum
Of course, it's nice to be able to specify sequences with the (..),
but (GHC again):
I'm not sure it is always obvious which numbers you end up with. Some
sequences have the last element outside the specified range, some do
not. At least, Hugs and GHC seem to be consistent.
Personally, I'd be inclined to drop succ and pred from Float/Double,
and only allow ranges with a specific increment.
(BTW, looking at the Enum definition in the HR, it seems to me that
..-generated lists can't be longer than maxint, since they are defined
in terms of fromEnum and toEnum, which works with Ints. Is this
If I haven't seen further, it is by standing in the footprints of giants