Proposal: Add "fma" to the RealFloat class

[David Feuer]

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.
On May 1, 2015 1:35 PM, "adam vogt" <vogt.adam at gmail.com> wrote:

> 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.
>
>
>
> On Fri, May 1, 2015 at 12:44 PM, Twan van Laarhoven <twanvl at gmail.com>
> wrote:
>
>> 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.
>>
>> 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.
>>
>> For further bikeshedding: my proposal for a name would mulAdd. But
>> fusedMulAdd or fusedMultiplyAdd would also be fine.
>>
>>
>> Twan
>>
>>
>> On 2015-04-30 00:19, Ken T Takusagawa wrote:
>>
>>> On Wed, 29 Apr 2015, Edward Kmett wrote:
>>>
>>>  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'.
>>>>
>>>
>>> I too advocate this go in Num.  The place I anticipate
>>> seeing fma being used is in some polymorphic linear algebra
>>> library, and it is not uncommon (having recently done this
>>> myself) to do linear algebra on things that aren't
>>> RealFloat, e.g., Rational, Complex, or number-theoretic
>>> fields.
>>>
>>> --ken
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>>  _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> 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/e01a2793/attachment-0001.html>