On Thu, Apr 17, 2014 at 2:48 PM, Henning Thielemann <schlepptop@henning-thielemann.de> wrote:
Am 17.04.2014 19:15, schrieb Edward Kmett:


log1p and expm1 are C standard library functions that are important for
work with exponentials and logarithms.

I propose adding them to the Floating class where it is defined in
GHC.Float.

No question, these functions are useful. But I think there should be two proposals:

1) Add log1pFloat, log1pDouble, expm1Float, expm1Double to GHC.Float
2) Extend Floating class with log1p and expm1 methods.

I think the first item is unproblematic since it is a simple addition. Since FPUs sometimes directly implement log1p and expm1 functions, I wonder whether GHC also should support the according machine instructions. E.g. x86 has F2XM1 and FYL2XP1 and good old MC68882 had FETOXM1 and FLOGNP1.
 
The second item means to alter the Floating class which affects all custom Floating instances. I think one should add default implementations. They don't have an numerical advantage but they save programmers from code breakage.
 
I included the default definitions in code snippet in the proposal, so user code that remains unaware of them would be unaffected, while packages like compensated, or a wrapper around libqd could implement them as needed.

expm1 :: Floating a => a -> a
expm1 x = exp x - 1

log1p :: Floating a => a -> a
log1p x = log (1 + x)

My proposal is very much about adding them to the class for Floating. Since they have legal default definitions it really costs nothing to just do the right thing here.

Adding the primops is trivially done by end-users in a library and has been my solution up until now, but if that was all that is done, you have to overload between them by making some needless extra class and 'whether you are using decent numerics' leaks into your type. 

Not doing 2 would force long term needless hairsplitting and code duplication for no reason.

Consequently, I deliberately did not split up the proposal in this matter.

We do not have to export these from Prelude. My knee-jerk reaction is
that we probably shouldn't.

Not exporting them from Prelude still means to export them from GHC.Float, right? I mean, users must be able to implement these methods for custom types like extended precision floating point numbers as provided by libqd. But there should also be a non-GHC module that exports the full Floating class.

Yes, I am proposing including them in the export of the class from GHC.Float.

I'm also fully on board with exporting the full Floating class from some non-GHC module in base, say, something like Numeric.Floating.

-Edward