Make Eq type class single method

[Sven Panne]

Am Mi., 20. Okt. 2021 um 20:57 Uhr schrieb Edward Kmett <ekmett at gmail.com>:

> Interestingly, I'd always assumed the answer was that all comparison
> functions should return False for NaN, and mentally just assumed that would
> include (/=). I never actually tested if (/=) returned False, but
> apparently this isn't the case. [...]
>

NaN is the only value where the result of "x == x" is *swapped*. The
reasoning behind this by Kahan himself in e.g.
https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF:

Were there no way to get rid of NaNs, they would be as useless as
> Indefinites on CRAYs; as soon as one were encountered, computation would be
> best stopped rather than continued for an indefinite time to an Indefinite
> conclusion. That is why some operations upon NaNs must deliver non-NaN
> results. Which operations? Disagreements about some of them are inevitable,
> but that grants no license to resolve the disagreements by making arbitrary
> choices. Every real ( not logical ) function that produces the same
> floating-point result for all finite and infinite numerical values of an
> argument should yield the same result when that argument is NaN. ( Recall
> hypot above.) The exceptions are C predicates “ x == x ” and “ x != x ”,
> which are respectively 1 and 0 for every infinite or finite number x but
> reverse if x is Not a Number ( NaN ); these provide the only simple
> unexceptional distinction between NaNs and numbers in languages that lack a
> word for NaN and a predicate IsNaN(x). Overoptimizing compilers that
> substitute 1 for x == x violate IEEE 754.


IEEE 754 Wonderland... :-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/1844b067/attachment-0001.html>