Instable evaluation of combined logical expressions

[Jörg Bretschneider]

David Bateman wrote:
> John W. Eaton wrote:
>> On 13-Feb-2009, Jörg Bretschneider wrote:
>>
>> | Bug report for Octave 3.0.3 configured for i686-pc-msdosmsvc
>> | | Description:
>> | -----------
>> | | Octave seems to evaluate all expressions in combined logical
>> condition
>> | expressions,
>> | i.e.    cond1 LOGICALOPERATOR cond2 (LOGICALOPERATOR ...)
>> | even if the logical result of the condition is already determined by
>> the
>> | first condition
>> | An error occurs if the syntactical validity of the second or further
>> | conditions depends
>> | on a FALSE value of the first condition, e.g. an index request into an
>> | empty matrix.
>> | It is not unusual to check the length of an array first in order to
>> | request a condition
>> | on some of its elements. The example works with Matlab for years, but
>> | not Octave 3.0.x
>> | | Repeat-By:
>> | ---------
>> | |   x=[];   if ~isempty(x)   &   x(1) ~= 0,   disp('do
>> something'),   end
>> | | Fix:
>> | ---
>> |     A work around for this was to pose multiple separate IF conditions,
>> |     but this is not the preferred way, as octave can easily understand
>> |     that an AND expression is FALSE if its first condition is, as well
>> |     as an OR expression is TRUE if its first condition is, there may be
>> |     other instances but the first one is the most important case.
>> |     I had to adapt hundreds of lines of M-code to make it compatible.
>>
>> We consider the way that | and & short-circuit to be a bug in Matlab,
>> because they only short-circuit in some instances (IF and WHILE
>> conditions) and the behavior is different if you do
>>
>>   t = a & b;
>>   if (t) ...
>>
>> vs
>>
>>   if (a & b) ...
>>
>> A better solution for you is to use the && and || operators which
>> always do short-circuiting.
>>
>> jwe
>>
>>   
> A even better solution would have been to read the FAQ
> 
> http://www.gnu.org/software/octave/FAQ.html#MATLAB-compatibility
> 
> before posting
> 
> D.
> 
> 

I was not aware of that bug in matlab, and also didn't come across the
Matlab/octave compatibility section in the FAQ so far, sorry for that.
Nevertheless I would have posted the following on the issue.

Working with R13, I never used  && and || in matlab either, as these
operators have been introduced later, in R14 or R2006, I don't know for
sure. Indeed, && and || seem to have been introduced solely as
short-circuit and scalar versions of & and |, and Mathworks did not the
full job required. & and | are short-circuiting in matlab (at least in
if and while statements) from the beginning (I started with matlab 4 in
1996), and this is natural, as most people will evaluate a combined
logical expression from left to right and would stop if the result was
clear before all parts of the whole expression have been weighed.

Octave implements a strict mathematical approach, which is pure science
in its own right, but not so practical at times. I am a mathematician,
but I am also a partner for engineers, which is a major field where
matlab and hence octave are used.

I suggest that octave developers implement a straightforward AND
"natural" alternative to matlabs buggy versions, i.e., let & and | be
bitwise short-circuiting at all instances where they may be used. This
should not affect older octave code which didn't make use of
short-circuiting, but would, btw, allow the vast archive of "older"
m-code to be run without trouble in octave.

The new operators && and || are superfluous imho, as one can use all()
or any() to implement the same conditions with & and | on matrix
arguments. But they have come into broad use recently with matlab,
a.f.a.i.k, and hence must remain in octave for compatibility, of course.


-- 
Jörg Bretschneider

Fraunhofer-Institut für Integrierte Schaltungen
Institutsteil Entwurfsautomatisierung
Zeunerstr. 38,
01069 Dresden,
Germany

Tel. ++49(0)351/4640-749
Fax: ++49(0)351/4640-703
Joerg.Bretschneider at eas.iis.fraunhofer.de
www.eas.iis.fraunhofer.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3627 bytes
Desc: S/MIME Cryptographic Signature
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090217/f988f18d/attachment.bin