order of evaluation of overloaded functions

[srvaldez]

hello all
I ran into this problem using FreeBasic where I had written the overloaded functions and operators, but I have the same symptom when using FreePascal, and here my only contribution is this tiny test, I had nothing to do with the GMP bindings, they came with the FPC distribution

Code: [Select]

{$mode objfpc}{$H+}

program my_example2;

uses
    sysutils, math, gmp;
 
var
    c: MPInteger;

function calc(N: MPInteger): MPInteger;

begin
    c+=1;
    calc:=N*c;
end;

var
    n: MPInteger;

begin
    n:=calc(2)+calc(3)+calc(4);
    writeln(format('calculation = %s', [string(n)]));
    writeln('should equal 20 if calculated from left to right');
end.


calculation = 16
should equal 20 if calculated from left to right

the order that this expression is evaluated is from right to left; n:=calc(2)+calc(3)+calc(4);
c=1, calc(4) -> 4
c=2, calc(3) -> 6
c=3, calc(2) -> 6; the total is 16 but if evaluated from left to right should equal 20

[Kays]

Evaluation order is not related to operator precedence. Indeed summation operators are left‑associative, but this does not determine the evaluation order.

The order of evaluation of the operands of an operator is implementation‑dependent. A standard program must not make any assumption about this order. The left operand might be evaluated before or after the right operand, or they might be evaluated in parallel. In fact, sometimes one operand might not be evaluated at all for some values of the other operand. […]

Kathleen Jensen, Niklaus Wirth: Pascal – user manual and report (4^th revised ed.). p. 166. DOI 10.1007/978‑1‑4612‑4450‑9. ISBN 978‑0‑387‑97649‑5.

[BrunoK]

As far as my limited mathematical knowledge goes, addition is commutable, thus there is no reason to expect, from a  compiler,  any order in an addition.

If a involved function has a side effect  (modifies a variable) involving the result, it is the problem of the programmer.

[Khrys]

FPC makes no guarantees on this (taken from the reference guide):

Remark The order in which expressions of the same precedence are evaluated is not guaranteed to be left-to-right. In general, no assumptions on which subexpression is evaluated first should be made in such a case.

The compiler will decide which subexpression to evaluate first based on optimization rules. Thus, in the following expression:

  a := g(3) + f(2);

f(2)  may be executed before  g(3). This behavior is distinctly different from Delphi or Turbo Pascal.

If one expression must be executed before the other, it is necessary to split up the statement using temporary results:

  e1 := g(3); 
  a  := e1 + f(2);

Recently there was a similiar discussion on this forum about the order of parameter evaluation (it too is under the compiler's discretion, unlike Delphi)

[Thaddy]

The order of Pascal evaluation is a mathematical fallacy and very easy to get trapped by it. It does not adhere to the basics of +, -, * and /. In Pascal multiplication comes before addition or substraction:
1+2 * 3 should be 9, not 7....(go figure my lost time over the years..)
I wonder where most CS got their silly ideas from..

[bytebites]

Random evaluation order is not optimization.

[Thaddy]

It is not random, alas, but then again I started to understand math when logic got involved.
I never paided much attention during math lessons. please ignore.
I used my time to throw a yellow fish in the teachers drinking glass and started fishing with a small rod.

The fish was from expanding paper, not a living creature. This happened in 1970.
The rod was taken from my parents bakery, used for marsipan gnomes.

[PascalDragon]

The order of Pascal evaluation is a mathematical fallacy and very easy to get trapped by it. It does not adhere to the basics of +, -, * and /. In Pascal multiplication comes before addition or substraction:
1+2 * 3 should be 9, not 7....(go figure my lost time over the years..)
I wonder where most CS got their silly ideas from..

I don't know what kind of Math you learned, but in good, old Algebra multiplication has higher precedence than addition, and thus 1 + 2 * 3 is 7, not 9 and any good compiler as well as calculator will return the same here.

[ccrause]

The order of Pascal evaluation is a mathematical fallacy and very easy to get trapped by it. It does not adhere to the basics of +, -, * and /. In Pascal multiplication comes before addition or substraction:
1+2 * 3 should be 9, not 7....(go figure my lost time over the years..)
I wonder where most CS got their silly ideas from..

Interestingly this exact example is discussed in order of operations with the answer of 7.

[MarkMLl]

Leaving aside Thaddy's tenebrations which I feel aren't helpful, I think the issue is this.

If we replace OP's original function calc() with three identical functions calcA() through calcC() for ease of discussion:

Code: Pascal  [Select][+][-]

1. n := calcA(2) + calcB(3) + calcC(4);
2.  

Even if the precedence and ordering of the arithmetic additions are universally agreed, there is no guarantee that the three functions calcA() through calcC() which comprise the operands are evaluated in any specified sequence.

This could possibly be viewed as an unspoken extension of the "short circuiting" of Boolean expressions:

Code: Pascal  [Select][+][-]

1. b := boolA(2) and boolB(3) and boolC(4);
2.  

the expression will proceed from left to right in all cases, but assuming that boolA() has evaluated true then if boolB() evaluates false then either boolC() will never be evaluated, or boolC()'s result (and in theory at least) all side effects will be discarded as a casualty of speculative execution.

Interestingly, I was reading about a Pascal implementation a couple of days ago where for..do was parallelised, which resulted in the controlled statements being evaluated in arbitrary order hence as a matter of course the control variable having no defined value on completion. This sort of thing might not be done as routine (as of this year at least), but I think it's important to bear the possibility in mind as a matter of style.

MarkMLl

[440bx]

The evaluation order will usually respect operator precedence as established and accepted in mathematics.

Within that, there are two things (that come to mind) that can affect the order in which equal precedence operations are carried out and those are, the way the expression is parsed (often but, not always recursive) and re-arrangement due to optimizations.

In an expression where the operators have equal precedence, as the one presented by the OP, it will be the parsing algorithm and the optimizer that will determine the evaluation sequence.

That's quite likely why most compilers documentation simply state that the order of evaluation is not guaranteed (it's much easier to say that than to go into all the evaluation details resulting from parsing algorithms that may change and the optimizer's abilities which may also change in subsequent releases.)

Ultimately, mathematical operator precedence is (at least in the majority of cases) respected.

[MarkMLl]

The evaluation order will usually respect operator precedence as established and accepted in mathematics.

Since when has "this program will usually give the correct result" been acceptable performance?

MarkMLl

[Warfley]

Note the term to describe this is operator associativity. The right most associativity displayed here makes sense considering that the FPC is an recursive descent LL(1) parser, so it will look at the first + and then recursively descent into the left hand side of the expression creating a rightmost evaluation order.

There also seems to be no documentation stating associativity of the operator. That said, it's a bit odd, because other languages do this. For example the C and C++ standards specifically define the arithmetic operators to be left associative, which is also the common definition in mathematics (but for example do not specify the order of operations for function parameters). In other languages like Haskell you can when defining your own operators even say if they are left or right associative.

So it makes technical sense to be implemented that way, but mathematically it's a bit odd especially when compared with other languages.

[440bx]

The evaluation order will usually respect operator precedence as established and accepted in mathematics.

Since when has "this program will usually give the correct result" been acceptable performance?

MarkMLl

I'm not sure when it happened but, I've seen "unusual" behavior claimed as being right too many times.  As a result. now I have a tendency to "guard" my statements.

You don't have to go far to find such statements, just a few posts above this one, "someone" claimed that 1 + 2 * 3 should equal 9 instead of 7. 

Another instance that comes to mind but, I don't remember the details involved MS Excel, there was situation where it broke mathematical rules and MS implied that what Excel was doing was right (why would anyone care what Gauss or Euler may think ?)

This is age of covfefe

[MarkMLl]

You don't have to go far to find such statements, just a few posts above this one, "someone" claimed that 1 + 2 * 3 should equal 9 instead of 7. 

Yes, I saw it. And I remember a thread a few days ago where somebody else was totally unable to grasp the idea that the language explicitly said that certain behaviour was undefined (which I alluded to in my earlier post).

I'd like to think that some of us are made of sterner stuff.

MarkMLl