Enum class

[Ketil Malde]

George Russell <ger@tzi.de> 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
2.0
Prelude> succ 1.99
2.0
Prelude> succ 1.99999
2.0
Prelude> succ (-0.2)
1.0
Prelude> succ (-0.99999)
1.0
Prelude> succ (-1.1)
0.0

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
2.45
Main> succ 1.99
2.99
Main> succ (-0.2)
0.8
Main> succ (-1.1)
-0.10000000000000009

Apparently, GHC simply adds 1.0.

What was the argument for having Float and Double be part of Enum
again?  :-)

Of course, it's nice to be able to specify sequences with the (..),
but (GHC again):

Main> [1.0..2.5]
[1.0,2.0,3.0]
Main> [1.1..2.5]
[1.1,2.1]
Main> [1.1..3.0]
[1.1,2.1,3.1]

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
correct? Why?)

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants