Re: Inaccurate results from numeric ln(), log(), exp() and pow()
От | Tom Lane |
---|---|
Тема | Re: Inaccurate results from numeric ln(), log(), exp() and pow() |
Дата | |
Msg-id | 8680.1447456239@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Inaccurate results from numeric ln(), log(), exp() and pow() (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: Inaccurate results from numeric ln(), log(), exp() and pow()
|
Список | pgsql-hackers |
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > On 13 November 2015 at 18:36, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Seems like we arguably should do this whenever the weight isn't zero, >> so as to minimize the number of sqrt() steps. > It's a bit arbitrary. There is a tradeoff here -- computing ln(10) is > more expensive than doing a sqrt() since the Babylonian algorithm used > for sqrt() is quadratically convergent, whereas the Taylor series for > ln() converges more slowly. At the default precision, ln(10) is around > 7 times slower than sqrt() on my machine, although that will vary with > precision, and the sqrt()s increase the local rscale and so they will > get slower. Anyway, it seemed reasonable to not do the extra ln() > unless it was going to save at least a couple of sqrt()s. OK --- I think I miscounted how many sqrt's we could expect to save. One more thing: the approach you used in power_var() of doing a whole separate exp * ln(base) calculation to approximate the result weight seems mighty expensive, even if it is done at minimal precision. Couldn't we get a good-enough approximation using basically numericvar_to_double_no_overflow(exp) * estimate_ln_weight(base) ? regards, tom lane
В списке pgsql-hackers по дате отправления: