<p dir="ltr">On Sep 21, 2013 9:17 AM, "Bob Hutchison" <<a href="mailto:hutch-lists@recursive.ca">hutch-lists@recursive.ca</a>> wrote:<br>
> On 2013-09-21, at 4:46 AM, Stijn van Drongelen <<a href="mailto:rhymoid@gmail.com">rhymoid@gmail.com</a>> wrote:<br>
>> I do have to agree with Damodar Kulkarni that different laws imply different classes. However, this will break **a lot** of existing software.<br>
> You could argue that the existing software is already broken.</p>
<p dir="ltr">I'd argue that it's not all broken, and you're breaking it all. </p>
<p dir="ltr">>> 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.<br>
>> import qualified Data.Eq.Approximate as A<br>
>> import qualified Data.Ord.Approximate as A<br>
>><br>
>> main = print $ 3.16227766016837956 A.== 3.16227766016837955<br>
> As soon as you start doing computations with fp numbers things get much worse. </p>
<p dir="ltr">Exactly. The Eq and Ord instances aren't what's broken, at least when you're dealing with numbers (NaNs are another story). That there are pairs of non-zero numbers that when added result in one of the two numbers is broken. That addition isn't associative is broken. That expressions don't obey the substitution principle is broken. But you can't tell these things are broken until you start comparing values. Eq and Ord are just the messengers. <br>
</p>