[GHC] #10364: Feature request: Add support for FMA

[GHC]

#10364: Feature request: Add support for FMA
-------------------------------------+-------------------------------------
        Reporter:  lerkok            |                   Owner:  ekmett
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Core Libraries    |                 Version:  7.11
      Resolution:                    |                Keywords:  report-
Operating System:  Unknown/Multiple  |  impact
 Type of failure:  None/Unknown      |            Architecture:
      Blocked By:                    |  Unknown/Multiple
 Related Tickets:                    |               Test Case:
                                     |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by lerkok):

 There was quite a bit of discussion and feedback on the mailing list, that
 I very much appreciated. See here:

 https://mail.haskell.org/pipermail/libraries/2015-May/025597.html

 Based on the analysis, I think this proposal should be shelved for the
 time being. And thus, I'm closing this feature-request.

 For the record, I'm quoting the final message from the above discussion.

 {{{
 Thank you for all the feedback on this proposal. Based on the feedback, I
 came to conclude that the original idea did not really capture what I
 really was after, and hence I think this proposal needs to be shelved for
 the time being.

 I want to summarize the points made so far:

     * Almost everyone agrees that we should have this functionality
 available. (But see below for the direction I want to take it in.)
     * There's some disagreement on the name chosen, but I think this is
 less important for the time being.
     * The biggest gripe is where does "fma" really belong. Original
 suggestion was 'RealFloat', but people pointed 'Num' is just a good place
 as well.
     * Most folks want a default definition, and see "fma" as an
 optimization.

 It is these last two points actually that convinced me this proposal is
 not
 really what I want to have. I do not see "fma" as an optimization. In
 particular, I'd be very concerned if the compiler substituted "fma x y z"
 for "x*y+z". The entire reason why IEEE754 has an fma operation is because
 those two expressions have different values in general. By the same token,
 I'm also against providing a default implementation. I see this not as an
 increased-precision issue, but rather a semantic one; where "x*y+z" and
 "fma x y z" *should* produce two different values, per the IEEE754 spec.
 It's not really an optimization, but how floating-point values work. In
 that sense "fma" is a separate operation that's related to multiplication
 and addition, but is not definable in those terms alone.

 Having said that, it was also pointed out that for non-float values this
 can act as an optimization. (Modular arithmetic was given as an example.)
 I'd think that functionality is quite different than the original
 proposal,
 and perhaps should be tackled separately. My original proposal was not
 aiming for that particular use case.

 My original motivation was to give Haskell access to the floating-point
 circuitry that hardware-manufacturers are putting a lot of effort and
 energy into. It's a shame that modern processors provide a ton of
 instructions around floating-point operations, but such operations are
 simply very hard to use from many high-level languages, including Haskell.

 Two other points were raised, that also convinced me to seek an
 alternative
 solution:

    * Tikhon Jelvis suggested these functions should be put in a different
 class, which suggests that we're following IEEE754, and not some idealized
 model of numbers. I think this suggestion is spot on, and is very much in
 line with what I wanted to have.
    * Takebonu Tani kindly pointed that a discussion of floats in the
 absence of rounding-modes is a moot one, as the entire semantics is based
 on rounding. Haskell simply picks "RoundNearestTiesToEven," but there are
 4
 other rounding modes defined by IEEE754, and I think we need a way to
 access those from Haskell in a convenient way.

 Based on this analysis, I'm withdrawing the original proposal. I think fma
 and other floating-point arithmetic operations are very important to
 support properly, but it should not be done by tacking them on to Num or
 RealFloat; but rather in a new class that also considers rounding-mode
 properly.

 The advantage of the "separate" class approach is, of course, I (or
 someone
 else) can create such a class and push it on to hackage, using FFI to
 delegate the task of implementation to the land-of-C, by supporting
 rounding modes and other floating-point weirdness appropriately. Once that
 class stabilizes and its details are ironed out, then we can imagine
 cooperating with GHC folks to actually bypass the FFI and directly
 generate
 native code whenever possible.

 This is the direction I intend to move on. Please drop me a line if you'd
 like to help out and/or have any feedback.
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10364#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler