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@gmail.com> wrote:
On Fri, May 1, 2015 at 5:52 PM, David Feuer <david.feuer@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@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries