Обсуждение: [Fwd: Re: ruleutils with pretty-print option]

Now the patch is *really* appended :-)

Tom Lane wrote:

>
>Applied with some editorializing.  In particular, I don't believe the
>original did the right thing with (a - (b - c)).
>
>
>

Oops, missed that case...
But now, we have (a + ( b + c)) again.
A patch that removes parentheses for + and * is appended.

Regards,
Andfdsa


Index: backend/utils/adt/ruleutils.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/ruleutils.c,v
retrieving revision 1.147
diff -c -r1.147 ruleutils.c
*** backend/utils/adt/ruleutils.c    30 Jul 2003 22:56:23 -0000    1.147
--- backend/utils/adt/ruleutils.c    31 Jul 2003 09:32:15 -0000
***************
*** 2547,2552 ****
--- 2547,2559 ----
                  if (node == (Node *) lfirst(((OpExpr *) parentNode)->args))
                      return true;

+                 /*
+                                  * Exception: for * and +, ordering doesn't matter
+                                  */
+                 if ((*op == '+' && *parentOp == '+') ||
+                     (*op == '*' && *parentOp == '*'))
+                     return true;
+
                  return false;
              }
              /* else do the same stuff as for T_SubLink et al. */

Tom Lane wrote:

>>Now the patch is *really* appended :-)
>>
>>
>
>And rejected.
>
Ok, the ckeck for node being the first child already does the trick for
standard l-t-r evaluation.

>You cannot assume that an operator is commutative or
>associative just because it has a name you think ought to be.
>(For a counter-example, it's well known that floating-point addition
>is not associative.)
>
Well, to me it's not well-known that floating-point addition is not
associative, do I need to re-learn my math?

>More: if the tree structure for ops of equal precedence looks like
>a + (b + c), then it's a near certainty that the user wrote those
>parentheses.  Why would you think that removing them is pretty-printing?
>
In this case the user really wrote the parentheses, so they should be shown.
This stuff is all about guessing what the original definition looked
like, if we just had the source <sigh>...
I had a conversation with Bruce about embedded comments, and we found
that the idea of (mis-)using nodes for this seems to be not viable.
Still seeking for a way to preserve more-or-less the original user's
definition.

Regards,
Andreas

Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Now the patch is *really* appended :-)

And rejected.  You cannot assume that an operator is commutative or
associative just because it has a name you think ought to be.
(For a counter-example, it's well known that floating-point addition
is not associative.)

More: if the tree structure for ops of equal precedence looks like
a + (b + c), then it's a near certainty that the user wrote those
parentheses.  Why would you think that removing them is pretty-printing?

            regards, tom lane

Tom Lane wrote:

>Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
>
>>Well, to me it's not well-known that floating-point addition is not
>>associative, do I need to re-learn my math?
>>
>>
>
>regression=# select (1.0::float8 + (-1.0::float8)) + 1.0e-20::float8;
> ?column?
>----------
>    1e-20
>(1 row)
>
>regression=# select 1.0::float8 + ((-1.0::float8) + 1.0e-20::float8);
> ?column?
>----------
>        0
>(1 row)
>
>
>

Hi Tom,

I already suspected an example like this. Obviously in a pure math
world, the second example is wrong, caused by implicite rounding.
Fortunately, if omitting the float8 casts numeric is used, delivering
ultimate precision.

Just for curiousity: on MSSQL2000, the first will deliver
9.99999999999995E-21, and if the type decimal(30,25) is used both give
0.00000000000.  Even better, CAST(  CAST(1E-20 AS DECIMAL(30,25)  AS
FLOAT) is 0.0 :->

Oracle 9.2 will calculate correctly with float down to 1.0e-40.

Regards,
Andreas

On Thu, 31 Jul 2003 16:30:17 +0200, Andreas Pflug
<pgadmin@pse-consulting.de> wrote:
>Well, to me it's not well-known that floating-point addition is not
>associative

This is a case of theory vs. practice mismatch:  In theory addition is
associative, in practice there is only limited storage available for a
floating-point number.  Let's do an example with 3 significant decimal
digits:

    a = 1000        internal representation: 1.00e3
    b =    1        internal representation: 1.00e0
    a + b = 1.001e3

which cannot be represented in our system, so it is rounded to 1.00e3
and we get

    a + b = 1000
    a + b + b + b + b + b + b + b + b + b + b = 1000

when evaluated left to right, but

    a + (b + b + b + b + b + b + b + b + b + b) =
    1.00e3 + 1.00e1 = 1.01e3 = 1001

Servus
 Manfred

Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Well, to me it's not well-known that floating-point addition is not
> associative, do I need to re-learn my math?

regression=# select (1.0::float8 + (-1.0::float8)) + 1.0e-20::float8;
 ?column?
----------
    1e-20
(1 row)

regression=# select 1.0::float8 + ((-1.0::float8) + 1.0e-20::float8);
 ?column?
----------
        0
(1 row)


            regards, tom lane