.... how would you have an implementation of finite precision floating point that has the "expected" exact algebraic laws for * and +?

I would argue that Float and Double do satisfy a form of the standard algebric laws where equality is approximate. 

eg  (a+(b+c)) - ((a+b)+c) <= \epsilon, where epsilon  is some constant multiple of max(ulp(a),ulp(b),ulp(c)).
(a similar idea applies to pretty much any other algebraic law you can state, such as distributivity etc)

I do think that it'd be useful if the RealFloat class provided an ulp function (unit of least precision), which is available as part of any IEEE compliant c float library.

there are MANY computable number represntations where the *exact* algebraic laws dont hold, but this *approximate* form which provides some notion of bounded forwards/backwards relative/absolute error bound guarantee in a particularly strong way.


i think we should figure out articulating laws that play nice for both the *exact* and *approximate* universes.  the

On Sun, May 3, 2015 at 7:05 PM, Mike Meyer <mwm@mired.org> wrote:
On Sun, May 3, 2015 at 4:11 PM, Levent Erkok <erkokl@gmail.com> wrote:
   * Tikhon Jelvis suggested these functions should be put in a different class, which suggests that we're following IEEE754, and not some idealized model of numbers. I think this suggestion is spot on, and is very much in line with what I wanted to have.

This is very much in line with a suggestion I've been toying with for
a long time. Basically, we have three different ideas for how floats
should behave, and the current implementation isn't any of them. So
I've been thinking that we ought to deal with this by moving Float out
of Prelude - or at least large chunks of it.

The three different models are:

1) Real numbers. We aren't going to get those.

2) IEEE Floats. This is what we've got, except as noted, there are
   lots of things that come with this that we don't provide.

3) Floats that obey the laws of Num. We don't get that, mostly because
   getting #2 breaks things.

The breakage of #3 causes people creates behavior that's surprising -
at least to people who aren't familiar with IEEE Floats.

So the proposal I've been toying with was something along the lines of
breaking RealFloat up along class lines. Those classes where RealFloat
obeyed the class laws and IEEE Float behavior would stay in
RealFloat. The rest would move out, and could be gotten by importing
either Data.Float.IEEE or Data.Float.Num (or some such).

Ideally, this will leave enough floating point behavior in the Prelude
that doing simple calculations would just work - at least as well as
it ever did, anyway. When you start doing things that can currently
generate surprising results, you will need to import one of the two
options. Figuring out which one means there's a chance you'll also
figure out why you sometimes get those surprising results.

       <mike


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries