Proposal: Add "fma" to the RealFloat class

[David Feuer]

We have (almost) no tradition of using CPU instruction names for our own
function, and I don't see why now is the time to start. To take a recent
example, we have countLeadingZeros and countTrailingZeros rather than clz,
ctz, ctlz, cttz, bsf, bsr, etc. We also have popCount instead of popcnt,
and use shiftR and shiftL instead of things like shl, shr, sla, sal, sra,
sar, etc. Thus I am -1 on calling this thing fma. multiplyAdd seems more
reasonable to me.

On Sun, May 3, 2015 at 3:42 AM, Takenobu Tani <takenobu.hs at gmail.com> wrote:

> Hi,
>
> little information.
>
> General CPUs use term of "FMA" for "Mul + Add" operation
> and implement special instructions.
>
> x86(AMD64, Intel64) has FMA instructions:
>   FMADD132PD, ...
>
> ARM has FMA instructions:
>   VMLA, ...
>
>
> In DSP culture, it's called "MAC(Multiply and Accumulator)".
> Traditional DSPs have MAC(Multiply and Accumulator) instructions:
>
> TI's C67 has MAC instructions:
>   MAC, ...
>
>
> If you map "fma" function to cpu's raw instruction,
> be careful for rounding and saturation mode.
>
>
> BTW, "FMA" operation is defined in IEEE754-2008 standard.
>
>
> Regards,
> Takenobu
>
> 2015-04-29 18:19 GMT+09:00 Henning Thielemann <
> lemming at henning-thielemann.de>:
>
>>
>> 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'.
>>
>>  "fma" (a.k.a. fused-multiply-add) is one of those functions; which is
>>> the workhorse in many HPC applications.
>>> The idea is to multiply two floats and add a third with just one
>>> rounding, and thus preserving more precision.
>>> There are a multitude of applications for this operation in engineering
>>> data-analysis, and modern processors
>>> come with custom implementations and a lot of hardware to support it
>>> natively.
>>>
>>
>> Ok, the proposal is about increasing precision. One could also hope that
>> a single fma operation is faster than separate addition and multiplication
>> but as far as I know, fma can even be slower since it has more data
>> dependencies.
>>
>>  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.
>>
>>
>>  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.
>>
>>
>>  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).
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> 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/4a6c7d87/attachment.html>