Re: Inaccurate results from numeric ln(), log(), exp() and pow()

On 16 September 2015 at 09:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> > ... For example, exp() works for inputs up to 6000. However, if you
> > compute exp(5999.999) the answer is truly huge -- probably only of
> > academic interest to anyone. With HEAD, exp(5999.999) produces a
> > number with 2609 significant digits in just 1.5ms (on my ageing
> > desktop box). However, only the first 9 digits returned are correct.
> > The other 2600 digits are pure noise. With my patch, all 2609 digits
> > are correct (confirmed using bc), but it takes 27ms to compute, making
> > it 18x slower.
>
> > AFAICT, this kind of slowdown only happens in cases like this where a
> > very large number of digits are being returned. It's not obvious what
> > we should be doing in cases like this. Is a performance reduction like
> > that acceptable to generate the correct answer? Or should we try to
> > produce a more approximate result more quickly, and where do we draw
> > the line?
>
> FWIW, in that particular example I'd happily take the 27ms time to get
> the more accurate answer. If it were 270ms, maybe not. I think my
> initial reaction to this patch is "are there any cases where it makes
> things 100x slower ... especially for non-outrageous inputs?" If not,
> sure, let's go for more accuracy.
>

Agreed

Hopefully things can be made faster with less significant digits.

I figure this is important enough to trigger a maint release, but since we
already agreed when the next one is, I don't see we need to do it any
quicker, do we?

Well done Dean for excellent research.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services