Thread: [GENARAL] round() bug?

[GENARAL] round() bug?

From
Willy-Bas Loos
Date:
Hi,
I ran into some strange behavior.
Seems like a bug to me?

wbloos=# select round(0.5::numeric), round(0.5::double precision);
 round | round
-------+-------
     1 |     0
(1 row)

wbloos=# select version();
                                                   version                                                   
--------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.1.13 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1, 64-bit
(1 row)

Cheers,
--
Willy-Bas Loos

Re: [GENARAL] round() bug

From
David G Johnston
Date:
Willy-Bas Loos-3 wrote
> Hi,
> I ran into some strange behavior.
> Seems like a bug to me?
>
> wbloos=# select round(0.5::numeric), round(0.5::double precision);
>  round | round
> -------+-------
>      1 |     0
> (1 row)

Not a bug; and likely to simple to have escaped notice this long so the
first reaction should be "what am I missing here?"

[google: round .5 postgresql]

http://grokbase.com/t/postgresql/pgsql-hackers/03ap11tckn/round-function-wrong/oldest

Round( numeric ) - 0.5 rounds away from zero
Round( float ) - platform dependent, IEEE 0.5 rounds toward even

You can argue the decision but at this point it's not likely to change.

David J.




--
View this message in context: http://postgresql.1045698.n5.nabble.com/GENARAL-round-bug-tp5800087p5800118.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


Re: [GENARAL] round() bug

From
Raymond O'Donnell
Date:
On 15/04/2014 17:20, David G Johnston wrote:
> Willy-Bas Loos-3 wrote
>> Hi, I ran into some strange behavior. Seems like a bug to me?
>>
>> wbloos=# select round(0.5::numeric), round(0.5::double precision);
>> round | round -------+------- 1 |     0 (1 row)
>
> Not a bug; and likely to simple to have escaped notice this long so
> the first reaction should be "what am I missing here?"
>
> [google: round .5 postgresql]
>
> http://grokbase.com/t/postgresql/pgsql-hackers/03ap11tckn/round-function-wrong/oldest
>
>  Round( numeric ) - 0.5 rounds away from zero Round( float ) -
> platform dependent, IEEE 0.5 rounds toward even
>
> You can argue the decision but at this point it's not likely to
> change.

Interestingly, I get different results (on both 9.1.4 and 9.3.0) on Windows:

postgres=# select round(0.5::numeric), round(0.5::double precision);
 round | round
-------+-------
     1 |     1
(1 row)


postgres=# select version();
                           version
-------------------------------------------------------------
 PostgreSQL 9.1.4, compiled by Visual C++ build 1500, 64-bit
(1 row)


.... Same on 9.3.0.

Ray.

--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie


Re: [GENARAL] round() bug

From
David G Johnston
Date:
Raymond O'Donnell wrote
> On 15/04/2014 17:20, David G Johnston wrote:
>> Willy-Bas Loos-3 wrote
>>> Hi, I ran into some strange behavior. Seems like a bug to me?
>>>
>>> wbloos=# select round(0.5::numeric), round(0.5::double precision);
>>> round | round -------+------- 1 |     0 (1 row)
>>
>> Not a bug; and likely to simple to have escaped notice this long so
>> the first reaction should be "what am I missing here?"
>>
>> [google: round .5 postgresql]
>>
>> http://grokbase.com/t/postgresql/pgsql-hackers/03ap11tckn/round-function-wrong/oldest
>>
>>  Round( numeric ) - 0.5 rounds away from zero Round( float ) -
>> platform dependent, IEEE 0.5 rounds toward even
>>
>> You can argue the decision but at this point it's not likely to
>> change.
>
> Interestingly, I get different results (on both 9.1.4 and 9.3.0) on
> Windows:
>
> postgres=# select round(0.5::numeric), round(0.5::double precision);
>  round | round
> -------+-------
>      1 |     1
> (1 row)
>
>
> postgres=# select version();
>                            version
> -------------------------------------------------------------
>  PostgreSQL 9.1.4, compiled by Visual C++ build 1500, 64-bit
> (1 row)
>
>
> .... Same on 9.3.0.

