<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 29, 2015 at 5:19 AM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
On Wed, 29 Apr 2015, Levent Erkok wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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'.</blockquote><div> </div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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.</blockquote><div><br></div><div>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'.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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.</blockquote><div><br></div><div>I argued rather strenuously for this for the expm1, log1p case, but wasn't able to win folks over.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote><div><br></div><div>I have no strong preference on the name. fusedMultiplyAdd has the benefit that a non-domain-expert can figure it out. fma is traditional.</div><div><br></div><div>-Edward</div></div></div></div>