Dean Herington <[EMAIL PROTECTED]> writes:
> It's inconsistent to remove the "+1/2" for
> numericEnumFromTo but to leave the "+(n'-n)" for
> numericEnumFromThenTo. I think you probably mean to
> remove both (actually, all three).
You are right, what I meant is
numericEnumFromTo n m = takeWhile (<= m) (numericEnumFrom n)
numericEnumFromThenTo n n' m = takeWhile p (numericEnumFromThen n n')
where
p | n' >= n = (<= m)
| otherwise = (>= m)
> I wouldn't recommend these changes for Float and Double
> (the increments are there to account for arithmetic
> inexactness)
That's clear, but see below.
> (1) In section A (Standard Prelude), in the definition of
> `numericEnumFromThenTo`, change "n' > n" to "n' >= n", to
> agree with the last bullet in section 6.3.4.
Good point, also included in the above code.
George Russell <[EMAIL PROTECTED]> writes:
> Indeed I think the Haskell Library Report contains quite a
> few examples of floating point code which a numerical
> analyst would have written rather better. So I don't
> think it's good enough to treat every Float/Double
> operation as if it had an implicit "UNSAFE" flag
> indicating that the compiler was entitled to weird
> behaviour only comprehensible to experts, as seems to be
> the case with floating enumerations now.
Simon made clear that he wants to change as little as
possible. This area is inconsistent as a whole, and I agree
that the best solution would be to do away with the
'impossible' stuff at least (Float and Double): then every
user could define her Enum instance in the most appropriate
way, fuzzing with +epsilon or *(1+epsilon) or whatever. Or
simply doesn't use the nice syntax. In my opinion getting
elements MUCH greater than the upper limit is more confusing
than losing the last one, which is a familiar and well known
consequence of finite precision. And the above MUCH is very
hard to tell. Just think of [1%1..2], [1%2..2], [1%3..2],
etc. Which sequence is the first with three elements?
Currently the second.
For Floats my above argument is even less convincing. It's
impossible to do it right, but apparently we have to do
something. I vote for less magic (MUCH=0), so that the
resulting weirdness be comprehensible to more experts, not
only to the ones who know the language definition by heart.
Feri.
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
