Proposal: Add "fma" to the RealFloat class

[Levent Erkok]

Joachim:

I do think that a class is needed. The IEEE754 is actually quite agnostic
about floating-point types. What IEEE754 says about floats are the sizes of
the exponent and the mantissa; let's call them E and M for short. Then, one
can define a floating-point type for each combination of E and M, both of
which are at least 2. The resulting type will fit into E+M+1 bits.

We have:

        -  "Float" is  E=8, M=23. (And thus fits into a 32 bit machine word
with the sign bit.)
        -  "Double" is E=11, M=52. (And thus fits into a 64 bit machine
word with the sign bit.)

(In fact IEEE754 defines single/double precision to have at least those E/M
values, but allows for larger. But let's ignore that for a moment.)

You can see that the next thing in line is going to be something that fits
into 128 bits, also known as quad-precision. (Where E=15, M=112, plus 1 for
the sign-bit.)

If we get type-literals into Haskell proper, then these types can all be
nicely represented as "FP e m" for numbers e, m >= 2.

It just happens that Float/Double are what most hardware implementations
support "naturally," but all IEEE-754 operations are defined for all
precisions, and I think it would make sense to capture this nicely in
Haskell, much like we have Int8, Int16, Int32 etc, and have them instances
of this new class.

So, I'm quite against creating "fmaFloat"/"fmaDouble" etc.; but rather
collect all these in a true IEEE754 arithmetic class. Float and Double will
be the two instances for today, but one can easily see the extension to
other variants in the future. (C already supports long-double to an extent,
so that's missing in Haskell; as one sticking point.)

This class should also address rounding-modes, as almost all
float-operations only make sense in the context of a rounding mode. The
design space there is also large, but that's a different discussion.

-Levent.


On Mon, May 4, 2015 at 1:14 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
>
> Am Sonntag, den 03.05.2015, 14:11 -0700 schrieb Levent Erkok:
>
> > Based on this analysis, I'm withdrawing the original proposal. I think
> > fma and other floating-point arithmetic operations are very important
> > to support properly, but it should not be done by tacking them on to
> > Num or RealFloat; but rather in a new class that also considers
> > rounding-mode properly.
> >
> does it really have to be a class? How much genuinely polymorphic code
> is there out there that yet requires this precise handling of precision?
>
> Have you considered adding it as monomorphic functions fmaDouble,
> fmaFloat etc. on hackage, using FFI? Then those who need these functions
> can start to use them.
>
> Furthermore you can start getting the necessary primops supported in
> GHC, and have your library transparently use them when available.
>
> And only then, when we have the implementation in place and actual
> users, we can evaluate whether we need an abstract class for this.
>
>
> Greetings,
> Joachim
>
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> 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/20150504/7559f4f9/attachment-0001.html>