Re: Unexpected result using floor() function

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Pujol Mathieu <mathieu(dot)pujol(at)realfusio(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Unexpected result using floor() function
Date: 2016-03-14 20:15:58
Message-ID: CAHyXU0yKx_Y96LhA32wn0URgEMTPDWepKe5=tGq83jQVmTJkpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Mar 14, 2016 at 11:54 AM, Pujol Mathieu
<mathieu(dot)pujol(at)realfusio(dot)com> wrote:
> Le 14/03/2016 15:29, Merlin Moncure a écrit :
>>
>> On Mon, Mar 14, 2016 at 9:21 AM, Pujol Mathieu
>> <mathieu(dot)pujol(at)realfusio(dot)com> wrote:
>>>
>>> Hi
>>> I reproduce your bug using "PostgreSQL 9.3.6, compiled by Visual C++
>>> build
>>> 1600, 64-bit" on Windows 8
>>> I also notice that SELECT floor(4.725 * power(10, 2)::numeric + 0.5) work
>>> as
>>> expected
>>
>> I don't think this is a bug -- just peculiarities of floating point math.
>>
>> merlin
>>
>>
> I think also that it is a float precision issue but the weird thing is that
> both calls without floor return 273. Maybe the display method make a
> rounding ?

Yeah. One of the trickiest bits about floating point numbers with
postgres (as well as many other implementations) is that the textual
representation does not necessarily equate to the internal one. This
can lead to some pretty weird situations. For example, data that was
valid when dumped could fail to restore on duplicate key. Anyone
doing work with floating point should be aware of this: it's compact
and fast but poor at representing precise numbers.

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Peter Geoghegan 2016-03-14 20:20:07 Re: ON CONFLICT DO NOTHING RETURNING
Previous Message Peter Devoy 2016-03-14 19:28:24 ON CONFLICT DO NOTHING RETURNING