Agreed.  It will be a boon for dot product powered algorithms every where.  <div><br></div><div>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 <span></span>a bit better in time for 7.12</div><div><br></div><div>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.  <br><br>On Monday, May 4, 2015, Merijn Verstraaten <<a href="mailto:merijn@inconsistent.nl">merijn@inconsistent.nl</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Cheers,<br>
Merijn<br>
<br>
> On 4 May 2015, at 12:00, Yitzchak Gale <<a href="javascript:;" onclick="_e(event, 'cvml', 'gale@sefer.org')">gale@sefer.org</a>> wrote:<br>
><br>
> Levent Erkok wrote:<br>
>> ...I think this proposal needs to be shelved for the time being.<br>
><br>
> Nevertheless, I vote for doing it now.<br>
><br>
> A better, more featureful, and more principled approach to<br>
> FP is definitely needed. It would be great if we could tackle<br>
> that and finally solve it - and I think we can. But that's a<br>
> huge issue which has been discussed extensively in the<br>
> past, and orthogonal to Levant's proposal.<br>
><br>
> In the meantime, adding new functions that provide access<br>
> to more FP functionality without adding any significant<br>
> new weirdness are welcome, and will naturally flow into<br>
> whatever future solution to the broader FP issue we<br>
> implement.<br>
><br>
> It makes little difference whether or not we provide a bad<br>
> but working default implementation; my vote is to<br>
> provide it. It will prevent breakage in case someone<br>
> happens to have implemented a manual RealFloat instance<br>
> out there somewhere, and it won't affect the standard<br>
> instances because we'll provide implementations for<br>
> those. Obviously a clear explanatory Haddock comment<br>
> would be required. Even better, trigger a warning if an<br>
> instance does not provide an explicit implementation, but<br>
> I'm not sure if that's possible. I'm still in favor of doing<br>
> Levant's proposal now even if the consensus is to omit<br>
> the default.<br>
><br>
> I vote for the usual practice of a human-readable<br>
> name, but don't let bikeshedding hold this back.<br>
><br>
> Thanks,<br>
> Yitz<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'Libraries@haskell.org')">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br>
</blockquote></div>