
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@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
On 21 April 2014 09:38, John Lato
wrote: 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