<div dir="ltr"><div class="gmail_extra"><div>On Sat, Sep 21, 2013 at 2:21 AM, Bardur Arantsson <<a href="mailto:spam@scientician.net">spam@scientician.net</a>> wrote:</div><div>> On 2013-09-21 06:16, Mike Meyer wrote:</div>
<div>> > The single biggest gotcha is that two calculations</div><div>> > we expect to be equal often aren't. As a result of this, we warn</div><div>> > people not to do equality comparison on floats.</div>
<div>> The Eq instance for Float violates at least one expected law of Eq:</div><div>> </div><div>> Prelude> let nan = 0/0</div><div>> Prelude> nan == nan</div><div>> False</div><div><br></div><div>
Yeah, Nan's are a whole 'nother bucket of strange.</div><div><br></div><div>But if violating an expected law of a class is a reason to drop it as</div><div>an instance, consider:</div><div><br></div><div>Prelude> e > 0</div>
<div>True</div><div>Prelude> 1 + e > 1</div><div>False</div><div><br></div><div style>Of course, values "not equal when you expect them to be" breaking</div><div>equality means that they also don't order the way you expect:</div>
<div><br></div><div>Prelude> e + e + 1 > 1 + e + e</div><div>True</div><div><br></div><div>So, should Float's also not be an instance of Ord?</div><div><br></div><div>I don't think you can turn IEEE 754 floats into a well-behaved numeric</div>
<div>type. A wrapper around a hardware type for people who want that</div><div>performance and can deal with its quirks should provide access to</div><div>as much of the types behavior as possible, and equality comparison</div>
<div>is part of IEEE 754 floats.</div><div><br></div><div> <mike</div><div><br></div></div></div>