<div dir="ltr">The main problem that I find in practice with the 'just exile it to another class' argument is that it creates a pain point. Do you implement against the worse implementations of exp or do they use the specialized class that provides harder guarantees for expm1 to avoid destroying all precision very near 1? It means that anything that builds on top of the abstraction you provide gets built two ways at least. <div><br></div><div>I wound up with a lot of code that was written against Monad and Functor separately and spent much of my time dealing with nonsensical "made up" organization issues like "is this version the liftM-like one or the fmap-like one?" If it is in the class then folks can just reach out and use it. (<$) being directly in Functor means you can just reach for it and get better sharing when you 'refill' a functor with a constant. If it was exiled to some other place, there'd always the worry about of whether you should implement for portability or precision and you'll never get to stop thinking about it.</div><div><br></div><div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 2:00 PM, Tikhon Jelvis <span dir="ltr"><<a href="mailto:tikhon@jelv.is" target="_blank">tikhon@jelv.is</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><div><div>Would it make sense to create a new class for operations like fma that has accuracy guarantees as part of its typeclass laws? Or would managing a bunch of typeclasses like that create too much syntactic, conceptual or performance overhead for actual use?<br><br></div>To me, that seems like it could be better than polluting Num—which, after all, features prominently in the Prelude—but it might make for worse discoverability.<br><br></div>If we do add it to Num, I strongly support having a default implementation. We don't want to make implementing a custom numeric type any more difficult than it has to be, and somebody unfamiliar with fma would just manually implement it without any optimizations anyhow or just leave it out, incomplete instantiation warnings nonwithstanding. Num is already a bit to big for casual use (I rarely care about signum and abs myself), so making it *bigger* is not appealing.<br><br></div>Personally, I'm a bit torn on the naming. Something like mulAdd or fusedMultiplyAdd is great for non-experts, but it feels like fma is something that we only expect experts to care about, so perhaps it's better to name it in line with their expectations.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 10:52 AM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I'm somewhat opposed to the Num class in general, and very much opposed to calling floating point representations "numbers" in particular. How are they numbers when they don't obey associative or distributive laws, let alone cancellation, commutativity, ....? I know Carter disagrees with me, but I'll stand my ground, resolute! I suppose adding some more nonsense into the trash heap won't do too much more harm, but I'd much rather see some deeper thought about how we want to deal with floating point.</p><div><div>
<div class="gmail_quote">On May 1, 2015 1:35 PM, "adam vogt" <<a href="mailto:vogt.adam@gmail.com" target="_blank">vogt.adam@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The Num class is defined in GHC.Num, so Prelude could import GHC.Num hiding (fma) to avoid having another round of prelude changes breaking code.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 12:44 PM, Twan van Laarhoven <span dir="ltr"><<a href="mailto:twanvl@gmail.com" target="_blank">twanvl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree that Num is the place to put this function, with a default implementation. In my mind it is a special combination of (+) and (*), which both live in Num as well.<br>
<br>
I dislike the name fma, as that is a three letter acronym with no meaning to people who don't do numeric programming. And by putting the function in Num the name would end up in the Prelude.<br>
<br>
For further bikeshedding: my proposal for a name would mulAdd. But fusedMulAdd or fusedMultiplyAdd would also be fine.<span><font color="#888888"><br>
<br>
<br>
Twan</font></span><div><div><br>
<br>
On 2015-04-30 00:19, Ken T Takusagawa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 29 Apr 2015, Edward Kmett wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Good point. If we wanted to we could push this all the way up to Num given the operations<br>
involved, and I could see that you could benefit from it there for types that have nothing<br>
to do with floating point, e.g. modular arithmetic could get away with using a single 'mod'.<br>
</blockquote>
<br>
I too advocate this go in Num.  The place I anticipate<br>
seeing fma being used is in some polymorphic linear algebra<br>
library, and it is not uncommon (having recently done this<br>
myself) to do linear algebra on things that aren't<br>
RealFloat, e.g., Rational, Complex, or number-theoretic<br>
fields.<br>
<br>
--ken<br>
_______________________________________________<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>
</blockquote>
_______________________________________________<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>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<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></blockquote></div>
</div></div><br>_______________________________________________<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></blockquote></div><br></div>
</div></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>