Recent

Author Topic: Evaluation of constant statements  (Read 4512 times)

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 306
  • My software never cras....
Evaluation of constant statements
« on: September 21, 2022, 04:20:26 pm »
Code: Pascal  [Select][+][-]
  1. CONST
  2.   TFy = 0.95;
  3.   TFx = 1 - TFy;
  4.  

and later on

Code: Pascal  [Select][+][-]
  1.    y := x * TFx;     //or
  2.    y := TFx * x;
  3.  

When I read this it irks me from an algebra POV....

I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

KodeZwerg

  • Hero Member
  • *****
  • Posts: 917
  • Fifty shades of code.
    • Delphi & FreePascal
Re: Evaluation of constant statements
« Reply #1 on: September 21, 2022, 04:25:02 pm »
Code: Pascal  [Select][+][-]
  1. CONST
  2.   TFy = 0.95;
  3.   TFx = 1 - TFy;
Code: Pascal  [Select][+][-]
  1. CONST
  2.   TFy = Double(0.95);
  3.   TFx = Double(1 - TFy);
Thats how I would write such to have a proper type set.
« Last Edit: Tomorrow at 31:76:97 by KodeZwerg »

KodeZwerg

  • Hero Member
  • *****
  • Posts: 917
  • Fifty shades of code.
    • Delphi & FreePascal
Re: Evaluation of constant statements
« Reply #2 on: September 21, 2022, 04:28:33 pm »
I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.
The constant will be "calculated" at the point when you set it, at least that's how it should work.
« Last Edit: Tomorrow at 31:76:97 by KodeZwerg »

Thaddy

  • Hero Member
  • *****
  • Posts: 12614
Re: Evaluation of constant statements
« Reply #3 on: September 21, 2022, 04:32:06 pm »
Code: Pascal  [Select][+][-]
  1. CONST
  2.   TFy = 0.95;
  3.   TFx = 1 - TFy;
  4.  

and later on

Code: Pascal  [Select][+][-]
  1.    y := x * TFx;     //or
  2.    y := TFx * x;
  3.  

When I read this it irks me from an algebra POV....

I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.

The compiler sticks to mathematical operator precedence. See the manual.
https://www.freepascal.org/docs-html/ref/ref.html#QQ2-151-184
The tables are listed in precedence order. Note ** is implemented by the programmer, it is listed at that position because ** is a special form of multiplication.

If you are not sure, you can indeed enclose a partial expression using ( and ) but carefully written code should not need that in all cases because of the above.
« Last Edit: September 21, 2022, 04:34:57 pm by Thaddy »
Writing code in an overly complex way is usually merely a complete misunderstanding of the goal you are trying to achieve.

440bx

  • Hero Member
  • *****
  • Posts: 3267
Re: Evaluation of constant statements
« Reply #4 on: September 21, 2022, 04:33:51 pm »
I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.
true constants are evaluated at compile time, therefore the expression (1- TFy) doesn't exist past its declaration, what exists after its evaluation is its result.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 12614
Re: Evaluation of constant statements
« Reply #5 on: September 21, 2022, 04:37:02 pm »
true constants are evaluated at compile time, therefore the expression (1- TFy) doesn't exist past its declaration, what exists after its evaluation is its result.
Yes, but the precedence is equal at both compile time and runtime. 1-Tfy still relies on the same precedence even if it is already resolved at compile time. The evaluation order is the same both ways.

I interpreted his unease in that fashion, but indeed true const expressions are evaluated before compilation and replaced by a single constant. The same is true for typed constants in {$J-} mode also.
« Last Edit: September 21, 2022, 04:51:13 pm by Thaddy »
Writing code in an overly complex way is usually merely a complete misunderstanding of the goal you are trying to achieve.

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 306
  • My software never cras....
Re: Evaluation of constant statements
« Reply #6 on: September 21, 2022, 04:57:05 pm »
Code: Pascal  [Select][+][-]
  1. CONST
  2.   TFy = 0.95;
  3.   TFx = 1 - TFy;
Code: Pascal  [Select][+][-]
  1. CONST
  2.   TFy = Double(0.95);
  3.   TFx = Double(1 - TFy);
Thats how I would write such to have a proper type set.

Well, I did have
Code: Pascal  [Select][+][-]
  1.     TFy: Single = 0.95;
  2.    Tfx: Single = 1 - TFy;
  3.  
But that failed to compile.

But your solution works fine for me.  Never thought of a type cast in a constant statement.

Thanks.
« Last Edit: September 21, 2022, 04:59:45 pm by AlanTheBeast »
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 306
  • My software never cras....
Re: Evaluation of constant statements
« Reply #7 on: September 21, 2022, 05:05:05 pm »
I don't get that warm and fuzzy feeling that (1-TFy) is operated separately before (or after) the multiplication.
true constants are evaluated at compile time, therefore the expression (1- TFy) doesn't exist past its declaration, what exists after its evaluation is its result.

What bothers me is that if I do a nice simple integer const set up such as:

Code: Pascal  [Select][+][-]
  1. CONST
  2.   A = 43;
  3.   B = 72-A;

There is no compile time error.  I take the B as pre-computed and snug as a bug in rug.

Yet,
Code: Pascal  [Select][+][-]
  1. CONST
  2.     TFy: Single = 0.95;
  3.    Tfx: Single = 1 - TFy;

Fails to achieve snug buggness.

IAC, KodeZwerg's solution is fine for my needs.

Thanks.
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

Thaddy

  • Hero Member
  • *****
  • Posts: 12614
Re: Evaluation of constant statements
« Reply #8 on: September 21, 2022, 05:08:41 pm »
Indeed, I made a mistake. Type constants will throw an error.
Writing code in an overly complex way is usually merely a complete misunderstanding of the goal you are trying to achieve.

