Hi Haskellers, assuming that the type class "Enum" represents enumeration types, there are two questions for me: (1) What is the justification for the types "Float" and "Double" to be members of the type class "Enum"? This might induce students to use floating point values as counters in arithmetic sequences. (2) Why not make tuples of bounded enumeration types themselves bounded enumeration types? E.g., [(False,False)..(True,True)] could evaluate to [(False,False),(False,True),(True,False),(True,True)] and it is comprehensible since the ordering in the sequence equals the lexicographic ordering imposed on tuple comparison. Cheers Christoph
"Ch. A. Herrmann" wrote:
(1) What is the justification for the types "Float" and "Double" to be members of the type class "Enum"? This might induce students to use floating point values as counters in arithmetic sequences.
And what's wrong with that? If the students are using are using values like 0.1 and expecting it to be represented exactly then they should have some lectures about floating point arithmetic. I've heard your complaint before, but I can't really understand why removing Float and Double from Enum would make Haskell any better for beginners. These two type have complicated properties, and to use them correctly you have to know about them. It's something you have to learn sooner or later. (In the the olden day when I had my first CS course we were told about it very early.) -- Lennart
Lennart Augustsson writes:
"Ch. A. Herrmann" wrote:
(1) What is the justification for the types "Float" and "Double" to be members of the type class "Enum"? This might induce students to use floating point values as counters in arithmetic sequences.
And what's wrong with that? If the students are using are using values like 0.1 and expecting it to be represented exactly then they should have some lectures about floating point arithmetic.
Real numbers (which floating point numbers are trying to be) are not enumerable (that is, they cannot be placed in a one-one correspondence with the integers).
I've heard your complaint before, but I can't really understand why removing Float and Double from Enum would make Haskell any better for beginners. These two type have complicated properties, and to use them correctly you have to know about them. It's something you have to learn sooner or later. (In the the olden day when I had my first CS course we were told about it very early.)
I don't see it as a matter of ease of understanding for beginners. How can floating point numbers be meaningfully enumerated (they could be enumerated by treating their binary representation as an integer, but that is not meaningful) ? What is the "successor" of pi ? Tim -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin
On Tue, Oct 23, 2001 at 07:32:58PM +1000, Tim Barbour wrote:
Lennart Augustsson writes:
"Ch. A. Herrmann" wrote:
(1) What is the justification for the types "Float" and "Double" to be members of the type class "Enum"? This might induce students to use floating point values as counters in arithmetic sequences.
And what's wrong with that? If the students are using are using values like 0.1 and expecting it to be represented exactly then they should have some lectures about floating point arithmetic.
Real numbers (which floating point numbers are trying to be) are not enumerable (that is, they cannot be placed in a one-one correspondence with the integers).
I've heard your complaint before, but I can't really understand why removing Float and Double from Enum would make Haskell any better for beginners. These two type have complicated properties, and to use them correctly you have to know about them. It's something you have to learn sooner or later. (In the the olden day when I had my first CS course we were told about it very early.)
I don't see it as a matter of ease of understanding for beginners. How can floating point numbers be meaningfully enumerated (they could be enumerated by treating their binary representation as an integer, but that is not meaningful) ? What is the "successor" of pi ?
I think the problem is that Enum in haskell means not only enumerable types, but types which have enumerable subsets when taken with an incrementer. which the reals satisfy. this can be demonstrated by things like [1.0, 1.1 ..] which is obviously equinumerous to the integers. I think the confusion comes from the fact that Enum is a misnomer, it does not necisarilly imply the type is countable, just that we can create meaningful countable subsets.... now whether that is a good idea is a different question. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@repetae.net ---------------------------------------------------------------------------
John> I think the problem is that Enum in haskell means not only John> enumerable types, but types which have enumerable subsets when John> taken with an incrementer. which the reals satisfy. This is a good justification. John> this can be demonstrated by things like [1.0, 1.1 ..] which is John> obviously equinumerous to the integers. I'd prefer to write [ 1.0 + fromIntegral i / 10 | i<-[0..n] ] since you can be sure that the list has (n+1) elements (if n>=0). Cheers Christoph
Tim Barbour wrote:
Lennart Augustsson writes:
"Ch. A. Herrmann" wrote:
(1) What is the justification for the types "Float" and "Double" to be members of the type class "Enum"? This might induce students to use floating point values as counters in arithmetic sequences.
And what's wrong with that? If the students are using are using values like 0.1 and expecting it to be represented exactly then they should have some lectures about floating point arithmetic.
Real numbers (which floating point numbers are trying to be) are not enumerable (that is, they cannot be placed in a one-one correspondence with the integers).
But belonging to the Enum class does not mean that all the elements of the type can be enumerated (so maybe the name of the class is wrong). The Enum class has a number of operations that are very useful even for real numbers (not that Haskell has real numbers). -- Lennart
"Lennart" == Lennart Augustsson <lennart@augustsson.net> writes:
Lennart> "Ch. A. Herrmann" wrote: >> (1) What is the justification for the types "Float" and "Double" >> to be members of the type class "Enum"? This might induce >> students to use floating point values as counters in arithmetic >> sequences. Lennart> And what's wrong with that? If the students are using are Lennart> using values like 0.1 and expecting it to be represented Lennart> exactly then they should have some lectures about floating Lennart> point arithmetic. The point is that students might use the fact that Float and Double are in type class Enum as a justification to use it in practice, e.g., to avoid an Int->Float conversion. Maybe one can even prove that approximation errors will not harm in a particular situation. The question is whether a language should impose a style that protects programmers from taking such risks, and Haskell is a language that uses to follow this direction. Lennart> I've heard your complaint before, but I Lennart> can't really understand why removing Float and Double Removing them would possibly cause problems with existing programs and this is definitely not my aim. However, it'll make sense to think about long-term improvements. I wouldn't call Float and Double enumeration types. Maybe, a just misunderstood what Enum means. Cheers Christoph
On Tue, Oct 23, 2001 at 12:27:37PM +0200, Ch. A. Herrmann wrote:
Removing them would possibly cause problems with existing programs and this is definitely not my aim. However, it'll make sense to think about long-term improvements. I wouldn't call Float and Double enumeration types. Maybe, a just misunderstood what Enum means.
At a first glance, I would suppose than the construction [a,b..{,c}] is valid not only for Enum classes, but also for any Num class (any which have (+) operation). I woud say it is quite naturally. I don't know if it possible now to define the same operation (enumFromThen) for two classes, but newcoming advances about polymorphism could enable this. Anyway, haskell world (as I could notice) would not be surprised by this little incompatibility. Max.
"Ch. A. Herrmann" wrote:
"Lennart" == Lennart Augustsson <lennart@augustsson.net> writes:
Lennart> "Ch. A. Herrmann" wrote: >> (1) What is the justification for the types "Float" and "Double" >> to be members of the type class "Enum"? This might induce >> students to use floating point values as counters in arithmetic >> sequences.
Lennart> And what's wrong with that? If the students are using are Lennart> using values like 0.1 and expecting it to be represented Lennart> exactly then they should have some lectures about floating Lennart> point arithmetic.
The point is that students might use the fact that Float and Double are in type class Enum as a justification to use it in practice, e.g., to avoid an Int->Float conversion.
What I was trying to say is that if you are using floating point numbers you should have some clue what you are doing. This goes for doing conversions Int->Float (a suspicious operation since you might loose precision) or using an operation in Enum. As I said, floating point types are very complicated and should not be used without some knowledge if you care about the result. (Rational and Integer, on the other hand, are very well behaved types.)
Removing them would possibly cause problems with existing programs and this is definitely not my aim. However, it'll make sense to think about long-term improvements. I wouldn't call Float and Double enumeration types. Maybe, a just misunderstood what Enum means.
Yes, Enum is a bad name. -- Lennart
participants (5)
-
Ch. A. Herrmann -
John Meacham -
Lennart Augustsson -
Max Kirillov -
Tim Barbour