Mitar wrote:
> > Why is 0/0 (which is NaN) > 1 == False and at the same time 0/0 < 1 ==
> > False. This means that 0/0 == 1? No, because also 0/0 == 1 == False.
> > I understand that proper mathematical behavior would be that as 0/0 is
> > mathematically undefined that 0/0 cannot be even compared to 1.
> > There is probably an implementation reason behind it, but do we really
> > want such "hidden" behavior? Would not it be better to throw some kind
> > of an error?

Like nearly all programming languages, Haskell implements
the standard IEEE behavior for floating point numbers.
That leads to some mathematical infelicities that are
especially irking to us in Haskell, but the consensus was
that it is best to follow the standard.

That is why NaN==NaN, NaN<NaN, and NaN>Nan are all False,

The special case of 1/0 is less clear, though. One might
decide that it should be an error rather than NaN, as some
languages have.

Cristian Baboi wrote:
> I think it's a bug.
> Here is why:
>
> let f = (\x -> x/0) in f 0 == f 0
>
> Referential transparency say that f 0 must equal to f 0, but in this case
> it is not. :-)

This does not violate referential transparency. f 0 is always
the same value. (==) is a function like any other; in this case,
it does not satisfy the mathematical laws we would like it
to in order to conform to standard floating point behavior.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to