On Tue, Sep 20, 2011 at 12:47 PM, Paterson, Ross <r.pater...@city.ac.uk> wrote: > Daniel Fischer writes: >>> A numeric range [a..a+n] might be expected >>> to have a+n+1 elements, but that doesn't hold either for Float and >>> Double. I think Enum for floating point values is broken >> >>Yes, it is. Like Eq and Ord. > > .. only more so. And the brokenness has infected Rational: try > > [1,3..20]::[Rational]
I actually think the brokenness of Ord for floating point values is worse in many ways, as demonstrated by the ability to insert a value into a Data.Set.Set and have other values "disappear" from the set as a result. Getting an unexpected element in a list doesn't really seem as bad as silently corrupting entire data structures. For numeric ranges of fractional values, I expect that what one typically wants is either "the two end points, and N intermediate values evenly spaced" or "the starting value, and successive increments up to some cut-off", with the default increment being 1 or -1 as appropriate. The current Enum instance splits the difference and gets you some of both, except that you might get the wrong values or something past the cut-off. Similarly, the current Ord instance splits the difference between a coherent total order (what Ord instances should be) and the semantically correct partial order (what floats should have, as defined in the IEEE standard). - C. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
