Prev: IR-Spectra
Next: www.voguesneakers.com Cheap Jordans,Cheap Nike Shox R4,Cheap Air Max 90
From: Matt J on 28 May 2010 10:58
"Eric Salemi" <eric.salemi(a)septentrio.com> wrote in message <htoesv$3pc$1(a)fred.mathworks.com>...
> > Have you overloaded subsref as well?
>
> I tried to overload subsref as well, I guess Matlab needs [obj.field(:)] to return something in order to compute the number of expected arguments for the subsequent subasgn call.
>
> The builtin version of subasgn does not accept array-reference operation on multiple output, so I have to implement it myself:
>
> -- subsref.m --
>
> function varargout = subsref(this,index)
>
> n = numel(this);
>
> if n > 1
> varargout = cell(1,n);
> for i = 1 : n
> varargout{i} = subsref(this(i),index);
> end
> else
> varargout = { builtin('subsref',this,index) };
> end
================

This could be part of the problem. When you call builtin('subsref',this,index) you are passing a non-builtin MATLAB object (i.e. "this") to a builtin function. Perhaps you should do struct(this) at the top of the file.

Other than that, I would still like to know what happens when you type [obj.field(:)] without trying to assign anything to it.
From: Eric Salemi on 28 May 2010 11:18
"Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message <htolme$i5g$1(a)fred.mathworks.com>...

> This could be part of the problem. When you call builtin('subsref',this,index) you are passing a non-builtin MATLAB object (i.e. "this") to a builtin function. Perhaps you should do struct(this) at the top of the file.

I actually think that within an overloaded subsref, any call to subsref will call the builtin version of subsref anyway. Otherwise we would end up in a infinite recursive loop. So I would assume that calling subsref from within a class method (i.e. on a non-builtin object) is a standard operation that is fully supported by Matlab. How else would you forward a deeply nested assignment on private member otherwise? Anyway, Matlab does not crash in the subsref call but before or after the subasgn call.

> Other than that, I would still like to know what happens when you type [obj.field(:)] without trying to assign anything to it.

See message 3 for that.

Eric.
From: James Tursa on 28 May 2010 12:16
"Eric Salemi" <eric.salemi(a)septentrio.com> wrote in message <htobje$6kq$1(a)fred.mathworks.com>...
>
> If I remove the subsasgn.m method, I get a normal error message. If I overload numel and force it to return 1 instead of 2, Matlab enters the overloaded subasgn.m. It seems that Matlab crashes after the call to numel.m but before it enters the overloaded subasgn.m.
>
> Anyone knows what could go wrong?

You generally can't overload numel to do whatever you want. There is a limitation built in to MATLAB OOP classes that has to have numel behave a certain way. See the doc on numel for more info.

James Tursa
From: Philip Borghesani on 28 May 2010 12:56
You are bumping into a limitation of the design of subsasgn. See http://www.mathworks.com/support/bugreports/194179

More recent versions of MATLAB produce an error for [obj.field(:)] = deal(true); instead of crashing but there is no simple
solution.

>> [pa.a(:)]=deal(1)
??? Scalar index required for this type of multi-level indexing.

Phil

"Eric Salemi" <eric.salemi(a)septentrio.com> wrote in message news:htobje$6kq$1(a)fred.mathworks.com...
> Hi,
>
> I'm using Matlab 7.0.1.246 (R14) to develop a large project. I notice a weird bevahior when using the OOP framework of Matlab and
> would like to have an opinion.
>
> I have a simplistic user-defined class on my path class MyClass. In the @MyClass folder, I placed the constructor MyClass.m and
> the overloaded subsasgn.m:
>
> -- MyClass.m --
>
> function this = constructor(varargin)
>
> this = class(struct,'MyClass');
>
> -- end of MyClass.m --
>
> -- subasgn.m --
>
> function this = subsasgn(this,index,varargin)
>
> keyboard
>
> -- end of subasgn.m --
>
> Then, on the matlab prompt I build a 1x2 MyClass object, and try to do an assignment:
>
> obj = [MyClass MyClass];
> [obj.field] = deal(true); % GO IN DEBUG MODE
> [obj.field(:)] = deal(true); % SEGMENTATION FAULT
>
> Matlab purely crash with a segmentation fault on the second assignment.
>
> If I remove the subsasgn.m method, I get a normal error message. If I overload numel and force it to return 1 instead of 2, Matlab
> enters the overloaded subasgn.m. It seems that Matlab crashes after the call to numel.m but before it enters the overloaded
> subasgn.m.
>
> Anyone knows what could go wrong?


