[Haskell-cafe] Mystery of an Eq instance
Stijn van Drongelen
rhymoid at gmail.com
Sat Sep 21 10:46:25 CEST 2013
On Sat, Sep 21, 2013 at 10:26 AM, Mike Meyer <mwm at mired.org> wrote:
> On Sat, Sep 21, 2013 at 2:21 AM, Bardur Arantsson <spam at scientician.net>
> > On 2013-09-21 06:16, Mike Meyer wrote:
> > > The single biggest gotcha is that two calculations
> > > we expect to be equal often aren't. As a result of this, we warn
> > > people not to do equality comparison on floats.
> > The Eq instance for Float violates at least one expected law of Eq:
> > Prelude> let nan = 0/0
> > Prelude> nan == nan
> > False
> Yeah, Nan's are a whole 'nother bucket of strange.
> But if violating an expected law of a class is a reason to drop it as
> an instance, consider:
> Prelude> e > 0
> Prelude> 1 + e > 1
> Of course, values "not equal when you expect them to be" breaking
> equality means that they also don't order the way you expect:
> Prelude> e + e + 1 > 1 + e + e
> So, should Float's also not be an instance of Ord?
> I don't think you can turn IEEE 754 floats into a well-behaved numeric
> type. A wrapper around a hardware type for people who want that
> performance and can deal with its quirks should provide access to
> as much of the types behavior as possible, and equality comparison
> is part of IEEE 754 floats.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
I do have to agree with Damodar Kulkarni that different laws imply
different classes. However, this will break **a lot** of existing software.
If we would do this, only Eq and Ord need to be duplicated, as they cause
most of the problems. Qualified imports should suffice to differentiate
between the two.
import qualified Data.Eq.Approximate as A
import qualified Data.Ord.Approximate as A
main = print $ 3.16227766016837956 A.== 3.16227766016837955
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe