Proposal (long term): Remove (/=) from Eq; change the semantics of (==) for floating point

Edward Kmett ekmett at
Thu Sep 25 15:30:51 UTC 2014

On Thu, Sep 25, 2014 at 5:38 AM, Herbert Valerio Riedel <hvr at> wrote:

> On 2014-09-25 at 05:25:02 +0200, David Feuer wrote:
> > As Edward Kmett explained to me, (/=) is currently needed in Eq to
> support
> > IEEE floating point semantics for (==) and (/=). As I see it, those
> > semantics are badly broken from the perspective of what Eq is supposed to
> > mean, and really should be supported using special functions (eqIEEE and
> > neqIEEE or whatever), whereas the most appropriate Eq instance for
> floating
> > point would be something more like
> If the Eq instance for Double is changed, what about its Ord instance
> then? Right now, (0/0::Double) is handled poorly for both Eq and Ord,
> resulting in Data.Map and other operations relying on Eq/Ord to behave
> weirdly when (0/0::Double) happens to be used as key.

If you go to use Doubles for keys in a Data.Map you'd have a whole host of
other problems.

Even if you had the instance proposed here, which makes it harder to work
nicely with underflow/overflow conditions on doubles, which are a far more
common going concern and motivate the IEEE design, you have an issue.

Notably, that if you compute the same number twice in different parts of
your program or even the same part at different times you can get different
answers due to intermediate value promotion in the FPU, etc.

That pretty much damns any attempt to use doubles for exact value-match key
lookup to unreliability or failure.

FWIW- I'm -1 on this proposal.


> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list