Re: Proposal: Add "fma" to the RealFloat class

.... 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 wrote:

On Sun, May 3, 2015 at 4:11 PM, Levent Erkok 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.

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