Re: BUG #19467: Inconsistency in MOD() result involving POWER() and floating-point precision in PostgreSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: fmusqlgen(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19467: Inconsistency in MOD() result involving POWER() and floating-point precision in PostgreSQL
Date: 2026-04-27 14:08:37
Message-ID: 2566490.1777298917@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

John Naylor <johncnaylorls(at)gmail(dot)com> writes:
> On Mon, Apr 27, 2026 at 6:33 PM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> Mathematically, this corresponds to the fractional part of 3^70.31, which
>> should be deterministic for a given evaluation strategy.
>>
>> However, different systems produce significantly different results:

> These two statements don't contradict eachother.

> Trying the expression on WolframAlpha shows 0.41 is close to the
> expected value, so I don't see a bug here.

Those other systems are probably using float8 arithmetic, which has
nowhere near enough precision to give a nonzero answer.

In Postgres, constants like "3.00" are type numeric not type float8,
so:

regression=# select pow(3.00, 70.31);
pow
---------------------------------------
3518806773889710662003177340498520.41
(1 row)

regression=# select mod(pow(3.00, 70.31), 1);
mod
------
0.41
(1 row)

You can duplicate the lower-precision answer if you want:

regression=# select pow(3.00::float8, 70.31::float8);
pow
------------------------
3.5188067738897196e+33
(1 row)

regression=# select pow(3.00::float8, 70.31::float8)::numeric;
pow
------------------------------------
3518806773889720000000000000000000
(1 row)

regression=# select mod(pow(3.00::float8, 70.31::float8)::numeric, 1);
mod
-----
0
(1 row)

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message surya poondla 2026-04-27 22:31:27 Re: BUG #19463: Server crash (Assertion failure) when using MERGE statement in CTE
Previous Message Ayush Tiwari 2026-04-27 12:41:34 Re: BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor