Re: Inaccurate results from numeric ln(), log(), exp() and pow()
От | Tom Lane |
---|---|
Тема | Re: Inaccurate results from numeric ln(), log(), exp() and pow() |
Дата | |
Msg-id | 6758.1447517619@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: > I'm much less happy with the sqrt() range reduction step though. I now > realise that the whole increment local_rscale before each sqrt() > approach is totally bogus. Yeah, I was wondering about that yesterday ... > So repeated use of sqrt() can be used for range reduction, even in > extreme cases, and it won't lose precision if it's done right. In > fact, in the worst case there are only 22 sqrts() by my count. Cool. > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: