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

From: Merlin Moncure <mmoncure(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: Inaccurate results from numeric ln(), log(), exp() and pow()
Date: 2015-09-16 15:54:56
Message-ID: CAHyXU0yr0Ax7-LakA2TW6RzaaaYXFhyaP5JMQhdmeZS5ERDfdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 16, 2015 at 10:14 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> On 16 September 2015 at 14:49, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> AFAICT, this kind of slowdown only happens in cases like this where a
>>> very large number of digits are being returned.
>>
>> Can you clarify "very large"?
>>
>
> I haven't done much performance testing because I've been mainly
> focussed on accuracy. I just did a quick test of exp() for various
> result sizes. For results up to around 50 digits, the patched code was
> twice as fast as HEAD. After that the gap narrows until at around 250
> digits they become about the same speed, and beyond that the patched
> code is slower. At around 450 digits the patched code is twice as
> slow.
>
> My guess is that no one is actually using it for numbers that large.

well, I'm sold :-).

(I certainly agree that a slow inaccurate answer is better than a fast
inaccurate one, but it's nice to know that reasonable users of these
functions won't be impacted)

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2015-09-16 16:03:55 Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Previous Message Nicolas Barbier 2015-09-16 15:53:39 Re: [PROPOSAL] Covering + unique indexes.