Arioch

  • Sr. Member
  • ****
  • Posts: 415
Re: Evaluation of constant statements
« Reply #9 on: September 21, 2022, 05:37:35 pm »
Code: Pascal  [Select][+][-]
  1. {$J-}
  2.  
  3. const A: integer = 10;
  4. const B = A + 2;  // unit1.pas(87,1) Error: Illegal expression
  5.  

indeed, this compiles neither in Delphi nor in FPC.

Frankly, to me it looks like compiler defficiency. A bug wit hpriority too low to ever get fixed.

Unless they tacitly encourage hacks like

Code: Pascal  [Select][+][-]
  1. {$J-}
  2. const A: integer = 10;
  3. var B: PInteger;
  4. begin
  5.   B := @A; B^ := 20;
  6.  


KodeZwerg

  • Hero Member
  • *****
  • Posts: 917
  • Fifty shades of code.
    • Delphi & FreePascal
Re: Evaluation of constant statements
« Reply #10 on: September 21, 2022, 05:52:15 pm »
IAC, KodeZwerg's solution is fine for my needs.
Thanks.
I am glad to help  O:-)

Never thought of a type cast in a constant statement.
Hmmm... I am not sure if I would call it a typecast, I would call it a typed constant  :D
« Last Edit: Tomorrow at 31:76:97 by KodeZwerg »

440bx

  • Hero Member
  • *****
  • Posts: 3267
Re: Evaluation of constant statements
« Reply #11 on: September 21, 2022, 06:05:22 pm »
Well, I did have
Code: Pascal  [Select][+][-]
  1.     TFy: Single = 0.95;
  2.    Tfx: Single = 1 - TFy;
  3.  
But that failed to compile.
It doesn't compile because those are not true constants. The compiler cannot evaluate Tfx because it involves TFy which is NOT a constant (it is stored somewhere in the data segment instead of only existing in the compiler's parsing table(s)).
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 SP1 64bit.

AlanTheBeast

  • Sr. Member
  • ****
  • Posts: 306
  • My software never cras....
Re: Evaluation of constant statements
« Reply #12 on: September 21, 2022, 06:40:54 pm »
Well, I did have
Code: Pascal  [Select][+][-]
  1.     TFy: Single = 0.95;
  2.    Tfx: Single = 1 - TFy;
  3.  
But that failed to compile.
It doesn't compile because those are not true constants. The compiler cannot evaluate Tfx because it involves TFy which is NOT a constant (it is stored somewhere in the data segment instead of only existing in the compiler's parsing table(s)).

"true constant"?  What does that even mean?  A constant is a constant whether integer or float... is pi a constant?  Is it true?  False?

Syntactically dumb since it will evaluate integers correctly as I noted above, and it's not hyperdrive-rocketry to evaluate the expression as I wrote it.  I agree with Mr. Arioch that this appears to be a deficiency in the compiler.  Or at least an inconsistency.

I really don't see the issue with a constant being set float, esp. if the code specifies the data size as I did:      z: single = y*0.333;

I'm not a compiler expert to be sure, but allowing the integer constants to evaluate as I pointed out above, but not floating point seems to be a glaring inconsistency.

To whit, I'm not sure if the constant expression is inserted in the code - and therefore leaving me to wonder about the algebraic "sanity" of the whole thing.

Which is why people resort to hacks as Arioch suggests (not that I'd go there).

Anyway CodeZwerk's suggestion is fine and the universe did not break on compile or execution.

Never thought of a type cast in a constant statement.
Hmmm... I am not sure if I would call it a typecast, I would call it a typed constant  :D

  %)

Usually a typed constant looks (to little old me) like:
 x:   word = 33333;

Your slipping in the parentheses seems hacky...  but hacky-work is better than code that doesn't compile ---- !
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

wp

  • Hero Member
  • *****
  • Posts: 10478
Re: Evaluation of constant statements
« Reply #13 on: September 21, 2022, 06:51:23 pm »
"true constant"?  What does that even mean?
This is a pecularity of the Pascal language, I think introduced in the old Turbo days:

Code: Pascal  [Select][+][-]
  1. const
  2.   a: Integer = 1;
  3.  

This does not declare a constant, but a variable with initial value 1.

In current code, this is the same as
Code: Pascal  [Select][+][-]
  1. var
  2.   a: Integer = 1;
  3.  

440bx

  • Hero Member
  • *****
  • Posts: 3267
Re: Evaluation of constant statements
« Reply #14 on: September 21, 2022, 07:23:12 pm »
"true constant"?  What does that even mean?  A constant is a constant whether integer or float... is pi a constant?  Is it true?  False?
@wp answered your question but, more generally, anytime you declare a constant and specify its type (a typed constant) then you are actually declaring a _variable_.

Note that a typed constant is a different animal than a typecasted constant.  For instance:
Code: Pascal  [Select][+][-]
  1. const
  2.   a : integer = 1;  { this is a typed constant which means it is a _variable_ }
  3.  
  4.   b = integer(1);  { this is a true constant, _not_ a variable - note that a _type_ is _not_ specified }
  5.  
Whether "a" above is writeable or not depends on the setting of the compiler directive "$WRITEABLECONST".  if ON then the compiler places "a" is in the writeable section (usually "data"), if OFF then the compiler places it in a read-only section (don't remember the name it uses at this time for those) but, what's important is that in _either_ case "a" represents an address somewhere in memory whereas a _true_ constant is a named value the compiler keeps in its tables and whenever it sees the name of the constant, it replaces it with the value it calculated for it.

HTH.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018