Proposal: Add "fma" to the RealFloat class

[Levent Erkok]

I think `mulAdd a b c` should be implemented as `a*b+c` even for
Double/Float. It should only be an "optmization" (as in modular
arithmetic), not a semantic changing operation. Thus justifying the
optimization.

"fma" should be the "more-precise" version available for Float/Double. I
don't think it makes sense to have "fma" for other types. That's why I'm
advocating "mulAdd" to be part of "Num" for optimization purposes; and
"fma" reserved for true IEEE754 types and semantics.

I understand that Edward doesn't like this as this requires a different
class; but really, that's the price to pay if we claim Haskell has proper
support for IEEE754 semantics. (Which I think it should.) The operation is
just different. It also should account for the rounding-modes properly.

I think we can pull this off just fine; and Haskell can really lead the
pack here. The situation with floats is even worse in other languages. This
is our chance to make a proper implementation, and we have the right tools
to do so.

-Levent.

On Mon, May 4, 2015 at 10:58 AM, Artyom <yom at artyom.me> wrote:

>  On 05/04/2015 08:49 PM, Levent Erkok wrote:
>
> Artyom: That's precisely the point. The true IEEE754 variants where
> precision does matter should be part of a different class. What Edward and
> Yitz want is an "optimized" multiply-add where the semantics is the same
> but one that goes faster.
>
> No, it looks to me that Edward wants to have a more precise operation in
> Num:
>
> I'd have to make a second copy of the function to even try to see the
> precision win.
>
> Unless I'm wrong, you can't have the following things simultaneously:
>
>    1. the compiler is free to substitute *a+b*c* with *mulAdd a b c*
>    2. *mulAdd a b c* is implemented as *fma* for Doubles (and is more
>    precise)
>    3. Num operations for Double (addition and multiplication) always
>    conform to IEEE754
>
>  The true IEEE754 variants where precision does matter should be part of
> a different class.
>
> So, does it mean that you're fine with not having point #3 because people
> who need it would be able to use a separate class for IEEE754 floats?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150504/a83322e4/attachment.html>