Bookstore

 Computer Math and Games in Pascal (preview) Lazarus Handbook (preview only)

Author Topic: How is "not condition1 and condition2" evaluated?  (Read 2774 times)

Kays

• Full Member
• Posts: 181
• Whasup!?
Re: How is "not condition1 and condition2" evaluated?
« Reply #15 on: July 12, 2019, 11:49:30 pm »
[…] See here: https://en.wikipedia.org/wiki/Order_of_operations
These operators differ in weight.
Yeah, I knew that, I simply never called it “weight” (and neither did the Wikipedia authors). For me weight is a concept from physics.
Boolean operators do not have a defined precedence, they are all equal and their evaluation by the compiler is left to right.
Huh??? That surprises me, though. Boolean operators are obviously mentioned in the precedence table in chapter “expressions” of the reference manual, are they not?
Yours Sincerely
Kai Burghardt

lucamar

• Hero Member
• Posts: 2017
Re: How is "not condition1 and condition2" evaluated?
« Reply #16 on: July 13, 2019, 01:08:36 am »
Huh??? That surprises me, though. Boolean operators are obviously mentioned in the precedence table in chapter “expressions” of the reference manual, are they not?

IIRC, those mentioned in that table are not the boolean operators but the bitwise (logical) ones. I may be wrong, though.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!)
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.

Kays

• Full Member
• Posts: 181
• Whasup!?
Re: How is "not condition1 and condition2" evaluated?
« Reply #17 on: July 13, 2019, 01:45:54 am »
[…] IIRC, those mentioned in that table are not the boolean operators but the bitwise (logical) ones. I may be wrong, though.
Yeah, I had that idea, too, but that isn’t plausible, § Boolean operators: “Boolean operators can be considered as logical operations on a type with 1 bit size.” Ergo, you can just ignore the fact Pascal defines a dedicated Boolean data type and treat everything as integers, just as C does. The operator precedence table retains its validity.

PS: The documented operator precedence is concordance with ISO 7185.
« Last Edit: July 13, 2019, 02:06:23 am by Kays »
Yours Sincerely
Kai Burghardt

• Hero Member
• Posts: 8901
Re: How is "not condition1 and condition2" evaluated?
« Reply #18 on: July 13, 2019, 09:58:10 am »
I was a bit unclear myself: re-read my posts and replace Boolean with logical. That should suffice.
Most people that want to use threading should learn to patch their jeans first: use a needle.

BrunoK

• Full Member
• Posts: 181
• Retired programmer
Re: How is "not condition1 and condition2" evaluated?
« Reply #19 on: July 13, 2019, 12:07:21 pm »
Whatever the rules,
Code: Pascal  [Select]
1.   if (b1 or b2) = b3 then
2.
3.   if b3 = (b2 or b1) then
4.
parentheses to explicit the test precedence helps maintenance.

As a not 'superior logical' programmer it is how I have written those type of multi conditions for the last 30 years.
Lazarus trunk r. 59978/03.01.2019 (+/- patches regarding enabled, TScrollBar, TCursorImage). FPC 3.0.4 32 bits. (+heaptrc with leaked ClassName+Revisited TList) , Windows 10 Pro x64 (v. 1903)

glorfin

• Jr. Member
• Posts: 61
Re: How is "not condition1 and condition2" evaluated?
« Reply #20 on: July 14, 2019, 02:02:42 am »
a and not b will negate b.
This is perfectly unclear statement.
Obviously, here "a" will be evaluated, if it is false, no further processing continues and "false" is returned, because FPC, as far as I remember, uses lazy evaluation.
If "a" is true, it evaluates "not b"; if "not b" is false, it stops with "false" as result, otherwise "and" is evaluated and "true" returned.

Obviously, this is much more than just negation of b.
So, what did you want to say apart from being arrogant, as usually, is not clear.

glorfin

• Jr. Member
• Posts: 61
Re: How is "not condition1 and condition2" evaluated?
« Reply #21 on: July 14, 2019, 02:09:19 am »
The net result is to make it look as if it had precedence, but it isn't really so.
If it always looks like it has precedence, maybe it is more simple to say that it has precedence?

lucamar