I'm not particularly surprised that Windows is not being IEEE compliant, and
instead chooses the more common round-away-from-zero behavior, here though I
am unsure where the dependent implementation would end up existing.

David J.






--
View this message in context: http://postgresql.1045698.n5.nabble.com/GENARAL-round-bug-tp5800087p5800121.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


Re: [GENARAL] round() bug

From
Raymond O'Donnell
Date:
On 15/04/2014 17:34, David G Johnston wrote:
> Raymond O'Donnell wrote
>> On 15/04/2014 17:20, David G Johnston wrote:
>>> Willy-Bas Loos-3 wrote
>>>> Hi, I ran into some strange behavior. Seems like a bug to me?
>>>>
>>>> wbloos=# select round(0.5::numeric), round(0.5::double precision);
>>>> round | round -------+------- 1 |     0 (1 row)
>>>
>>> Not a bug; and likely to simple to have escaped notice this long so
>>> the first reaction should be "what am I missing here?"
>>>
>>> [google: round .5 postgresql]
>>>
>>> http://grokbase.com/t/postgresql/pgsql-hackers/03ap11tckn/round-function-wrong/oldest
>>>
>>>  Round( numeric ) - 0.5 rounds away from zero Round( float ) -
>>> platform dependent, IEEE 0.5 rounds toward even
>>>
>>> You can argue the decision but at this point it's not likely to
>>> change.
>>
>> Interestingly, I get different results (on both 9.1.4 and 9.3.0) on
>> Windows:
>>
>> postgres=# select round(0.5::numeric), round(0.5::double precision);
>>  round | round
>> -------+-------
>>      1 |     1
>> (1 row)
>>
>>
>> postgres=# select version();
>>                            version
>> -------------------------------------------------------------
>>  PostgreSQL 9.1.4, compiled by Visual C++ build 1500, 64-bit
>> (1 row)
>>
>>
>> .... Same on 9.3.0.
>
> I'm not particularly surprised that Windows is not being IEEE compliant, and
> instead chooses the more common round-away-from-zero behavior, here though I
> am unsure where the dependent implementation would end up existing.

Oh, so does the rounding code use OS facilities, then, rather than being
implemented in Postgres? - Didn't know that, though I was aware PG does
that in other areas (collation, for example).

Ray.


--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie


Re: [GENARAL] round() bug

From
Adrian Klaver
Date:
On 04/15/2014 10:21 AM, Raymond O'Donnell wrote:
> On 15/04/2014 17:34, David G Johnston wrote:

>
> Oh, so does the rounding code use OS facilities, then, rather than being
> implemented in Postgres? - Didn't know that, though I was aware PG does
> that in other areas (collation, for example).

See the thread below for that discussion:

http://www.postgresql.org/message-id/34608c0c0906150358xbc53de2pe0c7053779e7b0ca@mail.gmail.com


>
> Ray.
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


Re: [GENARAL] round() bug

From
Albe Laurenz
Date:
Raymond O'Donnell wrote:
>>> Interestingly, I get different results (on both 9.1.4 and 9.3.0) on
>>> Windows:

>> I'm not particularly surprised that Windows is not being IEEE compliant, and
>> instead chooses the more common round-away-from-zero behavior, here though I
>> am unsure where the dependent implementation would end up existing.

> Oh, so does the rounding code use OS facilities, then, rather than being
> implemented in Postgres? - Didn't know that, though I was aware PG does
> that in other areas (collation, for example).

Yes.

But this here:
http://msdn.microsoft.com/en-us/library/0b34tf65.aspx
claims that Windows C++ is IEEE compliant, so it should behave like Linux.

On systems where the function exists, PostgreSQL uses the rint() function.
On other systems (like Windows), it defines rint() as

double
rint(double x)
{
    return (x >= 0.0) ? floor(x + 0.5) : ceil(x - 0.5);
}

It is interesting that the above function, when applied to 0.5 on my
Linux x86_64 system, yields "1".

So while rint() follows the IEEE standard's default (if a value is exactly
between two integers, round to the even one), PostgreSQL's replacement
function doesn't.

So maybe there is a bug after all, and the replacement function
should be changed.

Yours,
Laurenz Albe