Hi
Bringing up an old thread, but this issue just bit me in real life:
[0, 2.5 .. 3.75 ] = [0, 2.5, 5.0]
I was comparative testing some C++ and some Haskell, and its a shame
when its the Haskell that is clearly wrong! I don't think any end
decision was reached in this thread, but I think this is
Malcolm Wallace wrote:
Phil proposes that, although retaining the instances of Enum for Float
and Double, we simplify the definitions of the numericEnumFrom family:
numericEnumFromThenTo :: (Fractional a, Ord a) => a -> a -> a -> [a]
numericEnumFrom = iterate (+1)
numericEnumFr
On 15/10/2008, at 20:41, Malcolm Wallace wrote:
Phil proposes that, although retaining the instances of Enum for Float
and Double, we simplify the definitions of the numericEnumFrom family:
numericEnumFromThenTo :: (Fractional a, Ord a) => a -> a -> a ->
[a]
numericEnumFrom = it
David Roundy <[EMAIL PROTECTED]> 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 t
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 <
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 te
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].
For example, anything in the neighborhood of this is just unfair, even
if i
Here's a counter-proposal:
numericEnumFromThenTo :: RealFloat a => a -> a -> a -> [a]
numericEnumFrom 0 = map fromInteger [1..]
numericEnumFrom n = map ((n+).fromInteger) [1..]
numericEnumFromThen n m = map (\x -> n+fromInteger x*(m-n)) [1..]
numericEnumFromTo n m = takeWhile (<= m*(1 + epsilon
On Wed, 2008-10-15 at 11:25 +0100, Mitchell, Neil wrote:
> Hi Malcolm,
>
> The current behaviour does sound like a bug, and the revised behaviour
> does sound like a fix - and one that has a sensible explanation if
> people trip over it. In general having floating point be a member of
> classes su
I'm sorry, but people who write [0.0,0.1 .. x] where x is a multiple
of 0.1 get exactly what they deserve if x is not included. Floating
point numbers are not the real numbers, and the sooner they learn that
the better. We can fudge this all we like, but 0.1 is never going to
be exactly represent
On Wed, Oct 15, 2008 at 10:41:25AM +0100, Malcolm Wallace wrote:
> Dear Haskell-Primers (and libraries).
>
> Recently, Phil Wadler has pointed out a weird anomaly in the Haskell'98
> Prelude, regarding numeric enumerations for Floats/Doubles:
>
> Prelude> [0, 0.3 .. 1.1]
> [0.0,0.3,0.6,0.89
Hi Malcolm,
The current behaviour does sound like a bug, and the revised behaviour
does sound like a fix - and one that has a sensible explanation if
people trip over it. In general having floating point be a member of
classes such as Eq has some obvious problems, but I realise is a
necessity for
12 matches
Mail list logo
