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@mired.org> wrote:
On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson <spam@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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe