Обсуждение: BUG #8317: ROUND(double*1/2) != ROUND(1/2*double)

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.


Cheers,
Rémi

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

2013/7/22  <remi.cura@gmail.com>:
> The following bug has been logged on the website:
>
> Bug reference:      8317
> Logged by:          R=C3=A9mi
> 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=C3=A9mi
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

R=E9mi Cura <remi.cura@gmail.com> wrote:=0A=0A> According to the doc=0A> ( =
http://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTA=
X-OPERATORS ),=0A> multiplication has precedence on division. (I supposed i=
t implicitely)=0A=0AThe correct link is:=0A=0Ahttp://www.postgresql.org/doc=
s/9.2/static/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE=0A=0AAnd it shows=
 multiplication, division, and modulo as having equal=0Aprecedence, with le=
ft-to-right associativity.=0A=0A> So anyway the query is parsed as ( 1/ (2*=
3.2)) and ( 3.2*1) / 2 ),=0A=0ANo, it is ((1 / 2) * 3.2) and ((3.2 * 1) / 2=
).=0A=0AThose evaluate to (0 * 3.2) and (3.2 / 2), respectively.=0A=0A--=0A=
Kevin Grittner=0AEDB: http://www.enterprisedb.com=0AThe Enterprise PostgreS=
QL Company