isnan is an elementwise function, so it’s returning arrays the same size and as x and y, not scalars, which is why && is complaining. You may want to judiciously use the function any with ~isnan and collapse the right dimensions to get a scalar before doing the &&.

–Loren

I want to execute certain functions only if I have at least one non-NaN value in x and at least one NaN value in y. This means that the loop should end in the above example because all values of x is NaN.
But I get this error: ‘Operands to the || and && operators must be convertible to logical scalar values’

Am I doing something wrong here?

Thanks

You might try dbstop if error so you can see the link of code and the values where the issue is exposed.

If that doesn’t help, please contact technical support (link on right of blog) with enough information to reproduce the issue so they can help you.

–Loren

Error in ==> fzero at 333
elseif ~isfinite(fx) || ~isreal(fx)

Error in ==> BRALHX_Condenser_Equations at 69
Fdel=fzero(Fun,1.4766e-007,options);

It will really helpful if I understand more about this error with respect to fzero function.

Cheers
Vinz

Although the rules make sense individually, they are inconsistent*.

What trips me up is when I use an if statement and add a condition later. So I start with

if A then B

and then decide that C is a condition too, so I turn it into

if A & C then B

only to have things crash if A is empty – which was previously not a problem.

I find it counterintuitive that adding code concerning C changes the way A is treated. This makes error-checking a lot more difficult, until you learn to take countermeasures.

I appreciate being able to use empty as false: if the variable has no value, it definitely doesn’t have the right one. This is very intuitive for me. However, I’m now considering teaching myself not to use this shortcut (and adding a short-circuited ~isempty instead), because it might trip me up later, unless I can learn to remember that when adding a condition to an if or while, I also need to add a short-circuited isempty…

I’d really like for the short-circuiting operators to evaluate in the same way that if and while do; not just for empties but also for arrays and such. Is there a particular reason that they require scalar values? Could we get ||| and &&& (for instance) to short-circuit for arrays (including empties)?

* I must admit that it’s quite probable that there is no consistent way to handle this, other than never accepting [] where a logical is expected. This would be more robust for the user (smaller chance of a small change causing large problems), but less convenient. So maybe all of this simply can’t be helped.

Please feel free to use the link at the right to make this enhancement suggestion. I personally don’t mind instead using another try-catch inside the catch block. I find the nesting clarifies my thinking.

–Loren

Best,
Marcel

if {} errors because the expression has to evaluate to something numeric, even if empty. Same for i. Neither one can be converted to a logical array.

–Loren

Another good way to look at the behavior! Thanks.

–Loren

Defining all([])=true has the additional advantage that all([A;B])=(all(A)&all(B)) holds when either array is empty.

The older versions used to generate an error for “if []” didn’t they? (although “if nan”, “if {}” and “if i” still do!) I guess that why I still prefer to write “if ~isempty(x) && all(x(:))” when it’s needed.