I think there *should* be a default definition in terms of (+) and (*). A person who defines their own instance for their own purpose should be free to ignore this function if it's not needed for their specific application. On 29/04/15 10:21, Levent Erkok wrote:
This proposal is very much in the spirit of the earlier proposal on adding new float/double functions; for instance see here: https://mail.haskell.org/pipermail/libraries/2014-April/022667.html
"fma" (a.k.a. fused-multiply-add) is one of those functions; which is the workhorse in many HPC applications. The idea is to multiply two floats and add a third with just one rounding, and thus preserving more precision. There are a multitude of applications for this operation in engineering data-analysis, and modern processors come with custom implementations and a lot of hardware to support it natively.
I created a ticket along these lines already: https://ghc.haskell.org/trac/ghc/ticket/10364
Edward suggested that the matter should further be discussed here.
I think the proposal is rather straightforward, and should be noncontroversial. To wit, we shall add a new method to the RealFloat class:
class (RealFrac a, Floating a) => RealFloat a where ... fma :: a -> a -> a -> a
The intention is that
fma x y z = x * y + z
except the multiplication and addition are done infinitely-precisely, and then rounded only once; as opposed to two roundings as one would get with the above implementation. Most modern architectures directly support this operation so we can map it easily; and in case the architecture does not have it available, we can get it via the C-math libraries, where it appears under the names fma (the double version), and fmaf (the float version.)
There should be no default definitions; as an incorrect (two-rounding version) would essentially beat the purpose of having fma in the first place.
While the name "fma" is well-established in the arithmetic/hardware community and in the C-library, we can also go with "fusedMultiplyAdd," if that is deemed more clear.
Discussion period: 2 weeks.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries