Re: BUG #16281: LN() function inaccurate at 1000th fractional digit

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Justin AnyhowStep <anyhowstep(at)hotmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16281: LN() function inaccurate at 1000th fractional digit
Date: 2020-03-01 15:34:37
Message-ID: CAEZATCVJjEF7ozLvni6o_KL1UCjmMrjLU=i-9Gz5gtV+TpVkHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, 1 Mar 2020 at 02:59, Justin AnyhowStep <anyhowstep(at)hotmail(dot)com> wrote:
>
> > With this patch, all the examples originally posted return the correct
> > results (calculated with bc). I'd be interested to know how the OP
> > constructed these examples, and whether there were any that were off
> > by more than 1 ULP.
>
> > Yeah, that would be interesting.
>
> I didn't do anything fancy. I'm learning how to write an arbitrary precision math library.
> I couldn't come up with good test cases since so many numbers exist.
> So, I sanity-checked my code by testing many random inputs against another library and pg, and compared the results.
>
> Most of the time, the problem would be with my code.
> But I found a few cases where it looked like pg was off.
>
> I don't think I found any that were off by more than 1.
>

OK, thanks for looking, and thanks for the report.

I did some random testing of my own using 100 random numbers each with
100,000 digits to the left of the decimal point and 900 to the right,
and I was able to find one case where the error was 2 ULP, without the
patch. The overall results were as follows:

error | count
-------+-------
2 | 1
1 | 16
-1 | 20
0 | 63
(4 rows)

which is quite a high probability of being off by one. With the patch,
the results for the same 100 random numbers became:

error | count
-------+-------
1 | 1
-1 | 1
0 | 98
(3 rows)

So the off-by-two case was fixed (actually becoming zero), and the
probability of off-by-one errors was greatly reduced (although, as
expected, not entirely removed).

I think this is pretty much the worst case for our ln()
implementation, since it has both a large number of digits before the
decimal point, causing a lot of square roots, and a large number after
the decimal point, causing a large number of Taylor series terms to be
computed. Such cases are really only of academic interest, and for
most other cases, the probability of an off-by-one result should be
much lower.

Regards,
Dean

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2020-03-02 03:39:21 Re: BUG #16276: Server crash on an invalid attempt to attach a partition to an index
Previous Message Justin AnyhowStep 2020-03-01 02:59:38 Re: BUG #16281: LN() function inaccurate at 1000th fractional digit