Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.

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

In response to

Browse pgsql-hackers by date

  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