RE: Enum instance for Ratio
| Both GHC and Hugs have a bug in their Prelude for Ratio's Enum | instance. The following program | |import Ratio |main = print [ 1, 4%(3::Int) .. 2 ] | | should print | |[1 % 1,4 % 3,5 % 3,2 % 1] | | but instead an infinite list of 1%1s is generated. The reason for this | is that the default method for enumFromThenTo is used, which truncates | 4%3 to 1 (same for enumFromTo). | Malcolm Wallace wrote: | I'd say that this is a bug in the Library Report, which seems to | specify this implementation. [...] | | But for Float, Double, Ratio and friends the report explicitly | states that numericEnumFromFooBar has to be used, which generates | the finite list. So it's only a bug in all implementations. :-) Indeed, GHC's libraries are wrong. We'll fix that. I don't propose to change the H98 defn of Enum instances though, flawed though they may be. Simon
Re: Enum instance for Ratio
Marc van Dongen wrote: Wouldn't that make Enum depend on Ord? Doesn't seem to make sense if classes are enumerable but not comparable. What examples are there of types for which it would be sensible to implement Enum but not Ord? The concept rather puzzles me. In particular, suppose you don't have an ordering on the pair (a,b). How do you propose to compute [a..b] ?
Enum instance for Ratio
Both GHC and Hugs have a bug in their Prelude for Ratio's Enum instance. The following program import Ratio main = print [ 1, 4%(3::Int) .. 2 ] should print [1 % 1,4 % 3,5 % 3,2 % 1] but instead an infinite list of 1%1s is generated. The reason for this is that the default method for enumFromThenTo is used, which truncates 4%3 to 1 (same for enumFromTo). Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Enum instance for Ratio
George Russell ([EMAIL PROTECTED]) wrote: : Marc van Dongen wrote: : Wouldn't that make Enum depend on Ord? : Doesn't seem to make sense if classes are : enumerable but not comparable. Of course above I should have said orderable in stead of comparable. : What examples are there of types for which it would be sensible to implement : Enum but not Ord? The concept rather puzzles me. In particular, suppose you : don't have an ordering on the pair (a,b). How do you propose to compute :[a..b] data Human = Woman | Man I can see reasons why I would like to know which Humans are there from a to b given a certain predifined order. Bu having said that I also think that in order to implement this, it is not necesary to to have to say that Woman is less than Man or vice versa. Regards, Marc
Re: Enum instance for Ratio
Sven writes: Both GHC and Hugs have a bug in their Prelude for Ratio's Enum instance. ... The reason for this is that the default method for enumFromThenTo is used, which truncates 4%3 to 1 (same for enumFromTo). I'd say that this is a bug in the Library Report, which seems to specify this implementation. (By the way, nhc98 suffers the same bug for the same reason, so can whoever fixes it first please publish their code so we can all share it? :-) Regards, Malcolm
Re: Enum instance for Ratio
A logical definition of Enum (to me wearing a mathematical hat)
would be
succ x = min { y | y x}
For Ratio this makes no sense, ergo Ratio should not be an
instance of Enum. For Float and Doubles it makes a lot of
sense (giving nextAfter, which is a commonly used IEEE function not
otherwise available).
The Prelude is wrong in two ways with Floats/Doubles:
(1) It thinks Float and Double are continuous types.
(2) It doesn't say what happens when you do
succ(1.0e20) (assuming 1.0e20 is too big for Int).
I wonder if anyone can guess what answer Hugs gives for
"succ 1.0e20" ?
Solution - remove the current definitions of Enum and replace
with the simple mathematical one . . .
Re: Enum instance for Ratio
George Russell ([EMAIL PROTECTED]) wrote:
: A logical definition of Enum (to me wearing a mathematical hat)
: would be
:
: succ x = min { y | y x}
:
Wouldn't that make Enum depend on Ord?
Doesn't seem to make sense if classes are
enumerable but not comparable.
Regards,
Marc
