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

[Edward Kmett]

On Thu, Apr 17, 2014 at 2:48 PM, Henning Thielemann <
schlepptop at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140417/3d2b95bb/attachment.html>