<div dir="ltr">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 3, 2015 at 3:42 AM, Takenobu Tani <span dir="ltr"><<a href="mailto:takenobu.hs@gmail.com" target="_blank">takenobu.hs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>little information.</div><div><br></div><div>General CPUs use term of "FMA" for "Mul + Add" operation</div><div>and implement special instructions.</div><div><br></div><div>x86(AMD64, Intel64) has FMA instructions:</div><div>  FMADD132PD, ...</div><div><br></div><div>ARM has FMA instructions:</div><div>  VMLA, ...</div><div><br></div><div><br></div><div>In DSP culture, it's called "MAC(Multiply and Accumulator)".</div><div>Traditional DSPs have MAC(Multiply and Accumulator) instructions:</div><div><br></div><div>TI's C67 has MAC instructions:</div><div>  MAC, ...</div><div><br></div><div><br></div><div>If you map "fma" function to cpu's raw instruction,</div><div>be careful for rounding and saturation mode.</div><div><br></div><div><br></div><div>BTW, "FMA" operation is defined in IEEE754-2008 standard.</div><div><br></div><div><br></div><div>Regards,</div><div>Takenobu</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2015-04-29 18:19 GMT+09:00 Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span><br>
On Wed, 29 Apr 2015, Levent Erkok wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This proposal is very much in the spirit of the earlier proposal on adding new float/double functions; for<br>
instance see here: <a href="https://mail.haskell.org/pipermail/libraries/2014-April/022667.html" target="_blank">https://mail.haskell.org/pipermail/libraries/2014-April/022667.html</a><br>
</blockquote>
<br></span>
Btw. what was the final decision with respect to log1p and expm1?<br>
<br>
I suggest that the decision for 'fma' will be made consistently with 'log1p' and 'expm1'.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"fma" (a.k.a. fused-multiply-add) is one of those functions; which is the workhorse in many HPC applications.<br>
The idea is to multiply two floats and add a third with just one rounding, and thus preserving more precision.<br>
There are a multitude of applications for this operation in engineering data-analysis, and modern processors<br>
come with custom implementations and a lot of hardware to support it natively.<br>
</blockquote>
<br></span>
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.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the proposal is rather straightforward, and should be noncontroversial. To wit, we shall add a new<br>
method to the RealFloat class:<br>
<br>
  class (RealFrac a, Floating a) => RealFloat a where<br>
      ...<br>
      fma :: a -> a -> a -> a<br>
</blockquote>
<br>
<br></span>
RealFloat excludes Complex.<span><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There should be no default definitions; as an incorrect (two-rounding version) would essentially beat the purpose of having fma in the first place.<br>
</blockquote>
<br></span>
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.<span><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
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).<br></div></div><span class="">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>