Certainly it is fair for you to defend the way MatLab operates. And, you are correct regarding the documentation of the “if” statement.

Even though I continue to lobby MatLab for specific improvements in the documentation when I encounter deficiencies, the documentation for “if” is very good.

However, for well designed software, the documentation serves as a backstop to its logical & reasonable operation. Further, in this case, the documentation of the “or” operator doesn’t give any hint to its different behavior when imbedded in an “if” statement.

I stand by the point I made that none of us here think it is reasonable for the outcome for an “or” operation be order dependent.

Further, I am more troubled by Steve’s comments regarding the specification for the “or” statement. A reasonable answer would be something like, “Yes MatLab’s specification for the “or” statement does discuss this behavior, but for proprietary reasons, we can’t share it with you.” Instead, he glosses over the issue with a “non-denial-denial.”

In my first reply to this, on November 1, I assumed there was a performance benefit to this feature and asked for an example. No reply yet. Show us how these other customers have taken advantage of this feature.

Reading between the lines, I suspect that this behavior kind of “happened” in the original version of MatLab and has recently been incorporated into the current specifications.

Here is the bottom line: MatLab is an expensive bit of software that is well worth the price. It is generally very well designed and has outstanding documentation. Users can quickly engage with MatLab even when approaching it from varied backgrounds and perspectives.

However, for the users like me and those around me, this feature that we’ve been discussing is not expected and Loren’s column is a good forum to discuss it. I read her column just so I can learn these details. Give some examples as I discuss above and then we’ll move on to other topics.

We cannot change this behavior now without breaking a great deal of existing customer code. So what we have done instead is to introduce the scalar, always-short-circuiting logical operators, and to encourage their use in if and while conditionals. The MATLAB Editor will even make this suggestion to you if you use “|” or “&” in an if or while conditional expression.

I think that MatLab has made this sufficiently complex.

Let’s go back to the “or” operator.

>> []|4

ans =

[]

>> 4|[]

ans =

[]

As expected, I get the empty result, regardless of order of the inputs.

But, there is no rational justification for the different result if imbedded in an if or while statement.

>> if []|4
disp(’true’);
else
disp(’false’);
end;
false

>> if 4|[]
disp(’true’);
else
disp(’false’);
end;
true
>>

What does the specification for the MatLab “if” statement say regarding this feature?

Or, was the “if” statement written without a specification?

You are missing the part about scalar expansion that works with many operators in MATLAB, including +, |, &. If I say

x = 1:3
y = []
x+y

I get the error message about matrix dimensions must agree, but I don’t if x = 3. In that case, MATLAB does a scalar expansion and I get the scalar to expand to the size 0×0 and therefore, I get an empty result.

The same thing is happening with

if [] | 4
  whatever
end

MATLAB can’t tell from the first part of the expression if the entire expression is true yet, so it keeps going. Then MATLAB computes [] | 4, using scalar expansion, empty is returned as the final expression for the if statement, and the result is then treated as false.

–Loren

Here are some commands and comments to illustrate:

First, rationally, the “or” operator should operate on logical variables. But, clearly it is an advantage if MatLab can convert from other data types to logical within the arguments of the operator. So, a question we asked was, how does MatLab convert doubles to logicals?

logical(4)

ans =

1

This makes sense and is what we expect.

Now a slightly harder situation, converting an empty double to logical.

>> logical([])

ans =

[]

>> isempty([])

ans =

1

This makes sense, an empty double gets converted to an empty logical.

Now, how does the “or” operator deal with different sizes of variables:

>> (1:5)|(1:4)
??? Error using ==> or
Inputs must have the same size.

How about if one is empty?

>> (1:5)|([])
??? Error using ==> or
Inputs must have the same size.

That makes sense because the empty variable has size zero.

>> size([])

ans =

0 0

With this background, the expected response within the “if” statement would be the same error message.

Further, it certainly doesn’t make sense for the “or” operator to short circuit to false when the first variable is false. Although this makes sense for an “and” operator, doesn’t the “or” operator always have to test both?

Thanks for pointing this out. I was thinking about if and while so I went back and made that more explicit.

–Loren

data=rand(100,1);
middleHalf=data(data>0.25 & data