<div dir="ltr">Joachim:<div><br></div><div>I do think that a class is needed. The IEEE754 is actually quite agnostic about floating-point types. What IEEE754 says about floats are the sizes of the exponent and the mantissa; let's call them E and M for short. Then, one can define a floating-point type for each combination of E and M, both of which are at least 2. The resulting type will fit into E+M+1 bits.</div><div><br></div><div>We have:<br></div><div><br></div><div>        -  "Float" is  E=8, M=23. (And thus fits into a 32 bit machine word with the sign bit.)</div><div>        -  "Double" is E=11, M=52. (And thus fits into a 64 bit machine word with the sign bit.)</div><div><br></div><div>(In fact IEEE754 defines single/double precision to have at least those E/M values, but allows for larger. But let's ignore that for a moment.)</div><div><br></div><div>You can see that the next thing in line is going to be something that fits into 128 bits, also known as quad-precision. (Where E=15, M=112, plus 1 for the sign-bit.)</div><div><br></div><div>If we get type-literals into Haskell proper, then these types can all be nicely represented as "FP e m" for numbers e, m >= 2.</div><div><br></div><div>It just happens that Float/Double are what most hardware implementations support "naturally," but all IEEE-754 operations are defined for all precisions, and I think it would make sense to capture this nicely in Haskell, much like we have Int8, Int16, Int32 etc, and have them instances of this new class.</div><div><br></div><div>So, I'm quite against creating "fmaFloat"/"fmaDouble" etc.; but rather collect all these in a true IEEE754 arithmetic class. Float and Double will be the two instances for today, but one can easily see the extension to other variants in the future. (C already supports long-double to an extent, so that's missing in Haskell; as one sticking point.)</div><div><br></div><div>This class should also address rounding-modes, as almost all float-operations only make sense in the context of a rounding mode. The design space there is also large, but that's a different discussion.</div><div><br></div><div>-Levent.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 4, 2015 at 1:14 AM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
<br>
Am Sonntag, den 03.05.2015, 14:11 -0700 schrieb Levent Erkok:<br>
<br>
> Based on this analysis, I'm withdrawing the original proposal. I think<br>
> fma and other floating-point arithmetic operations are very important<br>
> to support properly, but it should not be done by tacking them on to<br>
> Num or RealFloat; but rather in a new class that also considers<br>
> rounding-mode properly.<br>
><br>
</span>does it really have to be a class? How much genuinely polymorphic code<br>
is there out there that yet requires this precise handling of precision?<br>
<br>
Have you considered adding it as monomorphic functions fmaDouble,<br>
fmaFloat etc. on hackage, using FFI? Then those who need these functions<br>
can start to use them.<br>
<br>
Furthermore you can start getting the necessary primops supported in<br>
GHC, and have your library transparently use them when available.<br>
<br>
And only then, when we have the implementation in place and actual<br>
users, we can evaluate whether we need an abstract class for this.<br>
<br>
<br>
Greetings,<br>
Joachim<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Joachim “nomeata” Breitner<br>
  <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a> • <a href="http://www.joachim-breitner.de/" target="_blank">http://www.joachim-breitner.de/</a><br>
  Jabber: <a href="mailto:nomeata@joachim-breitner.de">nomeata@joachim-breitner.de</a>  • GPG-Key: 0xF0FBF51F<br>
  Debian Developer: <a href="mailto:nomeata@debian.org">nomeata@debian.org</a><br>
</font></span><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto: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><br></div>