Proposal: Add "fma" to the RealFloat class

[Carter Schonwald]

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

> On Sun, May 3, 2015 at 4:11 PM, Levent Erkok <erkokl at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150503/3a617db0/attachment-0001.html>