From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More inaccurate results from numeric pow() |
Date: | 2016-05-02 18:40:59 |
Message-ID: | CA+TgmoZkmevv2TpYFvYwqbCCeVkpLsH1mXnDB4pguigPvM68mg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 2, 2016 at 1:02 PM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> Doing some more testing of the numeric code patched in [1] I noticed
> another case where the result is inaccurate -- computing 0.12 ^
> -2345.6 gives a very large number containing 2162 digits, but only the
> first 2006 correct, while the last 156 digits are wrong.
Just out of curiosity, how can you tell? Where do you get alternate
output to compare against?
Also, I wonder what we think the contract with the user is in cases
like this. Surely, if we were dealing with floating point numbers,
nobody would expect a calculation like this to be accurate beyond the
first n digits, where n is surely much less than 2006. I like the
fact that numeric has a lot more precision than any built-in floating
point type, but does it have to get every digit in front of the
decimal point exactly right no matter how many there are?
rhaas=# select tan(pi()::numeric/2), tan(pi()/2);
tan | tan
-----------------+----------------------
618986325617924 | 1.63312393531954e+16
(1 row)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-05-02 18:44:33 | Re: Rename max_parallel_degree? |
Previous Message | Robert Haas | 2016-05-02 18:24:25 | Re: Naming of new tsvector functions |