ans =
Can Same Commands in Debugger and Command Window Exhibit Different Behavior?
이전 댓글 표시
I was debugging what I'm pretty sure is a bug (or at least an inconsistency) in @doc:subs and came across a behavior that I don't understand. I see a different result in the debugger than in the command window for what looks like the exact same sequence of commands. Everything below is copy/paste from the Matlab window w/ annotations added here. If it matters, the sequence in the debugger was executed while in ...\symbolic\@sym\subs.m
First, in the debugger:
Get roots of polynomial
K>> r = roots([1,1,1]);
Concatenate into a row
K>> X=[r(1),r(2)];
Check the class and size of X
K>> {class(X),size(X)}
ans =
1×2 cell array
{'double'} {[1 2]}
Convert to sym
K>> foo = sym(X);
Check which constructor is called.
K>> which sym(X)
C:\Program Files\MATLAB\R2024a\toolbox\symbolic\symbolic\@sym\sym.m % sym constructor
Check class and size of foo.
K>> {class(foo),size(foo)}
ans =
1×2 cell array
{'sym'} {[1 2]}
Apparently foo is (an ordinary?) 1x2 sym (I went back afterwards and verified that numel(foo) == 2).
So why does foo(1) return the entire array?
K>> foo(1)
ans =
[(3^(1/2)*1i)/2 - 1/2, - (3^(1/2)*1i)/2 - 1/2]
And foo(2) results in error?
K>> foo(2)
Index exceeds the number of array elements. Index must not exceed 1.
Quit debugger
K>> dbquit
Repeat sequence in command window
>> r = roots([1,1,1]);
>> X=[r(1),r(2)];
>> {class(X),size(X)}
ans =
1×2 cell array
{'double'} {[1 2]}
>> foo = sym(X);
>> which sym(X)
C:\Program Files\MATLAB\R2024a\toolbox\symbolic\symbolic\@sym\sym.m % sym constructor
Note that exact same constructor is called as above from the debugger.
>> {class(foo),size(foo)}
ans =
1×2 cell array
{'sym'} {[1 2]}
Here we get the expected indexing behavior.
>> foo(1)
ans =
(3^(1/2)*1i)/2 - 1/2
>> foo(2)
ans =
- (3^(1/2)*1i)/2 - 1/2
>>
What's different between command window and debugger?
Can anyone replicate (or not) this behavior in a more recent release than 2024a?
댓글 수: 2
r = roots([1,1,1]).'
size(r)
foo = sym(r);
size(foo)
foo(1), foo(2)
Confirms same behavior at command window in R2026a; don't have Symbolic TB to check in debugger and haven't yet moved beyond R2024b, either, anyway.
The examples before are possibly just a tad confusing in looking at the results if don't keep straight that the ans variable is the combination of the class and size calls into one cell array, but that's pretty-much immaterial to the conclusion.
Why the debugger acts differently is probably a Q? for MathWorks support, doubt can answer without more access to the internals.
Paul
2026년 9월 6일 20:34
채택된 답변
I suspect the only reason size() reports that foo is 1x2 in the first place is because size() is overloaded by class sym to do so. In fact, foo is just a 1x1 scalar object masquerading as a vector.
Addiitionally, overloaded subsref methods are not active within the class folder. Hence, when you execute commands in debug mode, from within the @sym folder, the indexing operation foo(2) is processed using builtin subsref, which sees foo as the scalar object it truly is, not a 1x2 vector.
댓글 수: 5
If so, is there a way to determine that definitively?
Yes, you can call the built-in size or numel method:
r = roots([1,1,1]);
X=[r(1), r(2)];
foo = sym(X);
size(foo)
builtin('size',foo)
numel(foo)
builtin('numel',foo)
If that's not possible, isn't it an impediment to debugging inside class @ folders?
It has been seen by some users as an impediment, which I imagine is one motivation for introducing Modular Indexing in lieue of subsref.The legacy method of accessing subsref functionality inside the class definition is to call subsref() directly.
Kyle
36분 전
Hi Paul,
Thank you for your question. I'm glad to see that Matt was able to help you get the answer you were looking for.
I wanted to add that this is more of a quirk of legacy subsref/subsasgn, rather than a quirk with the debugger. If you were to insert the same expression as a diagnostic line of code in the sym constructor, you would get the same behavior. The legacy subsref and subsasgn overloads are only called for indexing syntax in expressions outside of the class.
As Matt points out, this is part of the reason that MathWorks suggests new classes use the newer Modular Indexing mixins to implement overloaded indexing. It is not intuitive that foo(1) should behave differently depending on which class executes the expression.
isn't it an impediment to debugging inside class @ folders?
On the other hand, if you are debugging code inside the class, there is an argument to be made that you want objects to behave the same in the debugger as when code is running normally in that same workspace, including the behavior of indexing operations.
If you want overloaded indexing to be operative inside a particular function, e.g.,
function y=func(obj,x)
y=x+obj(2); %overloaded indexing expression
end
then perhaps that function shouldn't be a method at all, and should reside outside the class. Doing so wouldn't prevent you from invoking the function via class method syntax,
y=obj.func(x)
You would just need to make sure dot-indexing was appropriately overloaded in your subsref/subsasgn methods appropriately.
As an aside, I once proposed a new method attribute to let the user decide whether builtin or overloaded indexing is operative inside particular methods, e.g.,
classdef myclass
methods (Indexing=builtin)
function y=func1(obj,x)
end
function y=func2(obj,x)
end
end
methods (Indexing=overloaded)
function y=func3(obj,x)
end
end
end
with the obvious restriction that subsref,subsasgn, and maybe also size and numel, must be inside a block with Indexing=builtin. I was told there are problems with that proposal, but the explanation was beyond my software engineering acumen.
추가 답변 (0개)
카테고리
도움말 센터 및 File Exchange에서 Number Theory에 대해 자세히 알아보기
Translated by 