• Hero Member
• Posts: 2017
Re: How is "not condition1 and condition2" evaluated?
« Reply #22 on: July 14, 2019, 04:05:09 am »
The net result is to make it look as if it had precedence, but it isn't really so.
If it always looks like it has precedence, maybe it is more simple to say that it has precedence?

When talking informally, yes, maybe; but in a technical forum one should strive to be as precise as one can. At least that's what I think.

For example, iin:
Code: [Select]
not a and b the fact that it means
Code: [Select]
(not a) and bis just an artifact of left-to-right parsing; parsed right-to-left it would mean:
Code: [Select]
not (a and b).
I don't think it will change tomorow (or ever, if for nothing else than backwards compatibility) but it might, and one has to be aware of it.

Or I may be completely wrong. It can happen too
« Last Edit: July 14, 2019, 04:15:26 am by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!)
Lazarus 2.0.2/2.0.4  - FPC 3.0.4 on:
(K|L)Ubuntu 12..16, Windows XP SP3, various DOSes.

PascalDragon

• Hero Member
• Posts: 618
• Compiler Developer
Re: How is "not condition1 and condition2" evaluated?
« Reply #23 on: July 14, 2019, 11:41:49 am »
a and not b will negate b.
This is perfectly unclear statement.
Obviously, here "a" will be evaluated, if it is false, no further processing continues and "false" is returned, because FPC, as far as I remember, uses lazy evaluation.
If "a" is true, it evaluates "not b"; if "not b" is false, it stops with "false" as result, otherwise "and" is evaluated and "true" returned.

Obviously, this is much more than just negation of b.
So, what did you want to say apart from being arrogant, as usually, is not clear.
The short hand evaluation of Boolean expression can be controlled using the \$B directive. See here.

The net result is to make it look as if it had precedence, but it isn't really so.
If it always looks like it has precedence, maybe it is more simple to say that it has precedence?

When talking informally, yes, maybe; but in a technical forum one should strive to be as precise as one can. At least that's what I think.

For example, iin:
Code: [Select]
not a and b the fact that it means
Code: [Select]
(not a) and bis just an artifact of left-to-right parsing; parsed right-to-left it would mean:
Code: [Select]
not (a and b).
I don't think it will change tomorow (or ever, if for nothing else than backwards compatibility) but it might, and one has to be aware of it.

Or I may be completely wrong. It can happen too
The order of parsing will not change, because that's part of the Pascal standard (no matter if early Wirth's Pascal, ISO Pascal or Delphi language).

Peter H

• Jr. Member
• Posts: 54
Re: How is "not condition1 and condition2" evaluated?
« Reply #24 on: July 14, 2019, 02:29:40 pm »
Code: Pascal  [Select]
1. program Project1;
2.
3. begin
4.
5. writeln (true or true and false);
6. writeln (false and true or true);
8.
9. end.
10.
11.

This program prints "TRUE","TRUE" in FPC 3.3.1.
Same result in Delphi and in fpc 3.0.4.
So it seems the "and" operator has higher priority than "or".
(It is the same in C and in boolean algebra notation, "and" is treated as a multiplicative operator and has higher priority)
I am a little bit confused.
My book says all boolean operators have the same priority in pascal, but that doesnt seem true to me.
Obviously my book
https://www.amazon.de/Lazarus-Essentials-Peter-Wolfinger/dp/198304508X/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=lazarus+essentials&qid=1563114995&s=gateway&sr=8-1
(Otherwise this is a very good book)
So, whats about the priority of "exor"? (I think it is equal to or, because thats the common convention)

So this means, if there is left to right short circuit evaluation, in this code:
Code: [Select]
writeln (false and foo_a() or foo_b());

foo_a() will not be called.
foo_b() will be called.

This stuff is a little bit confusing and many books and websites explain it wrong or not at all.
« Last Edit: July 14, 2019, 04:38:37 pm by Peter H »

jamie

• Hero Member
• Posts: 1990
Re: How is "not condition1 and condition2" evaluated?
« Reply #25 on: July 14, 2019, 04:29:55 pm »
years ago before sanity kicked in, ANDing two numbers meant multiplying them...

There was no such thing as a limit to a number, the size of the number was always infinite,

So True * True  would be true..

Since True in the compiler generates the initial value of 1 it kind of works out..

but if two numbers were valid, them multiplying each other would always turn out valid other than 0.

but as you know, multiply any number by 0 you get zero.

so since in this thinking its logical to treat the AND as a multiplier when doing such things..

remember a True is any number other than 0.

In the computer world in the background the actual process isn't done that way because you could
end with a 0 results if you don't have some sort of overflow control taking place plus it would be
inefficient so they still keep with the old school math of order but process it logically in the background.

That is the way I understand it from my old days of math (YEARS ago)…

Peter H

• Jr. Member
• Posts: 54
Re: How is "not condition1 and condition2" evaluated?
« Reply #26 on: July 14, 2019, 04:43:00 pm »
In programs there is time.
Wirth tried to make pascal conform to mathematical notation.
But in mathematics and logic there is no time, there is no cause-effect relationship in boolean algebra.
So this try can be only partial successful, it is an impossible try....
« Last Edit: July 14, 2019, 04:53:34 pm by Peter H »

Peter H

• Jr. Member
• Posts: 54
Re: How is "not condition1 and condition2" evaluated?
« Reply #27 on: July 14, 2019, 05:21:38 pm »
Code: Pascal  [Select]
1. program Project1;
2.
3.   function t1: boolean;
4.   begin
5.     t1 := True;
6.     writeln('t1 was called');
7.   end;
8.
9.   function t2: boolean;
10.   begin
11.     t2 := True;
12.     writeln('t2 was called');
13.   end;
14.
15. begin
16.   writeln(t1 and False or t2);
17.   writeln('Next try');
18.   writeln(False and t1 or t2);
19.
21. end.
22.

Output:

t1 was called
t2 was called
TRUE
Next try
t2 was called
TRUE

Short circuit evaluation means: Two logical equivalent expressions have identical results, but different (side) effect.
« Last Edit: July 14, 2019, 05:26:39 pm by Peter H »

jamie

• Hero Member
• Posts: 1990
Re: How is "not condition1 and condition2" evaluated?
« Reply #28 on: July 14, 2019, 05:29:13 pm »
Looks normal to me..

No mater the AND results you are ORing with a TRUE. so it will always be true

the AND operation is first which yields a FALSE then you OR with a TRUE because T2 is returning true.

so its One "OR" the Other!

ASerge

• Hero Member
• Posts: 1406
Re: How is "not condition1 and condition2" evaluated?
« Reply #29 on: July 14, 2019, 08:37:41 pm »
Output:

t1 was called
t2 was called
TRUE
It was a good idea if the compiler could optimize such code by removing the call to the t1 function, which does not affect the result. The side effect of calling a function here is still not guaranteed by the documentation.
In justification, we can say that Delphi behaves in the same way.
FPC:
Code: ASM  [Select]
1. project1.lpr:19                           B := (t1 and False) or t2;
2. 000000010000150E e84dffffff               call   0x100001460 <T1>   ; unnecessary function call
3. 0000000100001513 84c0                     test   al,al              ; The result is even tested, but not used
4. 0000000100001515 e896ffffff               call   0x1000014b0 <T2>
5. 000000010000151A 84c0                     test   al,al
6. 000000010000151C 7405                     je     0x100001523 <main+35>
7. 000000010000151E 40b601                   mov    sil,0x1
8. 0000000100001521 eb03                     jmp    0x100001526 <main+38>
9. 0000000100001523 40b600                   mov    sil,0x0
10. project1.lpr:20                           writeln(B);
Delphi:
Code: ASM  [Select]
1. Project15.dpr.19: B := (t1 and False) or t2;
2. 000000000040E8DF E80CFFFFFF       call t1             ; Here, too, unnecessary function call, but the result is immediately ignored
3. 000000000040E8E4 E867FFFFFF       call t2
4. 000000000040E8E9 84C0             test al,al
5. 000000000040E8EB 7504             jnz Project1 + \$31
6. 000000000040E8ED 33C0             xor eax,eax
7. 000000000040E8EF EB02             jmp Project1 + \$33
8. 000000000040E8F1 B001             mov al,\$01
9. 000000000040E8F3 8805E7A80000     mov [rel \$0000a8e7],al
10. Project15.dpr.20: writeln(B);