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

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".

[Daniel Shub]

Seems like a bug to me.

[Oleg Komarov]

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.

Answer 1

[Philip Borghesani]

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".

[Khaled Hamed]

That makes a lot of sense. Even the behavior looks more consistent looking at it this way. Now that you mention it, of course "a single variable on a line should not assign to ans". Being used frequently in Cody, this bug was mistaken to be the rule rather than the exception. Thanks for the accurate diagnosis. I am sure fixing it will be an easy task for our capable Mathworks team.

[Daniel Shub]

I disagree. If s is a function it should assign to ans. If s is a function handle then s() should assign to ans. I can think of no reason s should not assign to ans.

[Khaled Hamed]

@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]

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

Answer 2

[Oleg Komarov]

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)

[Khaled Hamed]

No sir, this is not the same situation. The question posted above uses the automatic variable (ans). If you replace:

function ans = foo(in)
in;
end

then it works fine as expected. But not in the case posted. The problem seems to be with assigning the automatic variable (ans) within a try block. Try it yourself.

[Sven]

ans is the automatic variable assigned when an output that isn't already stored in another variable gets evaluated without a variable for it to be assigned to.

In the code:

s = 5;
s;

There is no need for ans - every variable has a place to go.

In the code:

s = 5;
s + 2;

ans is required to store the result of s + 2

[Oleg Komarov]

@Khaled: you're right, there's something glitchy if you use ans as the output variable.

I would not recommend using ans as output variable.

I suspect the display() plays around with ans, thus removing the semicolon affects whether the error is thrown or not.

[Sven]

Ah... I'm surprised.

When inside a function there is the difference you describe. Ignore my comment which is only valid when running directly from the command line.

By any chance are you trying some tricks that will get better Cody scores? ;)

[Khaled Hamed]

I was innocently trying a "shortcut" to get a better Cody score. :) This particular trick secured the lead (without the semicolon, of course). These are the times when glitches seem to appear, when trying unusual (but supposedly legitimate) "shortcuts". That is if it is realy a glitch.

[Oleg Komarov]

@Khaled: I already commented about that and it seems you missed the fact that I recognized the glitch (scroll above or http://www.mathworks.co.uk/matlabcentral/answers/46972#comment_96651)

However, I preferred not to alter my post to keep track of what should be expected and what happens (as you describe).

[Khaled Hamed]

@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]

Don't worry and no need to apologize. After all, I was the first who didn't understand the issue at first.

Answer 3

[Daniel Shub]

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.

[Khaled Hamed]

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.

Answer 4

[Matt Fig]

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.