Thread: round(x) function
This query: select round(0.5), round(0.5::integer), round(0.5::bigint), round( 0.5::float ), round( 0.5::double precision ),round(cast(0.5 as double precision )),round(cast(0.5::double precision as numeric )); has strange result: 1 1 1 0 0 0 1 Is this correct? My expected result is 1 1 1 1 1 1 1 Mauro
********************************************************************
SELEX Galileo S.p.A.
Con unico socio, direzione e coordinamento di Finmeccanica S.p.A.
Sede legale: Via Albert Einstein, 35 – 50013 Campi Bisenzio (FI) - Italia
Capitale sociale: Euro 293.391.015,00, i.v.
Reg. Imp. Firenze, C.F. e P.I. 02328910480
********************************************************************
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via riservata all'effettivo destinatario e possono essere soggetti a restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto il messaggio per errore siete pregati di cancellarlo dal vostro sistema e di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi titolo, la divulgazione o la distribuzione dei contenuti di questa e-mail a qualunque altro soggetto.
"Gaietti, Mauro \(SELEX GALILEO Guest, Italy\)" <mauro.gaietti@guests.selexgalileo.com> writes:
> This query:
> select round(0.5), round(0.5::integer), round(0.5::bigint), round(
> 0.5::float ), round( 0.5::double precision ),round(cast(0.5 as double
> precision )),round(cast(0.5::double precision as numeric )); has strange
> result:
> 1 1 1 0 0 0 1
> Is this correct?
On most machines the float4/float8 operations follow the IEEE-754 spec's
"round to nearest even" rule for such cases. I think all the other ones
are "add 0.5 and truncate" implementations. It's unlikely we'll mess
with either; and *highly* unlikely that we would change the float
behavior since that's not even under our direct control (the hardware or
libm is what's doing that). There's some case to be made for making
numeric and integer math do it the IEEE way, but I think that would
displease at least as many people as it pleased ...
regards, tom lane
On 3/26/2010 12:12 PM, Tom Lane wrote:
> "Gaietti, Mauro \(SELEX GALILEO Guest, Italy\)"<mauro.gaietti@guests.selexgalileo.com> writes:
>
>> This query:
>> select round(0.5), round(0.5::integer), round(0.5::bigint), round(
>> 0.5::float ), round( 0.5::double precision ),round(cast(0.5 as double
>> precision )),round(cast(0.5::double precision as numeric )); has strange
>> result:
>> 1 1 1 0 0 0 1
>>
>> Is this correct?
>>
> On most machines the float4/float8 operations follow the IEEE-754 spec's
> "round to nearest even" rule for such cases. I think all the other ones
> are "add 0.5 and truncate" implementations. It's unlikely we'll mess
> with either; and *highly* unlikely that we would change the float
> behavior since that's not even under our direct control (the hardware or
> libm is what's doing that). There's some case to be made for making
> numeric and integer math do it the IEEE way, but I think that would
> displease at least as many people as it pleased ...
>
> regards, tom lane
>
>
This topic keeps coming up every few months about rounding which way is
correct. I would be in favor of adding a option to round() function to
specify method.
Leave the defaults as they are for backwards capability, meaning if no
option is passed to Round() it follows current methods. I agree
changing how it works now would annoy many.
The option would be very simple something like this
Round( 0.5, RoundToEven) = 0
Round( -0.5, RoundToEven) = 0
Round(0.5, RoundUp) = 1
Round(-0.5, RoundUp) = 0
Round(0.5, RoundDown) = 0
Round(-0.5, RoundDown) = -1
Round(0.5, RoundToZero) = 0
Round(-0.5, RoundToZero) = 0
There are so many methods of rounding to choose from
http://en.wikipedia.org/wiki/Rounding
All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by
ourproprietary quotation system. Quotations received via any other form of communication will not be honored.
CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other
informationproprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it
addresses.If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified
thatany unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have
receivedthis e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this
e-mailimmediately.
Thank you.
I think this is not consistent with documentation that says there is just one round function, with one argument of
numerictype. It seems there is at least 2 different round functions with two different behaviours. One for
float4/float8that "round to nearest even" and another one for numeric type that "add 0.5 and truncate"
From the manual:
Example 10-4. Rounding Function Argument Type Resolution
There is only one round function that takes two arguments; it takes a first argument of type numeric and a second
argumentof type integer. So the following query automatically converts the first argument of type integer to numeric:
SELECT round(4, 4);
round
--------
4.0000
(1 row)
That query is actually transformed by the parser to:
SELECT round(CAST (4 AS numeric), 4);
********************************************************************
SELEX Galileo S.p.A.
Con unico socio, direzione e coordinamento di Finmeccanica S.p.A.
Sede legale: Via Albert Einstein, 35 – 50013 Campi Bisenzio (FI) - Italia
Capitale sociale: Euro 293.391.015,00, i.v.
Reg. Imp. Firenze, C.F. e P.I. 02328910480
********************************************************************
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not
theintended recipient please delete it from your system and notify the sender. You should not copy it or use it for any
purposenor disclose or distribute its contents to any other person.
Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via riservata all'effettivo destinatario e possono
esseresoggetti a restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto il messaggio per errore
sietepregati di cancellarlo dal vostro sistema e di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi
titolo,la divulgazione o la distribuzione dei contenuti di questa e-mail a qualunque altro soggetto.
-----Messaggio originale-----
Da: Justin Graf [mailto:justin@magwerks.com]
Inviato: venerdì 26 marzo 2010 18.44
A: Tom Lane
Cc: Gaietti, Mauro (SELEX GALILEO Guest, Italy); pgsql-general@postgresql.org
Oggetto: Re: [GENERAL] round(x) function
On 3/26/2010 12:12 PM, Tom Lane wrote:
> "Gaietti, Mauro \(SELEX GALILEO Guest, Italy\)"<mauro.gaietti@guests.selexgalileo.com> writes:
>
>> This query:
>> select round(0.5), round(0.5::integer), round(0.5::bigint), round(
>> 0.5::float ), round( 0.5::double precision ),round(cast(0.5 as double
>> precision )),round(cast(0.5::double precision as numeric )); has strange
>> result:
>> 1 1 1 0 0 0 1
>>
>> Is this correct?
>>
> On most machines the float4/float8 operations follow the IEEE-754 spec's
> "round to nearest even" rule for such cases. I think all the other ones
> are "add 0.5 and truncate" implementations. It's unlikely we'll mess
> with either; and *highly* unlikely that we would change the float
> behavior since that's not even under our direct control (the hardware or
> libm is what's doing that). There's some case to be made for making
> numeric and integer math do it the IEEE way, but I think that would
> displease at least as many people as it pleased ...
>
> regards, tom lane
>
>
This topic keeps coming up every few months about rounding which way is
correct. I would be in favor of adding a option to round() function to
specify method.
Leave the defaults as they are for backwards capability, meaning if no
option is passed to Round() it follows current methods. I agree
changing how it works now would annoy many.
The option would be very simple something like this
Round( 0.5, RoundToEven) = 0
Round( -0.5, RoundToEven) = 0
Round(0.5, RoundUp) = 1
Round(-0.5, RoundUp) = 0
Round(0.5, RoundDown) = 0
Round(-0.5, RoundDown) = -1
Round(0.5, RoundToZero) = 0
Round(-0.5, RoundToZero) = 0
There are so many methods of rounding to choose from
http://en.wikipedia.org/wiki/Rounding
All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by
ourproprietary quotation system. Quotations received via any other form of communication will not be honored.
CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other
informationproprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it
addresses.If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified
thatany unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have
receivedthis e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this
e-mailimmediately.
Thank you.
"Gaietti, Mauro \(SELEX GALILEO Guest, Italy\)" <mauro.gaietti@guests.selexgalileo.com> writes:
> I think this is not consistent with documentation that says there is
> just one round function, with one argument of numeric type.
The documentation you're quoting says there is just one round function
that takes *two* arguments. Which is true:
regression=# \df round
List of functions
Schema | Name | Result data type | Argument data types | Type
------------+-------+------------------+---------------------+--------
pg_catalog | round | double precision | double precision | normal
pg_catalog | round | numeric | numeric | normal
pg_catalog | round | numeric | numeric, integer | normal
(3 rows)
I don't think there's a claim anywhere that the numeric and double
precision versions of round(x) act identically. They hardly could be
exactly identical anyway given the different properties of the two
datatypes.
regards, tom lane