Re: [Haskell-cafe] Mystery of an Eq instance

i had a longer email written out, but decided a shorter one is better. I warmly point folks to use libs like the numbers package on hackage http://hackage.haskell.org/packages/archive/numbers/2009.8.9/doc/html/Data-N... it has some great alternatives to standard floats and doubles. the big caveat, however, is all your computations will be painfully slower by several orders of magnitude. And sometimes thats a great tradeoff! but sometimes it isnt. At the end of the day, you need to understand how to do math on the computer in a fashion that accepts that there is going to be finite precision. there is no alternative but to work with that understanding. numbers on the computer have many forms. and many tradeoffs. there is no one true single best approach. cheers -Carter On Sat, Sep 21, 2013 at 10:11 PM, Mike Meyer wrote:

...

On 2013-09-21 23:08, Mike Meyer wrote:

...

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

On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson wrote: pairs

...

According to Haskell NaN *is* a number.

Trying to make something whose name is "Not A Number" act like a number sounds broken from the start.

...

...

Eq and Ord are just the messengers. No. When we declare something an instance of Monad or Applicative (for example), we expect(*) that thing to obey certain laws. Eq and Ord instances for Float/Double do *not* obey the expected laws.

I just went back through the thread, and the only examples I could find where that happened (as opposed to where floating point calculations or literals resulted in unexpected values) was with NaNs. Just out of curiosity, do you know of any that don't involve NaNs?

Float violates the expected behavior of instances of - well, pretty much everything it's an instance of. Even if you restrict yourself to working with integer values that can be represented as floats. If we're going to start removing it as an instance for violating instance expectations, we might as well take it out of the numeric stack (or the language) completely.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe