Re: Inaccurate results from numeric ln(), log(), exp() and pow() - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Date
Msg-id CAEZATCVMa2msdkymfRk076L1DnrfMGcxoELYpCbmE58VXZX72g@mail.gmail.com
Whole thread Raw
In response to Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 14 November 2015 at 16:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We might well want to keep the power-10 argument reduction step, but
>> it would now be there purely on performance grounds so there's scope
>> for playing around with the threshold at which it kicks in.
>
> My inclination is to get rid of it.  I thought having ln_var recurse was
> rather ugly, and I'm suspicious of whether there's really any performance
> benefit.  Even with the pow_10 reduction, you can have up to 7 sqrt steps
> (if the first digit is 9999, or indeed anything above 445), and will
> almost always have 4 or 5.  So if the pow_10 reduction costs about as much
> as 7 sqrt steps, the input has to exceed something like 1e170 before it
> can hope to win.  Admittedly there's daylight between there and 1e128000,
> but I doubt it's worth carrying extra code for.
>

Yeah, that makes sense. Thinking about it some more, its potential
benefit becomes even less apparent at higher rscales because the cost
of ln() relative to sqrt() will become larger -- the number of Taylor
series terms required will grow roughly in proportion to the number of
digits N, whereas the number of iterations sqrt() needs to do only
grows like log(N) I think, because of it's quadratic convergence. So
let's get rid of it.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_statements query jumbling question
Next
From: Peter Eisentraut
Date:
Subject: Re: Python 3 compatibility fun