From: Matt J on 28 May 2010 13:16
"Eric Salemi" <eric.salemi(a)septentrio.com> wrote in message <htoms0$3ad$1(a)fred.mathworks.com>...
> "Matt J " <mattjacREMOVE(a)THISieee.spam> wrote in message <htolme$i5g$1(a)fred.mathworks.com>...
>
> > This could be part of the problem. When you call builtin('subsref',this,index) you are passing a non-builtin MATLAB object (i.e. "this") to a builtin function. Perhaps you should do struct(this) at the top of the file.
>
> I actually think that within an overloaded subsref, any call to subsref will call the builtin version of subsref anyway.
=================

No, you have to specify that the builtin version should be called. For example, this line in your code

varargout{i} = subsref(this(i),index);

is resulting in recursive call to MyClass.subsref, which you can easily verify by having subsref print a message to the screen each time it is called. It is not an infinite recursion because the call is contained within an if...else, which terminates the recursion. Anyway, I did my own tests, and discovered that builtin subsref is indeed smart enough to strip "this" down to a struct.

============
> > Other than that, I would still like to know what happens when you type [obj.field(:)] without trying to assign anything to it.
>
> See message 3 for that.
===========

No, message 3 contains a call of the form [r1,r2]=obj.field(:) which is not the syntax I requested (no []'s around obj.field(:) ). Anyway, I went ahead and implemented your example in R2009b using a classdef file (see below). It appears that they fixed whatever issue is causing the segmentation fault in the new OOP framework, so you might consider upgrading your MATLAB version. Here are some examples to illustrate the behavior you should/could be getting for various indexing operations:

>> [r1,r2]=obj.field(:) %SAME AS R14

r1 =

1
2
3
4


r2 =

1
2
3
4

>> obj(1).field

ans =

1 2 3 4

>> obj(2).field %BUG IN SUBSREF

??? Error using ==> subsref
Index exceeds matrix dimensions.

Error in ==> myClass>myClass.subsref at 24
varargout = { builtin('subsref',this,index) };

Error in ==> myClass>myClass.subsref at 21
varargout{i} = subsref(this(i),index);


>> [obj.field] %CORRECT LIST EXPANSION

ans =

1 2 3 4 1 2 3 4

>> [obj(:).field] %CLASSIC LIST EXPANSION PROBLEM - THINKS NUMEL=1

ans =

1 2 3 4

>> [obj.field]=deal(true); %SUCCEEDS IN CALLING SUBSASGN, BUT WRONG NARGOUT

Subsasgn executed with NARGOUT = 1


>> [obj(:).field]=deal(true); %SAME AS ABOVE

Subsasgn executed with NARGOUT = 1

>> [obj.field(:)]=deal(true); %NO SEGMENTATION FAULT

??? Scalar index required for this type of multi-level indexing.




%%%%%%%%%%%%%%%
classdef myClass

properties
field
end

methods

function this = myClass(varargin)

this.field = 1:4;
end

function varargout = subsref(this,index)

n = numel(this);

if n > 1
varargout = cell(1,n);
for i = 1 : n
varargout{i} = subsref(this(i),index);
end
else
varargout = { builtin('subsref',this,index) };
end


end

function this = subsasgn(this,index,varargin)

disp(['Subsasgn executed with NARGOUT = ' num2str(nargout)])

end

end



end
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: IR-Spectra
Next: www.voguesneakers.com Cheap Jordans,Cheap Nike Shox R4,Cheap Air Max 90