Proposal: Add "fma" to the RealFloat class

[Edward Kmett]

On Wed, Apr 29, 2015 at 5:19 AM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Wed, 29 Apr 2015, Levent Erkok wrote:
>
>  This proposal is very much in the spirit of the earlier proposal on
>> adding new float/double functions; for
>> instance see here:
>> https://mail.haskell.org/pipermail/libraries/2014-April/022667.html
>>
>
> Btw. what was the final decision with respect to log1p and expm1?
>
> I suggest that the decision for 'fma' will be made consistently with
> 'log1p' and 'expm1'.


We decided to add them. Then we didn't do it in 7.10. I'll talk to Herbert
about how to proceed to get them in 7.12, though we may wait until we know
the outcome of this proposal and fuse the two together into one patch.


>  I think the proposal is rather straightforward, and should be
>> noncontroversial. To wit, we shall add a new
>> method to the RealFloat class:
>>
>>   class (RealFrac a, Floating a) => RealFloat a where
>>       ...
>>       fma :: a -> a -> a -> a
>>
>
>
> RealFloat excludes Complex.


Good point. If we wanted to we could push this all the way up to Num given
the operations involved, and I could see that you could benefit from it
there for types that have nothing to do with floating point, e.g. modular
arithmetic could get away with using a single 'mod'.

 There should be no default definitions; as an incorrect (two-rounding
>> version) would essentially beat the purpose of having fma in the first
>> place.
>>
>
> I just read again the whole expm1 thread and default implementations with
> possible loss of precision seem to be the best option. This way, one can
> mechanically replace all occurrences of (x*y+z) by (fma x y z) and will not
> make anything worse. Types with a guaranteed high precision should be put
> in a Fused class.


I argued rather strenuously for this for the expm1, log1p case, but wasn't
able to win folks over.

 While the name "fma" is well-established in the arithmetic/hardware
>> community and in the C-library, we can also go with "fusedMultiplyAdd," if
>> that is deemed more clear.
>>
>
> Although I like descriptive names, the numeric classes already contain
> mostly abbreviations (abs, exp, sin, tanh, ...) Thus I would prefer the
> abbreviation for consistency. Btw. in DSP 56002 the same operation is
> called MAC (multiply-accumulate).
>

I have no strong preference on the name. fusedMultiplyAdd has the benefit
that a non-domain-expert can figure it out. fma is traditional.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150429/7cd991f8/attachment-0001.html>