On 14 November 2015 at 16:13, Tom Lane <t...@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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: