Proposal: Add "fma" to the RealFloat class

[Merijn Verstraaten]

I would suggest adding the relevant high-precision versions as direct functions on Float/Double and then add the "better" versions as part of Num as was suggested. Anyone who *needs* the precision can then get it by using the functions directly and forcing a specific type (since I don't think polymorphic code and this sort of precision demands fit well together). This way it's *possible* to write code with the required precision for Float/Double and anyone using Num gets an optional precision boost.

Cheers,
Merijn

> On 4 May 2015, at 12:00, Yitzchak Gale <gale at sefer.org> wrote:
> 
> Levent Erkok wrote:
>> ...I think this proposal needs to be shelved for the time being.
> 
> Nevertheless, I vote for doing it now.
> 
> A better, more featureful, and more principled approach to
> FP is definitely needed. It would be great if we could tackle
> that and finally solve it - and I think we can. But that's a
> huge issue which has been discussed extensively in the
> past, and orthogonal to Levant's proposal.
> 
> In the meantime, adding new functions that provide access
> to more FP functionality without adding any significant
> new weirdness are welcome, and will naturally flow into
> whatever future solution to the broader FP issue we
> implement.
> 
> It makes little difference whether or not we provide a bad
> but working default implementation; my vote is to
> provide it. It will prevent breakage in case someone
> happens to have implemented a manual RealFloat instance
> out there somewhere, and it won't affect the standard
> instances because we'll provide implementations for
> those. Obviously a clear explanatory Haddock comment
> would be required. Even better, trigger a warning if an
> instance does not provide an explicit implementation, but
> I'm not sure if that's possible. I'm still in favor of doing
> Levant's proposal now even if the consensus is to omit
> the default.
> 
> I vote for the usual practice of a human-readable
> name, but don't let bikeshedding hold this back.
> 
> Thanks,
> Yitz
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150504/79459ae6/attachment.sig>