Proposal: Add log1p and expm1 to GHC.Float.Floating

[wren romano]

I can verify that these functions are essential for numerical work and
that, though horrible, the names are standard and expected. In the
logfloat package I link to libc in order to use them for precisely
this reason.

However, I'm not entirely sure how I feel about the proposal. There
are a number of other fused algorithms like log1mexp and log1pexp[1]
which are related to log1p/expm1, or like fma which often has cpu
support. These fused algorithms are just as important for numerical
work, but not included in the proposal. From the numerical side of
things I'm all for throwing in the whole kitchen sink, though from a
type class perspective I'm not sure. The real benefit of including
these things in the core libraries, IMO, would be to make them primops
which would reduce the overhead of using them. The type class layer
above the primops is just (much needed) sugar.

Also, as Scott Turner mentions, from the numerical perspective I'd
much rather know that a type has a correct (i.e., precise)
implementation of these fused algorithms than to just have a default
implementation which may be imprecise. Though this is more a matter of
taste, either way.


[1] <http://cran.r-project.org/web/packages/Rmpfr/vignettes/log1mexp-note.pdf>

-- 
Live well,
~wren