order of evaluation of overloaded functions

[gidesa]

In mathematics  doesn't exists anything as global variables, so:
x = f(1) + f(2) 
is guaranteed same as:
x = f(2) + f(1)
So the problem is that, in the "hard" world of computers, the "calc" function modifies a global variable, but the programmer doesn't take care of it in the add formula, not using parentheses.

EDIT: in FPC 3.2.2/Laz 2.2.6 Win 11, compiling the program in first post, only changing MPInteger to simple Integer, the result is always 20, as expected with a left-first evaluation.
Could the right-first evaluation depends from the MPInteger type?

And using parentheses:

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

1. n:=calc(2) + (calc(3) + (calc(4)) );

has no effects on result.

[alpine]

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

I should say it is more of an observation, but not a problem. On the other hand using impure functions can always become such.

[wp]

This reminds me of a discussion here some years ago about the result of -2^2. About half of the users claimed it to be 4, the other half -4. Putting this expression into fpc as -2**2 prints -4, Wolfram Alpha (-2^2) too, the same for fpExpressionParser. But Excel and Calc return 4. The need for Excel compatibility forces fpspreadsheet to calculate it as 4, too, although it is based on fpExpressionParser... My personal opinion and math training tells me that the result is -4. Buf for clarity, always use parenthesis: (-2)^2 vs -(2^2).

The same question, BTW, holds for the expression 10^10^10. Is it the same as (10^10)^10 or 10^(10^10)?

[MarkMLl]

This reminds me of a discussion here some years ago about the result of -2^2. About half of the users claimed it to be 4, the other half -4. Putting this expression into fpc as -2**2 prints -4, Wolfram Alpha (-2^2) too, the same for fpExpressionParser. But Excel and Calc return 4. The need for Excel compatibility forces fpspreadsheet to calculate it as 4, too, although it is based on fpExpressionParser... My personal opinion and math training tells me that the result is -4. Buf for clarity, always use parenthesis: (-2)^2 vs -(2^2).

The same question, BTW, holds for the expression 10^10^10. Is it the same as (10^10)^10 or 10^(10^10)?

And /that's/ why APL had distinct "this number is -ve" and "negate this scalar or array" operators, and (much more controversially) had a single level of precedence with right-to-left evaluation unless overridden by parentheses.

It definitely had its weirdnesses (and attracted more than its share of weirdos) but its inventor was a mathematician and he looked after a remarkable number of edge-cases even in its early incarnations.

MarkMLl

[440bx]

Thank you @wp for mentioning the situation where Excel departed from formal mathematical rules.  I couldn't remember what the situation was, now I do.

[wp]

Well I think the source of the problem is that the '-' operator has two meanings: firstly, as operator for subtraction (2-1), and it is clear that it has lower precedence than '*', '/', or '^', secondly, as a unary operator which marks negative numbers (-1), and there does not seem to be an agreed precedence for it  (https://en.wikipedia.org/wiki/Order_of_operations#Unary_minus_sign)

[LV]

“In theory, there is no difference between theory and practice. But, in practice, there is.”— Jan L. A. van de Snepscheut

“The most important property of a program is whether it accomplishes the intention of its user.” ― C.A.R. Hoare

 

[alpine]

Code: Bash  [Select][+][-]

1. $ bash
2. $ let A=-2**2
3. $ echo $A
4. 4
5.  

It is actually a matter of precedence and how it is defined by the language. Well, in FPC it was made higher than the unary '-' but it in Excel someone seems to have decided that it shall have the lower since it is a binary (vs unary) operator.

[440bx]

@wp,

I completely agree.  In those cases I think parentheses should always be used to make the intentions clear instead of depending on precedence levels that may not be the expected ones.

A number of years ago, I needed to write an expression parser and faced all these "subtleties" and decided to make parentheses mandatory whenever operators of differing precedence level occurred consecutively.  At first, it looked like a good idea but, it fairly quickly became obvious that many expressions would be parentheses ridden making thus making them harder to read and, that did not solve the problem of sequences of operators with equal precedence that yield different results depending on how they are grouped, e.g, the exponentiation example you posted.

I don't care to contradict extremely bright people such as C.A.R Hoare but, user intentions often vary from one user to another, measuring anything by how well user intentions are met sounds a bit "unreliable".