# Re: Numeric x^y for negative x

From: Alvaro Herrera Dean Rasheed Jaime Casanova , Tom Lane , Yugo NAGATA , PostgreSQL Hackers , Dave Page Re: Numeric x^y for negative x 2021-09-13 16:51:17 202109131651.raa5zr4znnfk@alvherre.pgsql Raw Message | Whole Thread | Download mbox | Resend email 2021-06-29 11:08:01 from Dean Rasheed 📎  2021-07-01 13:17:46 from Dean Rasheed   2021-07-07 17:36:56 from Dean Rasheed 📎    2021-07-07 18:02:31 from Zhihong Yu     2021-07-07 18:42:43 from Dean Rasheed    2021-07-20 09:15:09 from Yugo NAGATA     2021-07-21 10:10:16 from Dean Rasheed 📎      2021-07-22 05:11:36 from Yugo NAGATA       2021-07-22 15:19:35 from Dean Rasheed        2021-07-29 18:14:05 from Dean Rasheed 📎         2021-08-05 16:04:39 from Tom Lane          2021-08-05 18:27:16 from Dean Rasheed           2021-08-06 02:58:04 from Tom Lane            2021-08-06 16:06:20 from Dean Rasheed 📎             2021-08-06 16:15:18 from Tom Lane              2021-08-06 20:23:39 from Dean Rasheed               2021-08-06 20:26:06 from Tom Lane                2021-08-06 20:27:03 from Dean Rasheed                 2021-09-01 23:39:17 from Jaime Casanova                  2021-09-02 06:27:09 from Dean Rasheed                   2021-09-10 17:31:20 from Jaime Casanova                    2021-09-12 19:36:05 from Dean Rasheed 📎                     2021-09-13 16:51:17 from Alvaro Herrera                      2021-09-13 18:29:13 from Dean Rasheed 📎                       2021-09-30 17:25:07 from Jaime Casanova                        2021-10-01 06:56:33 from Dean Rasheed                         2021-10-01 14:25:10 from Jaime Casanova pgsql-hackers

On 2021-Sep-12, Dean Rasheed wrote:

> So the fix is just to remove the upper bound on this local_rscale, as
> we do for the full-precision calculation. This doesn't impact
> performance, because it's only computing the logarithm to 8
> significant digits at this stage, and when x is very close to 1 like
> this, ln_var() has very little work to do -- there is no argument
> reduction to do, and the Taylor series terminates on the second term,
> since 1-x is so small.

I came here just to opine that there should be a comment about there not
being a clamp to the maximum scale. For example, log_var says "Set the
scales .. so that they each have more digits ..." which seems clear
enough; I think the new comment is a bit on the short side.

> Coming up with a test case that doesn't have thousands of digits is a
> bit fiddly, so I chose one where most of the significant digits of the
> result are a long way after the decimal point and shifted them up,
> which makes the loss of precision in HEAD more obvious. The expected
> result can be verified using bc with a scale of 2000.

I couldn't get bc (version 1.07.1) to output the result; it says

Runtime warning (func=(main), adr=47): non-zero scale in exponent
Runtime error (func=(main), adr=47): exponent too large in raise

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

### Browse pgsql-hackers by date

From Date Subject
Next Message Alvaro Herrera 2021-09-13 16:52:39 Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
Previous Message Alvaro Herrera 2021-09-13 16:15:24 Re: What are exactly bootstrap processes, auxiliary processes, standalone backends, normal backends(user sessions)?