I still don't see the issue. Why is 'not possible' to end evaluation at a False condition followed by AND? Some may not think its logical (ANYTHING is possible!) , but if its working as documented, one cant complain too much.
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.
Regards,
John Pitman
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf Of Roy Brown
Sent: Monday, 11 January 2010 10:14 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Bug in CI expression evaluation?
In message <BEA74B6095A54BFAB3EF52EFDFDD0589@monk>, Steve Cooper
<[log in to unmask]> writing at 13:20:37 in his/her local time opines:-
>Here's the relevant section from Appendix B of the Commands Manual:
>
>----------------------------------
>The rules of precedence determine which operations are performed before
>others. Their order, from highest to lowest priority, is:
...
>Logical operations: AND, NOT
>Logical operations: OR, XOR
>Evaluation is left to right until the evaluation is complete, or until
>a fatal error has been detected. If a fatal error is detected,
>evaluation terminates.
>Completion of evaluation in this case means either end of expression or
>partial evaluation of expression.
>In the latter case (partial evaluation), the result of the evaluation can be
>determined without examining the rest of the expressions. For example, when
>part of an expression that is evaluated to FALSE is followed by an AND, or
>is evaluated to TRUE and is followed by an OR:
I call 'bug' here - or 'design fault' if you like.
The above sentence has a logic error; it is *not* possible to cease
evaluation at FALSE followed by AND, as the designer has erroneously
assumed. Since a subsequent OR may override it, as in Walter's example.
Always assuming that the precedence of AND over OR, as described above,
is accurate, of course.
>So, I don't like it either, but it is working as documented. We have
>exactly the case in that last paragraph: a part evaluates to FALSE and
>is followed by an AND.
>Sorry, no bug here, just a weird design that I'm sure people are
>counting on at this point.
A *wrong* design, but I agree that there may well be JCL out there that
now relies on it, so I guess we have to live with it. Even if OpenMPE
ever gets its mitts on it.
Interesting philosophical question, though; which is more correct, a
program that faithfully implements a logic error in the design, or a
program that departs from the design, but gets the logic right? :-)
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 *
CAUTION: This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify RYCO Hydraulics Pty. Ltd. immediately. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of RYCO Hydraulics Pty. Ltd.
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
