Proposal: Add "fma" to the RealFloat class

[Carter Schonwald]

well said brandon.  FMA support is absolutely a mathematical accuracy and
 performance engineering thing (except when it hinder performance ).  It is
worth noting that most modern CPUS support several *different* versions of
the FMA operation, but thats beyond the scope / goal of this proposal I
think.

but yeah, for all of Num's warts, probably the right place to put it, with
a default implementation in terms of * and + (and compiler supplied primops
for applicable prelude types)

On Fri, May 1, 2015 at 2:11 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Fri, May 1, 2015 at 5:52 PM, David Feuer <david.feuer at gmail.com> wrote:
>
>> 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
>>
> TBH I think Num is a lost cause. If you want mathematical numbers, set up
> a parallel class instead of trying to force a class designed for numbers
> "in the wild" to be a pure theory class.
>
> This operation in particular is *all about* numbers in the wild --- it has
> no place in theory, it's an optimization for hardware implementations.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> 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/20150501/a77a5431/attachment.html>