Re: Inaccurate results from numeric ln(), log(), exp() and pow() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Date
Msg-id CA+Tgmobx1Lpx6ecoFapni_whvr6k2rn2WCpfoj+7tbWHkJD-Yw@mail.gmail.com
Whole thread Raw
In response to Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Nov 15, 2015 at 4:40 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 14 November 2015 at 20:05, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: mdnblocks() sabotages error checking in _mdfd_getseg()
Next
From: Robert Haas
Date:
Subject: Re: mdnblocks() sabotages error checking in _mdfd_getseg()