Proposal: Add "fma" to the RealFloat class

[Carter Schonwald]

Agreed.  It will be a boon for dot product powered algorithms every where.

There's a valid argument for in parallel exploration of systematically
better abstractions for the future, but that shouldn't preclude making core
tooling and primops a bit better in time for 7.12

I'll start investigating adding the applicable primops to ghc on all
supported platforms.  Most of the widely used ones have direct instruction
support, but some may have to call out to the c fma, eg unregisterized
builds and perhaps x86_32 unless I'm mistaken on the latter.

On Monday, May 4, 2015, Merijn Verstraaten <merijn at inconsistent.nl> wrote:

> 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 <javascript:;>>
> 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 <javascript:;>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150504/9fb53bbd/attachment.html>