Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
strange numel overload / varargin issue

Subject: strange numel overload / varargin issue

From: andywocky@gmail.com

Date: 24 Mar, 2009 23:13:44

Message: 1 of 2

Here's a tale of subsref/subsasgn/numel overloading (and varargin)
which has me puzzled. Comments and/or enlightenment on this
appreciated. Problem verified on Matlab 2008a, 2008b, 2009a.

I have a custom class, Foo, which must support {} and () indexing. I
overloaded subsref, subsasgn, and numel. The numel overload is
behaving strangely depending on how I access elements of Foo (e.g.,
comma-separated list type access, or not). Here is a snippet showing
the numel overload:

       classdef Foo < handle
            ...

            % Implicitly called by subsref, subsasgn to get nargout
            function n = numel(self, varargin)
                 % Case A: This works
                 nx = varargin{:};

                 % Case B: This doesn't work!?
                 % nx = varargin{1};

                 n = length(nx);
            end
       end

And here are some examples illustrating the behavior (with the nx
values Matlab assigns listed in comments for convenience):

>> F = Foo();
>> % nx (case A), nx (case B)
>> F{2:3:10} % [2 5 8], [3 2 10]
>> F{[2:3:10] % [2 5 8], [2 5 8]
>> F{[3, 2, 10]} % [3 2 10], [3 2 10]

As can be seen in command line test 1, the comma-separated list access
does *not* work for case B, even though one would expect varargin{1} =
varargin{:} in this case. It's almost as if Matlab secretly handles
varargin correctly for some special cases (e.g., varargin{:}).

Command line test 2 works as expected.

Command line test 3 illustrates that, when using numel with varargin
{1} to get indices, there are degnerate cases that can't be resolved.

Has anyone encountered this behavior before? Am I missing something
obvious, or is this a Matlab feature? :)

Thanks,
Andy

Subject: strange numel overload / varargin issue

From: James Tursa

Date: 25 Mar, 2009 00:30:22

Message: 2 of 2

andywocky@gmail.com wrote in message <17158a29-7bd9-4d7c-9ef5-b2cbc1535c24@d38g2000prn.googlegroups.com>...
> Here's a tale of subsref/subsasgn/numel overloading (and varargin)
> which has me puzzled. Comments and/or enlightenment on this
> appreciated. Problem verified on Matlab 2008a, 2008b, 2009a.
>
> I have a custom class, Foo, which must support {} and () indexing. I
> overloaded subsref, subsasgn, and numel. The numel overload is
> behaving strangely depending on how I access elements of Foo (e.g.,
> comma-separated list type access, or not). Here is a snippet showing
> the numel overload:
>
> classdef Foo < handle
> ...
>
> % Implicitly called by subsref, subsasgn to get nargout
> function n = numel(self, varargin)
> % Case A: This works
> nx = varargin{:};
>
> % Case B: This doesn't work!?
> % nx = varargin{1};
>
> n = length(nx);
> end
> end
>
> And here are some examples illustrating the behavior (with the nx
> values Matlab assigns listed in comments for convenience):
>
> >> F = Foo();
> >> % nx (case A), nx (case B)
> >> F{2:3:10} % [2 5 8], [3 2 10]
> >> F{[2:3:10] % [2 5 8], [2 5 8]
> >> F{[3, 2, 10]} % [3 2 10], [3 2 10]
>
> As can be seen in command line test 1, the comma-separated list access
> does *not* work for case B, even though one would expect varargin{1} =
> varargin{:} in this case. It's almost as if Matlab secretly handles
> varargin correctly for some special cases (e.g., varargin{:}).
>
> Command line test 2 works as expected.
>
> Command line test 3 illustrates that, when using numel with varargin
> {1} to get indices, there are degnerate cases that can't be resolved.
>
> Has anyone encountered this behavior before? Am I missing something
> obvious, or is this a Matlab feature? :)
>
> Thanks,
> Andy

I haven't look at your code in any detail, but I think you will have problems trying to overload numel. I had problems with a custom class involving this same issue sometime ago, and when I contacted The Mathworks about it the answer was basically as you suspect ... that behind the scenes numel is required to behave in a certain way and if you overload it to behave differently you will run into problems. There are warnings about this in the doc, so I would suggest you search the doc for this.

James Tursa

Tags for this Thread

No tags are associated with this thread.

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us