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

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Дата
Msg-id CAEZATCVMa2msdkymfRk076L1DnrfMGcxoELYpCbmE58VXZX72g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_statements query jumbling question
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Python 3 compatibility fun