Is this a Possible MATLAB bug? (Further strange Behavior)

3 views (last 30 days)
I have encountered a strange behavior while solving one of the problems in Cody. I have simplified the code into the following
function ans = junk(s)
try
s;
catch
999
end
This code gives an error if an output is requested (a=junk(3)), i.e it does not assign s to ans (it does not throw an error, though, within the try block, so adding the catch block has no effect).
The strange part is that if the semicolon is removed or replaced with a comma, it works correctly. Also, if any operation is performed on s (e.g. s+0) it works fine.
If the variable (ans) is invoked within the try block on a separate line after s, it works fine. Strange again, if (ans) is added on the same line as s with a semicolon or a comma, it jumps to the catch block, confirming no assignment in the semicolon case, but not for the comma case which worked fine before.
Any suggestions what causes this behavior? Am I missing something?
UPDATE:
Trying to avoid the try-catch block I tried a switch statement. I encountered further strange behavior of the 'ans' variable. Consider:
function ans = kkk(f,a)
switch nargin
case 1
f;
otherwise
999;
end
This time a=kkk(1) works fine, but when the input is a function handle it errors out
>> a=kkk(1)
a =
1
>> a=kkk(@plus)
Error in kkk (line 2)
switch nargin
Output argument "ans" (and maybe others) not assigned during call to "C:\Users\Dr. K. Hamed\Documents\MATLAB\kkk.m>kkk".
  2 Comments
Oleg Komarov
Oleg Komarov on 29 Aug 2012
I can't find it (and I might be wrong), but I think I read that using ans as an output variable will cause conflicts. I've been googling around for an hour but no results so far about the statement.

Sign in to comment.

Accepted Answer

Philip Borghesani
Philip Borghesani on 31 Aug 2012
There is a bug but it is the opposite of what you think.
function ans=foo(s)
s;
end
Should error in all cases, a single variable on a line should not assign to ans. Try it from the command line:
5;
s=1;
s;
ans
ans =
5
The bug appears to be in the accelerator, if it is disabled then calling foo will error:
>> feature accel off
>> a=foo(1)
Error in foo (line 2)
s;
Output argument "ans" (and maybe others) not assigned during call to "h:\local\foo.m>foo".
  4 Comments
Sven
Sven on 31 Aug 2012
Edited: Sven on 31 Aug 2012
Yes! Ha, this is what I thought (that simply evaluating an already assigned variable "s;" shouldn't be assigned to ans), but I was confused by the fact that doing so inside a function seemed to behave differently than just at the command line.
The fact that putting it in a try/catch statement (which I guess must somehow disable the accelerator?) makes it behave "correctly" again just put us all on the wrong track :)
Thanks for the clarification Philip - it gets a vote.
@Daniel: in the example above s is a function argument, so by the time you're inside the scope of that function, it must actually be a variable stored somewhere and not a "function". Even if it's a function handle, Philip's example stands. On the command line:
5;
s=@()sin;
s;
ans
ans =
5

Sign in to comment.

More Answers (3)

Oleg Komarov
Oleg Komarov on 29 Aug 2012
Edited: Oleg Komarov on 29 Aug 2012
Equivalently
function out = foo(in)
in;
end
will throw the same error.
If you call a = foo(10), the function tries to return a = out, but since the body of the function doesn't contain any assignment to out, it errors (as expected).
Removing the semicolon will still error in the case you call a = foo(10). It will however display in = 10 if I call foo(10).
If you add out after in (no semicolon), before the execution jumps to the catch, it will still display in, which won't happen if out comes before.
In brief, you have to keep in mind two things:
  1. Instructions are executed sequentially
  2. You can't show what doesn't exist (in the workspace)
  8 Comments
Oleg Komarov
Oleg Komarov on 30 Aug 2012
Don't worry and no need to apologize. After all, I was the first who didn't understand the issue at first.

Sign in to comment.


Daniel Shub
Daniel Shub on 30 Aug 2012
I think this is a bug, but your MWE muddies the water. The bug has nothing to do with ans being used as an output. The best set of MWEs that I can come up with is the following functions
function junkA(s)
s;
who
end
function junkB(s)
try
s;
who
end
end
function junkC(s)
try
1;
who
end
end
The WHO reveals the critical difference
>> junkA(1)
Your variables are:
ans s
>> junkB(1)
Your variables are:
s
>> junkC(1)
Your variables are:
ans s
>>
Something happens in the try block that prevents s from being assigned to ans, but it is not a universal failure.
  1 Comment
Khaled Hamed
Khaled Hamed on 30 Aug 2012
Edited: Khaled Hamed on 31 Aug 2012
You do shed more light on the issue. Thanks.
Please note my Update to the question above. Further strange behavior associated with 'ans' in a switch block this time.

Sign in to comment.


Matt Fig
Matt Fig on 29 Aug 2012
According to the documentation,
" The MATLAB software creates the ans variable automatically when you specify no output argument. "
Since this does not happen, I would say it is a bug.

Products

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by