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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Дата
Msg-id 4514.1449777733@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Robert Haas <robertmhaas@gmail.com>)
Ответы 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()  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Dec 10, 2015 at 2:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That's on me as author of the commit message, I guess.  The rscale
>> in most of these functions is exactly the number of fraction digits
>> that will be emitted, and we changed the rules for computing it.
>> Not by much, in most cases.  I don't think we should be too worried
>> about being bug-compatible with the old behavior.

> It seems to be a loss of 4 digits in every case I've seen.

I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth
of rscale in each of these functions so that the discrepancies tend to
favor more significant digits out, rather than fewer.  I don't know that
it's worth trying to guarantee that the result is never fewer digits than
before, and I certainly wouldn't want to make the rules a lot more complex
than what's there now.  But perhaps we could cover most cases easily.

Dean, do you want to recheck the patch with an eye to that?
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.