Repair to floating point enumerations?

[Jon Fairbairn]

David Roundy <droundy at darcs.net> writes:

> On Thu, Oct 16, 2008 at 05:31:50PM -0400, Isaac Dupree wrote:
>> Christopher Lane Hinson wrote:
>>>
>>> I agree with David, we should be using multiplication, not addition.
>>> However, I think that under the law of least surprise, we should
>>> require that for all a,b,z:
>>>
>>> all (\x -> x >= a && x < z || x <= a && x > z) [a,b..z].
>>
>> so that [0,0.1..0.3] doesn't include the terminating value that's a
>> little more than the literal 0.3?
>
> We could do what octave appears to do, which is to set anything within
> the fudge factor (but greater than the upper bound) equal to the upper
> bound.  That seems like a reasonable option to me.

I've not been following this closely, but I've not seen a
clear definition of what this is all for.  Without that,
we're going to see a succession of fudges that will work for
some notions of what the notation means and fail for others.

Assuming z>=a, must the resulting list include a? include z
exactly when?  If a or z is a literal, does include here
mean "include the value represented by the literal" or some
other nearby value?  Must the step (l!!(i+1)-l!!i) always be
the same? Must it equal (b-a)? (I can even imagine that for
some applications, a list that looked like this: [0.0,
1.0e-2, 2.0e-2, 3.0e-2, 4.0e-2, 5.0e-2,
6.0000000000000005e-2, 7.0e-2, 8.0e-2, 9.0e-2,
9.999999999999999e-2, 0.10999999999999999, 0.11] would be
preferable to one that included only one of the last two
elements).

Whatever is decided for floats, the definition must be
consistent with that for discrete quantities. I'm not sure
this is possible. Since floating point numbers are full of
surprises for anyone who is used to real numbers (and even a
few for people who are quite familiar with floats), the
principle of least surprise would surely indicate no
instance of Enum for floats.

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk