BUG #8317: ROUND(double*1/2) != ROUND(1/2*double)

On 2013-07-22 09:44:58 +0000, remi.cura@gmail.com wrote:

The following bug has been logged on the website:

Bug reference: 8317
Logged by: R�mi
Email address: remi.cura@gmail.com
PostgreSQL version: 9.2.4
Operating system: Ubuntu 12.0.4 32 bits hosted by a VirtualBox
Description:

Hello;
I ran into a strange behaviour.
Initially it showed in a group by, but is also happens in regular select :

example :
SELECT 2*ROUND(1/2*3.2)
--> gives 0
SELECT 2*ROUND(3.2*1/2)
--> gives 3

Obviously both should return the same thing, preferably 3.
It looks like a bug to me, or at least a non desirable behaviour.

Hm. Doesn't really look like a bug to me. The first parses as:
ROUND((1/2) * 3.2), the second as ROUND((3.2 * 1) / 2). So the different
result makes sense to me.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

2013/7/22 <remi.cura@gmail.com>:

The following bug has been logged on the website:

Bug reference: 8317
Logged by: Rémi
Email address: remi.cura@gmail.com
PostgreSQL version: 9.2.4
Operating system: Ubuntu 12.0.4 32 bits hosted by a VirtualBox
Description:

Hello;
I ran into a strange behaviour.
Initially it showed in a group by, but is also happens in regular select :

example :
SELECT 2*ROUND(1/2*3.2)
--> gives 0
SELECT 2*ROUND(3.2*1/2)
--> gives 3

Hello

It is not a bug - a reason for this behave is using a integer div in first case

( 1 / 2 ) * 3.2 ... 1/2 .. integer div, because left operand is int
and right operand is int
(3.2 * 1) / 2 ... 3.2 / 2 .. using numeric div, left operand is
numeric and right operand is int

Regards

Pavel Stehule

Obviously both should return the same thing, preferably 3.
It looks like a bug to me, or at least a non desirable behaviour.

Cheers,
Rémi

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi, thanks for your quick answers.

To close this non-bug :
According to the doc (
http://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTAX-OPERATORS
)
, multiplication has precedence on division. (I supposed it implicitely)
So anyway the query is parsed as ( 1/ (2*3.2)) and ( 3.2*1) / 2 ), and so
the behaviour is consistant.

Cheers ,

Rémi

2013/7/22 Pavel Stehule <pavel.stehule@gmail.com>

Rémi Cura <remi.cura@gmail.com> wrote:

According to the doc
( http://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTAX-OPERATORS ),
multiplication has precedence on division. (I supposed it implicitely)

The correct link is:

http://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE

And it shows multiplication, division, and modulo as having equal
precedence, with left-to-right associativity.

So anyway the query is parsed as ( 1/ (2*3.2)) and ( 3.2*1) / 2 ),

No, it is ((1 / 2) * 3.2) and ((3.2 * 1) / 2).

Those evaluate to (0 * 3.2) and (3.2 / 2), respectively.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs