In message 
<[log in to unmask]>, John 
Pitman <[log in to unmask]> writing at 10:26:36 in his/her local time 
opines:-
>I still don't see the issue. Why is 'not possible' to end evaluation at 
>a False condition followed by AND?

Because if I say A AND B OR C, and the order of evaluation is AND before 
OR, then I can cast this as the equivalent (A AND B) OR C.

And if C is true, then the expression is true, irregardless (Hi Stan!) 
of the truth values of A and B.

But the partial evaluation rule found in the documentation by Steve 
Cooper assumes that if A is false in A AND B OR C, then the whole 
expression is false. That's simply not the case.

> Some may not think its logical (ANYTHING is possible!) , but if its 
>working as documented, one cant complain too much.

Actually, one can complain like hell. It is not for HP, or anyone in HP, 
to rewrite the rules of logic, no matter how accidentally, or however 
carefully they document their mistake.

Neil Armstrong gives the examples I cite above, and you can see that 
while MPE gets the one without parentheses wrong, it gets the logically 
equivalent one with parentheses right:-

Calvin:IF A1=999 AND A2=2 OR A3=3
*** EXPRESSION FALSE: COMMANDS IGNORED UNTIL MATCHING ELSEIF/ELSE/ENDIF


Calvin:IF (A1=999 AND A2=2) OR A3=3
*** EXPRESSION TRUE

In both cases, the order of evaluation should be the same - the first by 
implication, and the second example with parentheses to make it 
explicit.

And so they should give the same result. But they don't. Why?

At a guess, both use the erroneous 'partial evaluation' logic. But 
whereas the first example uses it to resolve the whole expression to 
FALSE, and so gets it wrong, the second one uses it only to resolve the 
sub-expression in parentheses to FALSE, but continues to evaluate, finds 
TRUE after the OR, and correctly resolves FALSE OR TRUE to TRUE.

I will hazard a guess, though, that:-

IF (A1=999 AND A2=2 OR A3=3) OR A3=999

which ought to give TRUE, will also give FALSE. As, in effect, we have 
moved the 'bug' inside the parentheses. i.e., it's not just having 
parentheses that fixes the issue; they must always make the AND/OR 
precedence explicit.

>In Basic/V, INT(x)  function is defined as returning the NEXT LOWEST 
>whole number from x. Hence INT(1.5) returns 1, BUT INT(-1.5) returns 
>-2. Not necessarily what you might want, but as documented.

Yes, this can be a trap for the unwary. However, while it might not be 
what you want [1], it is not just 'as documented', it is also right.

Draw a graph, with the y axis (say) from -5 to +5. Plot some y and 
INT(y) values. (Using the up/down 'y' makes it clearer than the 
left/right 'x').

Note how INT(y) is absolutely consistent; whether y is above or below 
the line, INT(y) is always below y (except in the cases where it is 
exactly the same).

[1] If what you want is INT(ABS(x))*SGN(x) (or whatever the exact syntax 
is in Basic/V) you can always ask for that. But you might be surprised 
in many cases to find that even for negative numbers, the unadorned 
INT(x) is still the number you should use.

All the best

Roy
-- 
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *