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