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 log1pexplog1mexp? 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@gmail.com> wrote:
On 21 April 2014 09:38, John Lato <jwlato@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