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

[Edward Kmett]

I didn't want to make everyone pay for this feature, but as a number of
folks feel strongly about it, then let's explore the following modified
concrete proposal as an alternative.

* Add log1p, expm1, log1pexp, log1mexp to Floating with the defaults, but
extend the MINIMAL pragma for Floating to include them, so everyone gets
told to implement them.

* Just export the additional functions from Prelude like everything else in
Floating.

Why incorporate log1pexp, log1mexp? They have to be in the class or can't
be properly implemented pointwise for vector spaces.

Pros:

* Anyone who doesn't implement them get warnings during their builds.
* Code can reliably upgrade to expm1 and log1p and not be worse off than
today.
* If you can compile sans warnings you have nothing to fear. If you do get
warnings, you can know precisely what types will have degraded back to the
old precision at *compile* time, not runtime.
* The costs are mostly borne by folks who write libraries for things like
linear algebra or AD, who are the very kinds of people who would care about
these additions in the first pace.

Cons:

* Folks who do more than just GenericNewtypeDeriving for Floating needs to
work around the addition of these using CPP or get spammed with warnings,
but they are real warnings about needless loss of precision.

I'd almost prefer this to the original proposal, but it impacts more
people, so I could be swayed either way.

-Edward


On Mon, Apr 21, 2014 at 5:24 AM, Aleksey Khudyakov <
alexey.skladnoy at gmail.com> wrote:

> On 21 April 2014 09:38, John Lato <jwlato at gmail.com> wrote:
> > I was just wondering, why not simply numerically robust algorithms as
> > defaults for these functions?  No crashes, no errors, no loss of
> precision,
> > everything would just work.  They aren't particularly complicated, so the
> > performance should even be reasonable.
> >
> I think it's best option. log1p and exp1m come with guarantees
> about precision. log(1+p) default makes it impossible to depend in such
> guarantees. They will silenly give wrong answer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140421/8868bdd7/attachment.html>