Feedback-ID: ic6394509:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
MIME-Version: 1.0
Message-Id: <0459ded5-6daf-4bf0-9ab0-e1f11ab15ec6@app.fastmail.com>
In-Reply-To: <bbc62c2d-1173-4454-9e17-be99437c0e7e@app.fastmail.com>
References: <44d2ffca-d560-4919-b85a-4d07060946aa@app.fastmail.com>
 <87zfr1e1uj.fsf@wibble.ilmari.org>
 <9ff90ff9-5ac1-4529-b2f4-f93b37734b9c@app.fastmail.com>
 <81348268-b9fd-4308-bf52-056070aa7c2a@app.fastmail.com>
 <f25ddfc8-4f02-4e8f-8e74-0532f48d0817@app.fastmail.com>
 <CAEZATCV2qPTGo2Fd8xDs06Q7iU5aorgSa9+Fw9zkuQv1y15rcw@mail.gmail.com>
 <8e909218-1965-4515-99e3-4bb5b625e004@app.fastmail.com>
 <CAEZATCWEou=NjpvS-r1WxymbAYihsdKQoQBj1HfBeocoNcv5Ww@mail.gmail.com>
 <bbc62c2d-1173-4454-9e17-be99437c0e7e@app.fastmail.com>
Date: Tue, 02 Jul 2024 12:23:36 +0200
From: "Joel Jacobson" <joel@compiler.org>
To: "Dean Rasheed" <dean.a.rasheed@gmail.com>
Cc: =?UTF-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Optimize numeric multiplication for one and two base-NBASE digit
 multiplicands.
Content-Type: text/plain
Archived-At: <https://www.postgresql.org/message-id/0459ded5-6daf-4bf0-9ab0-e1f11ab15ec6%40app.fastmail.com>
Precedence: bulk

On Tue, Jul 2, 2024, at 11:05, Joel Jacobson wrote:
> On Tue, Jul 2, 2024, at 10:22, Dean Rasheed wrote:
>> Shortly after posting that, I realised that there was a small bug. This bit:
>>
>>             case 2:
>>                 newdig = (int) var1digits[1] * var2digits[res_ndigits - 4];
>>
>> isn't quite right in the case where rscale is less than the full
>> result. In that case, the least significant result digit has a
>> contribution from one more var2 digit, so it needs to be:
>>
>>                 newdig = (int) var1digits[1] * var2digits[res_ndigits - 4];
>>                 if (res_ndigits - 3 < var2ndigits)
>>                     newdig += (int) var1digits[0] * var2digits[res_ndigits - 3];
>>

Just to be able to verify mul_var() is working as expected when
rscale is less than the full result, I've added a numeric_mul_patched()
function that takes a third rscale_adjustment parameter:

I've tried to get a different result with and without the fix,
but I'm failing to hit the bug.

Can you think of an example that should trigger the bug?

Example usage:

SELECT numeric_mul_patched(9999.999,2,0);
var1ndigits=1 var2ndigits=2 rscale=3
 numeric_mul_patched
---------------------
           19999.998
(1 row)

SELECT numeric_mul_patched(9999.999,2,1);
var1ndigits=1 var2ndigits=2 rscale=4
 numeric_mul_patched
---------------------
          19999.9980
(1 row)

SELECT numeric_mul_patched(9999.999,2,-1);
var1ndigits=1 var2ndigits=2 rscale=2
 numeric_mul_patched
---------------------
            20000.00
(1 row)

SELECT numeric_mul_patched(9999.999,2,-2);
var1ndigits=1 var2ndigits=2 rscale=1
 numeric_mul_patched
---------------------
             20000.0
(1 row)

/Joel