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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Date: 2015-12-10 18:59:14
Message-ID: CA+Tgmobx1Lpx6ecoFapni_whvr6k2rn2WCpfoj+7tbWHkJD-Yw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 15, 2015 at 4:40 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> On 14 November 2015 at 20:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I committed this with that change and some other
>> mostly-cosmetic revisions.
>
> Thanks.

This patch, or something nearby, seems to have changed the number of
significant figures produced by log() and maybe some of the other
functions this patch touched. On master:

rhaas=# select log(.5);
log
---------------------
-0.3010299956639812
(1 row)

But on REL9_5_STABLE:

rhaas=# select log(.5);
log
-------------------------
-0.30102999566398119521
(1 row)

It's certainly not obvious from the commit message that this change
was expected. There is something about setting the rscales for
intermediate results, but there isn't any indication that the number
of digits in the final result should be expected to differ. Was that
intentional? Why did we make the change? I'm not sure it's bad, but
it seems funny to whack a user-visible behavior around like this
without a clearly-explained reason.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-12-10 19:09:45 Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Previous Message Tom Lane 2015-12-10 18:48:09 Re: mdnblocks() sabotages error checking in _mdfd_getseg()