From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Joel Jacobson <joel(at)compiler(dot)org> |
Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands. |
Date: | 2024-07-03 10:41:58 |
Message-ID: | CAEZATCUozj6+46cpNU4ajB3iwUQMRJtTQOBui8gFgWLhEbb_rQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2 Jul 2024 at 20:55, Joel Jacobson <joel(at)compiler(dot)org> wrote:
>
> Interesting, I actually think there is a bug in the normal mul_var() code.
> Found a case that rounds down, when it should round up:
>
> Calling mul_var() with:
> var1=51.2945442386599
> var2=0.828548712212
> rscale=0
>
> returns 42, but I think it should return 43,
> since 51.2945442386599*0.828548712212=42.5000285724431241296446988
>
> But maybe this is expected and OK, having to do with MUL_GUARD_DIGITS?
>
No, that's not a bug. It's to be expected. The point of using only
MUL_GUARD_DIGITS extra digits is to get the correctly rounded result
*most of the time*, while saving a lot of effort by not computing the
full result.
The callers of mul_var() that ask for reduced rscale results are the
transcendental functions like ln_var() and exp_var(), which are
working to some limited precision intended to compute the final result
reasonably accurately to a particular rscale.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2024-07-03 10:42:12 | Re: Conflict Detection and Resolution |
Previous Message | David Rowley | 2024-07-03 10:41:56 | Re: Use generation memory context for tuplestore.c |