Recent

Author Topic: order of evaluation of overloaded functions  (Read 1569 times)

gidesa

  • Full Member
  • ***
  • Posts: 114
Re: order of evaluation of overloaded functions
« Reply #15 on: September 20, 2024, 02:52:24 pm »
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.
« Last Edit: September 20, 2024, 03:55:09 pm by gidesa »

alpine

  • Hero Member
  • *****
  • Posts: 1263
Re: order of evaluation of overloaded functions
« Reply #16 on: September 20, 2024, 03:42:24 pm »
Quote
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.

"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

wp

  • Hero Member
  • *****
  • Posts: 12345
Re: order of evaluation of overloaded functions
« Reply #17 on: September 20, 2024, 04:00:10 pm »
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

  • Hero Member
  • *****
  • Posts: 7617
Re: order of evaluation of overloaded functions
« Reply #18 on: September 20, 2024, 04:15:59 pm »
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 4524
Re: order of evaluation of overloaded functions
« Reply #19 on: September 20, 2024, 05:25:04 pm »
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. :)
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

wp

  • Hero Member
  • *****
  • Posts: 12345
Re: order of evaluation of overloaded functions
« Reply #20 on: September 20, 2024, 05:38:46 pm »
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)

« Last Edit: September 20, 2024, 05:41:24 pm by wp »

LV

  • Jr. Member
  • **
  • Posts: 70
Re: order of evaluation of overloaded functions
« Reply #21 on: September 20, 2024, 05:55:20 pm »
“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

  • Hero Member
  • *****
  • Posts: 1263
Re: order of evaluation of overloaded functions
« Reply #22 on: September 20, 2024, 05:55:45 pm »
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.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

440bx

  • Hero Member
  • *****
  • Posts: 4524
Re: order of evaluation of overloaded functions
« Reply #23 on: September 20, 2024, 06:01:40 pm »
@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".
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018