subsref overload has fewer outputs than expected on cell attribute

Question

Nath 2012-12-28

4
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/57562-subsref-overload-has-fewer-outputs-than-expected-on-cell-attribute

编辑： per isakson 2016-9-14

I am overloading subsref in a class (reason is out topic here). Say for simplicity that my subsref should have the same behaviour as the builtin subsref in everycase. So I simply wrap a call to the builtin. But when using instance.some_cell{:}, where some_cell is a cell attribute, only the first element of the instance.some_cell is returned by my subsref.

In the following exemple, you can see a if bloc in subsref. Its only purpose is to pick the proper nargout size. The debugger shows me that varargout is of correct size (ie 3) right before my subsref returns. However, once my subsref is done, I only receive the first cell element oustide !!!

    instance= exemple_subsrf_oncell({1,2,3});
    instance.some_cell
    instance.some_cell{:} %WEIRD returns only 1

I know numel isn't involved here, because some_cell is of a builtin type. I wonder how I should define subsref so that it returns me the proper number of outputs when using expression like instance.some_cell{:} I wish to let matlab find the proper nargout alone (the uggly if block in subsref is just a stupid attempt to solve the problem).

exemple class code

classdef exemple_subsrf_oncell < handle     
properties
  some_cell= {}; 
end      
methods          
   function self= exemple_numel(cn)       
      self.some_cell= cn;
    end          
     function varargout= subsref(self,idx)
        if isequalwithequalnans(idx(end),substruct('{}',{':'}))
           varargout= cell(1,length(self.some_cell));
        else
           varargout= cell(1,1);
        end          
        [varargout{:}]= builtin('subsref',self,idx);    
        end
     end    
  end

Thank you very much for your attention

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Matt J 2012-12-28

2
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/57562-subsref-overload-has-fewer-outputs-than-expected-on-cell-attribute#answer_69667

编辑：Matt J 2013-1-4

Sadly, it's a known and old problem with subsref overloading. You cannot overload the syntax obj.prop{:}. Since the issue has been around for at least 7 years, my guess is it's buried too deep in the MATLAB source code to ever be fixed.

You can, of course, do things like this as a workaround,

    C=instance.some_cell;
    C{:}

Incidentally, it is a numel issue ( EDIT: or rather an issue in the way nargout interacts with numel). For user-defined classes, MATLAB's default numel for expressions obj.prop will always return 1. Overloading numel can't fix this, because dot-indexing expressions won't invoke the overloaded NUMEL method.

5 个评论
显示 3更早的评论隐藏 3更早的评论

Matt J 2013-1-2

编辑：Matt J 2013-1-2

numel(instance.colnames) % returns 3

That's because "instance.colnames" is not a user-defined object and also you are calling NUMEL from the command line. When you call NUMEL directly from the command line on a built-in class, it gets handled differently.

Here's a simplified example, that I think highlights the issue

    classdef myclass<handle
      methods
        function varargout = subsref(self,idx)
          varargout={10,20,30};
        end
        function N=numel(self,varargin)
         disp ' '
         disp 'Calling overloaded numel';
         N=3;
        end
      end
    end

And now some test cases below. Both indexing expressions should give the same results because the output of subsref is always varargout={10,20,30}, but you can see that the syntax instance.prop{:} behaves funny.

    >> clear classes; instance=myclass;
    >> instance{:} %Gives the correct number of outputs
    Calling overloaded numel
    ans =
        10
    ans =
        20
    ans =
        30
    >> instance.prop{:}  %WRONG
    ans =
        10

Since the overloaded NUMEL isn't even called in the second case (no message is displayed), there's nothing we can do to override the behavior.

Incidentally, to convince yourself that numel is indeed playing a role here, you could remove the overloaded numel from the classdef. Then observe that you get different behavior when you do

    >> instance{:}
    ans =
        10

Sean de Wolski 2013-1-4

@Nath, overload it for the class of your choice:

e.g. in an @cell folder, numel.m

Matt J 2013-1-4

编辑：Matt J 2013-1-4

@Nath

Isn't there a way to patch the BUILTIN numel ?

The only people who control the built-in NUMEL are TMW software engineers. As I said, if it were easy to fix, they would have done so 7 years ago. I'm actually no longer certain the bug is in NUMEL. I think it might be in NARGOUT. Specifically, NARGOUT will call NUMEL or it may not depending on the indexing syntax. It makes no difference, though. We don't have a way to overload NARGOUT either, as far as I can see.

@Sean,

Overloading NUMEL can't help because, as my example showed, there are situations when NUMEL overloads are ignored by NARGOUT.

请先登录，再进行评论。

Answer 2

Daniel Shub 2013-1-4

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/57562-subsref-overload-has-fewer-outputs-than-expected-on-cell-attribute#answer_70160

I am not following everything ... The two commands instance.some_cell and instance.some_cell{:} mean different things. See an old question of mine about cell array expansion. That said, I am not sure if you want them to return. It sounds like you want them to return the same thing. If that is the case, then add

if isequalwithequalnans(idx(end),substruct('{}',{':'}))
  varargout = {varargout};
end

to your subsref. It is not obvious to me how to overload subsref so it behaves like the built-in. For example, it seems overloading subsref to give the following behavior is difficult.

instance.some_cell = {1,2,3};
instance.some_cell{:}

2 个评论
显示无隐藏无

Nath 2013-3-8

As you said, they are different things and I dont want them returning the same value, as to for instance cell concatenation : {instance.some_cell,1} and {instance.some_cell{:},1} are definitely not the same

Nath 2013-3-8

The only (very heavy!) workaround I can think of would be to implement some cell-like class and have every cell attribute wrapped with this user cell class

请先登录，再进行评论。