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

3 ビュー (過去 30 日間)
Khaled Hamed
Khaled Hamed 2012 年 8 月 29 日
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 件のコメント
Daniel Shub
Daniel Shub 2012 年 8 月 29 日
Seems like a bug to me.
Oleg Komarov
Oleg Komarov 2012 年 8 月 29 日
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.

サインインしてコメントする。

採用された回答

Philip Borghesani
Philip Borghesani 2012 年 8 月 31 日
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 件のコメント
Khaled Hamed
Khaled Hamed 2012 年 8 月 31 日
@Daniel, The second part is true, s() should assign to answer since it is a calculation, but I think Philip's account on s alone is also true.
Sven
Sven 2012 年 8 月 31 日
編集済み: Sven 2012 年 8 月 31 日
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

サインインしてコメントする。

その他の回答 (3 件)

Oleg Komarov
Oleg Komarov 2012 年 8 月 29 日
編集済み: Oleg Komarov 2012 年 8 月 29 日
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 件のコメント
Khaled Hamed
Khaled Hamed 2012 年 8 月 30 日
編集済み: Khaled Hamed 2012 年 8 月 30 日
@Oleg, I am terribly sorry I missed your new comment (I was caught by the modifications you made with the original answer, which I now see aimed at clariying the case without using (ans). I have removed my incorrect comment. Please accept my sincere apology.
Oleg Komarov
Oleg Komarov 2012 年 8 月 30 日
Don't worry and no need to apologize. After all, I was the first who didn't understand the issue at first.

サインインしてコメントする。


Daniel Shub
Daniel Shub 2012 年 8 月 30 日
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 件のコメント
Khaled Hamed
Khaled Hamed 2012 年 8 月 30 日
編集済み: Khaled Hamed 2012 年 8 月 31 日
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.

サインインしてコメントする。


Matt Fig
Matt Fig 2012 年 8 月 29 日
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.

カテゴリ

Help Center および File ExchangeLoops and Conditional Statements についてさらに検索

タグ

製品

Community Treasure Hunt

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

Start Hunting!

Translated by