[Haskell-cafe] Mystery of an Eq instance

[Carter Schonwald]

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-Number-BigFloat.html

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 <mwm at mired.org> wrote:

> On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson <spam at scientician.net>
> 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
> 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.
>
>     <mike
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130921/92ec6215/attachment.htm>