<div dir="ltr">Quite a bit actually.<div><br></div><div>Consider something like:</div><div><br></div><div><a href="http://hackage.haskell.org/package/ad-4.2.1.1/docs/src/Numeric-AD-Rank1-Newton.html#gradientDescent">http://hackage.haskell.org/package/ad-4.2.1.1/docs/src/Numeric-AD-Rank1-Newton.html#gradientDescent</a><br></div><div><br></div><div>The step function in there could be trivially adapted to using fused multiplyAdd and precision would just improve. If such a member _were_ in Num, I'd use it in a heartbeat there. If it were in an extra class? I'd have to make a second copy of the function to even try to see the precision win.</div><div><br></div><div>Most of my numeric code is generic in some fashion, working over vector spaces or simpler number types just as easily.</div><div><br></div><div>As this proposal has been withdrawn, the point is more or less moot for now.</div><div><br></div><div>-Edward</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 4, 2015 at 4:14 AM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
<br>
Am Sonntag, den 03.05.2015, 14:11 -0700 schrieb Levent Erkok:<br>
<br>
> Based on this analysis, I'm withdrawing the original proposal. I think<br>
> fma and other floating-point arithmetic operations are very important<br>
> to support properly, but it should not be done by tacking them on to<br>
> Num or RealFloat; but rather in a new class that also considers<br>
> rounding-mode properly.<br>
><br>
</span>does it really have to be a class? How much genuinely polymorphic code<br>
is there out there that yet requires this precise handling of precision?<br>
<br>
Have you considered adding it as monomorphic functions fmaDouble,<br>
fmaFloat etc. on hackage, using FFI? Then those who need these functions<br>
can start to use them.<br>
<br>
Furthermore you can start getting the necessary primops supported in<br>
GHC, and have your library transparently use them when available.<br>
<br>
And only then, when we have the implementation in place and actual<br>
users, we can evaluate whether we need an abstract class for this.<br>
<br>
<br>
Greetings,<br>
Joachim<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Joachim “nomeata” Breitner<br>
  <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a> • <a href="http://www.joachim-breitner.de/" target="_blank">http://www.joachim-breitner.de/</a><br>
  Jabber: <a href="mailto:nomeata@joachim-breitner.de">nomeata@joachim-breitner.de</a>  • GPG-Key: 0xF0FBF51F<br>
  Debian Developer: <a href="mailto:nomeata@debian.org">nomeata@debian.org</a><br>
</font></span><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>