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

[Edward Kmett]

If you really want to push for uniform availability of the new precision and that everyone pays for supplying them, then we really should bite the bullet and export the full class with them from Prelude, let it warn library authors about missing implementations and just be done with it.

I personally do not think the extra precision is worth the pain, and my guiding rule for 7.10 from a change perspective had been that the changes we are pushing out for AMP etc should be able to be worked around sans CPP, but I could be won over to that viewpoint.

Regardless, upon reviewing all the numeric code I have that uses them, your original comment about log1pexp and log1mexp actually exposed some opportunities for better precision in my code.

I'd like to expand the proposal to incorporate them.

This would be absolutely painless under my variant, but if we're going down the other road, we should at least incur all the pain at once.

They are at least all unary combinators like most everything in the class so whatever lifting the library author needs will likely be similar.

Sent from my iPad

> On Apr 20, 2014, at 9:25 PM, wren romano <winterkoninkje at gmail.com> wrote:
> 
>> On Sun, Apr 20, 2014 at 8:49 PM, John Lato <jwlato at gmail.com> wrote:
>>> On Sun, Apr 20, 2014 at 5:20 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>> I know for me personally it would force me to double the amount of numeric
>>> code I write, just to maximize my audience. I really don't want to go there.
>>> I just want to be able to call the function I mean, and to be able to talk
>>> to the right people to make it do the right thing.
>> 
>> exp1m = error "Go bug some library author to implement exp1m"
>> 
>> would accomplish that even more efficiently, since it will directly point
>> users to the right people.
> 
> FWIW, because log1p/expm1 etc are not part of the current API, this
> too is a strictly monotonic improvement over the current state of
> things: users who don't know/care about the new functions don't need
> to change anything, and users who do care are beholden to see that
> they are implemented correctly. No need for CPP. And no misleading
> implementations of the fused functions.
> 
> I'm +1 for these defaults.
> 
> -- 
> Live well,
> ~wren
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries