Variable Based Indexing code on File Exchange - any takers?
Nabeel
* I've uploaded a "varbase" object to the MATLAB Central File Exchange
(collaboration welcome; contact me for details)
http://www.mathworks.com/matlabcentral/fileexchange/Files.jsp?fileId=1168
This object allows you to create object with the base index of your
choice. This uses a "data based" model, where array offsets are carried
with the data. The problem, as many have cited when discussing OOP, is
that you'd need to overload all of MATLAB's functions to work with this
function. To handle this in a cheap way, I wrote a function called
"makemethods" that autogenerates methods for this (or any other object)
to allow for what I call a "natural conversion". By natural conversion,
I mean that overloaded methods just resort to some default behavior, in
this case they behave as if they were operating on MATLAB's default
one-based doubles. For example:
>> p = varbase(rand(1,3),0)
p: varbase = 0
0.4565 0.0185 0.8214
>> p(0)
ans: varbase = 0
0.4565
>> plot(p)
The indexing p(0) obviously uses a special method, but the overload
@varbase/plot method just extracts the one-based data and passes it to
the default double plot. That's the "natural conversion".
(Incidentally, one enhancement we're considering for the MATLAB Language
is to provide a "default converter", so that for any undefined methods
for your object, MATLAB would automatically apply some conversion to
your object and then try again. But right now, this spec is relatively
immature and needs work.)
* How good is this?
This is certainly not a professional grade production. It's a "bare
bones" system, lacking what many will consider critical features but it
may be enough for others. It all depends on your needs. Unless
functions are overloaded "intelligently" instead of via my automatic
"makemethods" function, you end up with FIND, plotting functions, and
many other functions producing results/graphs that are unaware of the
base of your array. Does code work/run? Yes. Is it of the quality I'd
like to see in MATLAB? No. Given the amount of work a proper
implementation of this would take, do I feel that it's worthwhile to
take this further, or are my/our efforts better spent elsewhere? I'm
not sure; you need to let me know. In fact, you can help out if you
want to contribute code to this.
* Show me:
So, with about 9 overloaded methods and a few handy functions like
"makemethods", here's a sample session:
>> setup % to setup overloaded functions, only need to do once
% 'edit setup' to see what's inside the file and how to setup your own
code.
Overloaded 685 classes in 6.749 seconds.
>> str = varbase('Hi there, Nabeel.',-8)
str: varbase = -8
Hi there, Nabeel.
>> str(-8:8)
ans: varbase = -8
Hi there, Nabeel.
>> M0 = varbase(magic(4),0)
M0: varbase = 0
16 2 3 13
5 11 10 8
9 7 6 12
4 14 15 1
>> M0(0,:)
ans: varbase = 0
16 2 3 13
>> M1 = magic(4);
>> M0*M1
ans: varbase = 0
345 257 281 273
257 313 305 281
281 305 313 257
273 281 257 345
>> Mm1 = setbase(M0,-1);
>> getbase(Mm1)
ans =
-1
>> Mm1(-1,:)
ans: varbase = -1
16 2 3 13
>> surf(M0./Mm1); % works via "natural conversion" but axes limits are wrong
>> c = varbase(cell(3,3),-1)
c: varbase = -1
[] [] []
[] [] []
[] [] []
>> c(-1,:) = num2cell(1:3)
c: varbase = -1
[1] [2] [3]
[] [] []
[] [] []
>> c(:,1)
ans: varbase = -1
[3]
[]
[]
If this is something you like, or if you have interesting comments, let
me know. And if you overload some functions on your own in an
intelligent fashion, send them to me and I'll include them in the
package, as well as give you credit.
There are several limitations of this implementation. If you're
familiar with MATLAB OOP, you can probably figure out a lot of them.
Some of them are mentioned in the readme.txt file I've included, but
most probably aren't.
If you happen to e-mail me directly, please put the words "Varbase
object" in the subject so that I can catch this. I'll try to write back
if appropriate, but at the very least if you use this subject I can
filter for these messages.
-- Nabeel
"I think, therefore I .m"
robert bristow-johnson
okay Nabeel,
this looks like a beginning. (but just a beginning.)
thank you, Nabeel.
i am using MATLAB v 5.2.1, the last build for the Mac (we're not OSX here,
yet, but i sure as hell hope you folks build a MATLAB version for OSX
instead of writing the Mac off as it appears TMW has done in 1999). anyway,
because if work and upcoming holiday pressures, i won't be able to try it
out until after the new year.
3 things that i would like to mention:
1. instead of storing the (variable) base with the object, i really think
you should store the offsets which are 1-base for each dimension with the
object. setbase() and getbase() would make the conversion. this would
speed things up a little in subsref() and subsasgn() and make life simpler.
BTW, i like the name "rebase()" better than "setbase()" because it is
similar to "reshape()" and should, IMHO, have an identical calling
convention as reshape(). also, i like the name "base()" better than
"setbase()" because it is more similar to the "size()" function (except that
it returns the base instead of the size) and it should have an identical
calling convention as size().
2. the constructor should really be in rebase() (or what you are calling
"setbase()"). i.e. the only time a user will be creating a varbase type
object is when he takes a regular MATLAB "double" object and rebases it.
3. we need to be able to treat a "varbase" object that happens to have
(1, 1, ...) as its base exactly as a regular MATLAB "double" object. we
should be able to mix the two, or if a "varbase" object gets rebased to
(1, 1, ...), perhaps rebase() (or "setbase" or whatever) should return a
regular old MATLAB "double" object.
lastly, many basic MATLAB utilities will need to be slightly rewritten for
overloading, but they are finite in number. it will mostly be checking the
classes of the arguments with isa(). if it's a normal MATLAB "double"
class, we call the parent method being overloaded. if it's a "varbase", we
pass the varbase.data to the parent method and return the result as
varbase.data with appropriate settings for the base (usually the same
settings as the input argument).
a few MATLAB utilities for the basic operations will need a little more
thought because, just like the matrix shapes have to be correct for +, -, *,
/, etc.., now the bases will have to be checked for correctness. i'll be
happy to work out and propose those rules (and to field comments from both
USENET communities).
THIS IS DOABLE AND, CLEVE, WE'RE GONNA PROVE TO YOU HOW DOABLE AND USEFUL
(elegant) IT WILL BE! furthermore, it is still soooo fundamental, that is
should be intrinsic to the root MATLAB variable. in 10 years, you'll wonder
why you didn't put it in MATLAB in the first place (or at least before the
Sig Proc Toolbox came out when it should have been obvious, and *was* to
Thomas Krauss, that this extension to the MATLAB variable was needed).
In article <3C1ED270...@mathworks.com> , Nabeel <nab...@mathworks.com>
wrote:
robert bristow-johnson
bristow-johnson" <rob...@wavemechanics.com> wrote:
>
> okay Nabeel,
>
> this looks like a beginning. (but just a beginning.)
>
> thank you, Nabeel.
>
> i am using MATLAB v 5.2.1, the last build for the Mac (we're not OSX here,
> yet, but i sure as hell hope you folks build a MATLAB version for OSX
> instead of writing the Mac off as it appears TMW has done in 1999). anyway,
> because if work and upcoming holiday pressures, i won't be able to try it
> out until after the new year.
>
> 3 things that i would like to mention:
>
> 1. instead of storing the (variable) base with the object, i really think
> you should store the offsets which are 1-base for each dimension with the
> object. setbase() and getbase() would make the conversion. this would
> speed things up a little in subsref() and subsasgn() and make life simpler.
>
> BTW, i like the name "rebase()" better than "setbase()" because it is
> similar to "reshape()" and should, IMHO, have an identical calling
> convention as reshape(). also, i like the name "base()" better than
> "setbase()" because it is more similar to the "size()" function (except that
> it returns the base instead of the size) and it should have an identical
> calling convention as size().
i meant to say "i like the name 'base()' better than 'getbase()' because it
is more similar to the 'size()' function". this is one reason i've never
liked the "get_attribute()" vs. "set_attribute()" naming convention.
they're too similar. "get_attribute()" should just be named "attribute()"
and it returns whatever the attribute is. e.g. "y = time()" is preferable
to "y = get_time()". it reads better.
r b-j
Steven Lord
"robert bristow-johnson" <rob...@wavemechanics.com> wrote in message
news:epNT7.6301$BK....@nwrddc02.gnilink.net...
>
> okay Nabeel,
>
> this looks like a beginning. (but just a beginning.)
>
> thank you, Nabeel.
>
> i am using MATLAB v 5.2.1, the last build for the Mac (we're not OSX here,
> yet, but i sure as hell hope you folks build a MATLAB version for OSX
> instead of writing the Mac off as it appears TMW has done in 1999).
anyway,
> because if work and upcoming holiday pressures, i won't be able to try it
> out until after the new year.
>
> 3 things that i would like to mention:
>
> 1. instead of storing the (variable) base with the object, i really think
> you should store the offsets which are 1-base for each dimension with the
> object. setbase() and getbase() would make the conversion. this would
> speed things up a little in subsref() and subsasgn() and make life
simpler.
Go for it. Nabeel basically said "Tweak it as you will." when he put the
files on the File Exchange (at least that's the impression I received from
his message.)
> BTW, i like the name "rebase()" better than "setbase()" because it is
> similar to "reshape()" and should, IMHO, have an identical calling
> convention as reshape(). also, i like the name "base()" better than
> "setbase()" because it is more similar to the "size()" function (except
that
> it returns the base instead of the size) and it should have an identical
> calling convention as size().
>
> 2. the constructor should really be in rebase() (or what you are calling
> "setbase()"). i.e. the only time a user will be creating a varbase type
> object is when he takes a regular MATLAB "double" object and rebases it.
No. The constructor for a MATLAB object _must_ have the same name as the
directory in which it is located (except the directory will have an @ symbol
in front) and that common name will be the type of the object.
> 3. we need to be able to treat a "varbase" object that happens to have
> (1, 1, ...) as its base exactly as a regular MATLAB "double" object. we
> should be able to mix the two, or if a "varbase" object gets rebased to
> (1, 1, ...), perhaps rebase() (or "setbase" or whatever) should return a
> regular old MATLAB "double" object.
>
> lastly, many basic MATLAB utilities will need to be slightly rewritten for
> overloading, but they are finite in number. it will mostly be checking
the
> classes of the arguments with isa(). if it's a normal MATLAB "double"
> class, we call the parent method being overloaded. if it's a "varbase",
we
> pass the varbase.data to the parent method and return the result as
> varbase.data with appropriate settings for the base (usually the same
> settings as the input argument).
If I am correct, I think you misunderstand slightly how MATLAB OOPS works.
If MATLAB is told to execute a function with a double as the input argument,
it will use the standard operator/function on that argument. If MATLAB is
told to execute a function with an object of a class as the input, it will
look for the class directory and see if that function is overloaded for the
class; if it is, it will use the overloaded version of the function. If it
is not, it will use the standard version. So, even if (for example) MINUS
is overloaded for these new 'varbase' objects, if you type A-B where A and B
are double arrays, MATLAB will automatically use the built-in function. If
either of the two objects is a 'varbase' object, however, MATLAB will use
the varbase MINUS function (and so it should contain calls to make sure the
inputs are 'varbase' objects.)
> a few MATLAB utilities for the basic operations will need a little more
> thought because, just like the matrix shapes have to be correct for +, -,
*,
> /, etc.., now the bases will have to be checked for correctness. i'll be
> happy to work out and propose those rules (and to field comments from both
> USENET communities).
>
> THIS IS DOABLE AND, CLEVE, WE'RE GONNA PROVE TO YOU HOW DOABLE AND USEFUL
> (elegant) IT WILL BE!
With MATLAB OOPS, yes. If you wanted the source code of MATLAB to be
changed everywhere arrays were referenced to allow variable-based indexing
... _technically_ it's possible. However, in that case I think the next
version of MATLAB (upgraded and _fully tested to make sure nothing has been
broken_) would come out sometime early in 2007. [The job is much more
complicated and involved than you might think.] You may think I'm
exaggerating, and perhaps I am ... okay, late 2006 then. That's just my
guess.
--
Steve Lord
sl...@mathworks.com
Eric Jacobsen
Thanks much for this. It is definitely encouraging to get something
from somebody within the Mathworks that looks like progress toward a
solution.
I don't personally have any experience with the OOP features in
Matlab, so I guess I either have to punt and use other tools, or take
yet another leap of faith with Matlab and hope that this turns into a
solution. Given my personal experience with the history of this
problem, I am sorely tempted to punt. The fact that I do like so many
of Matlabs features may keep me from doing so. So I am, for the
moment, torn. The arrival of the holidays makes me, for the moment,
barely care. ;)
I will pass this on to some colleagues who may be more familiar with
Matlab's OOP features, and who are all too well aware of the one-based
indexing problem. Perhaps they'll have a more insightful opinion than
I'm able to offer.
In any case, thanks much again for the effort in the direction of a
solution,
Eric
On Tue, 18 Dec 2001 00:21:52 -0500, Nabeel <nab...@mathworks.com>
wrote:
Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://home.earthlink.net/~ejacobsensprint
robert bristow-johnson
(Eric Jacobsen) wrote:
> Nabeel,
>
> Thanks much for this. It is definitely encouraging to get something
> from somebody within the Mathworks that looks like progress toward a
> solution.
>
> I don't personally have any experience with the OOP features in
> Matlab, so I guess I either have to punt and use other tools, or take
> yet another leap of faith with Matlab and hope that this turns into a
> solution.
Eric,
i too have no previous experience with MATLAB OOP but, it appears that the
means to do this is there. but in order to make it as seamless as possible,
i think that what Nabeel has written will have to be changed a little bit.
i think, from reading Steve Lord's, input, that this class will have to be
renamed "rebase" since, to be seamless, the constructor will have to be the
same as the rebasing operator that changes a regular old MATLAB "double" to
this variable base thingie and i think the name for that should be
"rebase()". and rebase() should be able to take a "rebase" type and change
it's base AND be smart enough to return a regular old MATLAB "double" if a
"rebase" type happens to have its base changed to (1,1).
first the main operators (+, -, .*, ./, *, /, \, [(cat)]) will have to be
fixed and include the possibility of mixing "rebase" types with "doubles".
then the elementary functions (that should be straight forward), then a few
utilities like plot(). then we have something to start with and i would
immediately make the DFT() and FT() and convolve() operators. at that point
the elegance and utility of this should be demonstratible.
r b-j
robert bristow-johnson
bristow-johnson" <rob...@wavemechanics.com> wrote:
> In article <3c1ffade....@news.earthlink.net> , eric.j...@ieee.org
> (Eric Jacobsen) wrote:
>
>> Nabeel,
>>
>> Thanks much for this. It is definitely encouraging to get something
>> from somebody within the Mathworks that looks like progress toward a
>> solution.
>>
>> I don't personally have any experience with the OOP features in
>> Matlab, so I guess I either have to punt and use other tools, or take
>> yet another leap of faith with Matlab and hope that this turns into a
>> solution.
>
> Eric,
>
> i too have no previous experience with MATLAB OOP but, it appears that the
> means to do this is there. but in order to make it as seamless as possible,
> i think that what Nabeel has written will have to be changed a little bit.
> i think, from reading Steve Lord's, input, that this class will have to be
> renamed "rebase" since, to be seamless, the constructor will have to be the
> same as the rebasing operator that changes a regular old MATLAB "double" to
> this variable base thingie and i think the name for that should be
> "rebase()". and rebase() should be able to take a "rebase" type and change
> it's base AND be smart enough to return a regular old MATLAB "double" if a
> "rebase" type happens to have its base changed to (1,1).
here is my second stab at this. Nabeel, i really want this thing to look
like and work like an extension to the regular MATLAB variable of class
'double'. both for elegance and conciseness of syntax and usage and also, i
must admit, to prove my point to Cleve. therefore, i want the constructor,
called 'rebase()' to look and work like the existing MATLAB 'reshape()'
facility.
would you MATLAP OOP gurus like to examine the following two facilities and
tell me if it looks right? (some word unwrapping of long lines is
necessary.) anyway, Nabeel, if this looks okay to you, can we build off of
this paradigm, instead?
function X = rebase(varargin)
% REBASE Create a 'rebase' object, a MATLAB array with arbitrary bases.
%
% A 'rebase' object is just like a regular MATLAB variable of class
% 'double' except that the indices of each dimension need not always begin
% with 1 as is the case with the regular MATLAB variable. A 'rebase'
% object can be thought of as a generalization of a MATLAB array in which
% indices can have any reasonable finite range of integers, even negative
% integers.
%
% REBASE(X, [b1 b2 b3 ...]) or REBASE(X, b1, b2, b3, ...) creates an
% object containing the array X with the leading element of each
% dimiension defined to be b1, b2, b3, ... . The syntax and use of REBASE
% should be much like that of the MATLAB function RESHAPE.
%
% The array X, can either be a regular MATLAB variable of class 'double'
% that is treated just like a "rebase" object with base = [1 1 1 ...] or
% it can be another 'rebase' array.
%
% REBASE returns an object of class 'rebase' unless the base turns out to
% be exactly the same as the implied base of a MATLAB variable (which is
% [1 1 1 ...]) and, in that case, REBASE returns a regular MATLAB variable
% of class 'double'.
%
if isa (varargin{1}, 'double')
x.array = varargin{1};
x.offset = zeros(1, ndims(varargin{1}));
elseif isa (varargin{1}, 'rebase')
x = varargin{1};
x.offset = zeros(1, ndims(varargin{1}.array));
else
disp('rebase: input argument of unknown class.');
return;
end
if length(varargin) == 2
if size(varargin{2}) == size(x.offset)
x.offset = 1 - varargin{2};
else
disp('rebase: size of base vector inconsistent with array
dimensions.');
return;
end
elseif (length(varargin)-1) == length(x.offset)
for i = 1:length(offset)
if length(varargin{i+1}) == 1
x.offset(i) = 1 - varargin{i+1}; % base = 1 - offset and
offset = 1 - base
else
disp('rebase: input base must either be a vector or series of
scalers');
return;
end
end
else
disp('rebase: number of base indices inconsistent with array
dimensions.');
return;
end
x.offset = round(x.offset); % offsets or bases must be
integers
if x.offset == zeros(size(offset))
X = x.array; % return a standard MATLAB
"double" class if base = (1,1)
else
X = x;
X = class(X, 'rebase'); % return a "rebase" class if
base not = (1,1)
end
function b = base(X)
% BASE Return the base of X of a 'rebase' object in a row vector.
%
% If X is a regular MATLAB variable of class 'double', then the base
% returned is just [1 1 1 ...] . The syntax and use of BASE should be
% much like that of the MATLAB function SIZE.
%
if nargin == 1
if isa (X, 'rebase')
b = 1 - X.offset; % base = 1 - offset and
offset = 1 - base
elseif isa (X, 'double')
b = 1 - zeros(1, ndims(X));
else
disp('base: input argument of unknown class.');
end
else
disp('base: number of arguments must be one.');
end
Nabeel
A few things here.
Eric wrote:
> Thanks much for this. It is definitely encouraging to get something
> from somebody within the Mathworks that looks like progress toward a
> solution.
Thanks; I hope you find this code useful and can get some good ideas
from it. However I don't want to mislead anyone here - this code is
just one of my personal hacks. This code isn't supported by The
MathWorks and isn't meant as an indication of our thoughts/plans on
this. It's just something that I posted because I thought it might give
you some idea of how you could implement your own class for creating
data with arbitrary starting indices. And as long as you're aware of
its limitations, you could probably make some good use from it.
Getting to some of Robert's points:
> anyway, Nabeel, if this looks okay to you, can we build off of
> this paradigm, instead?
Well, I like some of the items you pointed out, but there are others
that I don't like and some that I'm opposed to. For the package that
I've uploaded, I probably wouldn't be interested in making many of the
changes you suggested. But some of the others seem pretty interesting.
Feel free to take this in whatever direction you'd like. I'll probably
use some of the ideas you've mentioned, but not all. And naturally,
you're free to use whatever parts of my code that you'd like.
I don't know how much time I'll have to put into the "Varbase" project
that I've uploaded. A lot of it might depend on the interest level it
gets, and right now it isn't looking so popular (take a look at the
download counts on the File Exchange). But as I make changes to it,
I'll certainly upload them to the site. If you've subscribed to the
file, you'll receive e-mail messages when I make changes, so this will
help you stay up-to-date on what I've done (this is one of the really
nice features of the File Exchange). For now, I've updated the object
to allow different bases for each dimension, and made a few other
changes.
Incidentally, you'll certainly want to brush up on MATLAB OOP or, as
Eric suggested, pass this off to someone who's already familiar with
it. It will make customizing this object to suite your preferences much
easier.
While I don't want to debate implementation issues that are a matter of
personal taste, I thought it'd be worthwile to point out a few items
that you should consider, regardless of your preferences:
> 3. we need to be able to treat a "varbase" object that happens to have
> (1, 1, ...) as its base exactly as a regular MATLAB "double" object. we
> should be able to mix the two, or if a "varbase" object gets rebased to
> (1, 1, ...), perhaps rebase() (or "setbase" or whatever) should return a
> regular old MATLAB "double" object.
Why do you need this? The reason I'm pointing out this particular
difference is that when returning a double in response to
varbase(data,[1,1,1,...]), you lose the the ability to assume you have
an object after calling a constructor - this is a standard assumption to
make in programming and can have an adverse affect on your code.
Consider this snippet
% b is an input to your code
x = varbase(a,b);
[...]
baseUsed = base(x);
The getbase call assumes you have an object. But under your spec, this
might not always be true, despite having called the constructor. So
you'd end up having to check for this special case, which ruins the
elegance of your code. This also can have a negative effect on any
optimizations that you or your programming language might make that are
based on having an object. And your code would involve lots of ISA or
CLASS calls that interrupt the flow.
A good programming practice is to always return the appropriate object
when you call a constructor. This practice is consistent with other
MATLAB behavior, and is also consistent with behavior you see in other
languages. So regardless of what your other preferences are, I'd
suggest not implementing this. But it's really up to you.
Besides, because of the way my object overloading is autogenerated in
the "setup" script, you can already use a varbase object as if it were a
MATLAB double. That's the default behavior defined in "setup".
> disp('rebase: input base must either be a vector or series of scalers');
> return;
Aside from the typo ("scalars"), you're probably better off using the
ERROR function instead:
error("rebase: input base must either be a vector or series of
scalars")
This will automatically stop your code from running, so no RETURN call
is needed. There's also a WARNING command which produces similar
messages but doesn't halt your program.
> i meant to say "i like the name 'base()' better than 'getbase()' because it
> is more similar to the 'size()' function". this is one reason i've never
> liked the "get_attribute()" vs. "set_attribute()" naming convention.
> they're too similar. "get_attribute()" should just be named "attribute()"
> and it returns whatever the attribute is. e.g. "y = time()" is preferable
> to "y = get_time()". it reads better.
That works well. Another option, which may be seen as more consistent
with the rest of the MATLAB language, is to overload GET and SET, and
specify parameter/value pairs. I'd also consider overloading the .
operator to allow one to access the field (which by default is private
in MATLAB). If you do a which -all get, you'll see that we've done this
for many of our objects.
> thought because, just like the matrix shapes have to be correct for +, -, *,
> /, etc.., now the bases will have to be checked for correctness.
I'm personally more interested in the sizes being correct for these
operations rather than the bases, but I'd say that's a matter of
personal preference. I found myself wanting to do simple things like
scaling or adding a constant to my data - having to construct an object
just for that reason is a bit tedious. ie, things like:
diag([1 2 3])*p % scale the rows of p by 1, 2, and 3
would become:
varbase(diag([1 2 3]),base(p))*p
But again, it all depends on what you'd want to do with the object.
I haven't defined an overloaded CAT operator, I'm not sure how I'd like
that to work. I'm leaning towards having it care about the base, and
erroring if the bases don't match.
I hope this package is useful to you, either in its current form or in
some derivative of it. Working with your own M implementation of this
allows you to make whatever choices you want, at whatever pace you want
to see them happen. Ultimately, this should allow you to have the
flexability that you're looking for, without having to compromise on the
features you want to see.
-- Nabeel
Bob Cain
Nabeel wrote:
>
> Incidentally, you'll certainly want to brush up on MATLAB OOP
Nabeel, which of your documents provides the best coverage?
Thanks,
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
To contribute your unused processor cycles to the fight against cancer:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////
Duane Hanselman
> Nabeel wrote:
> >
> > Incidentally, you'll certainly want to brush up on MATLAB OOP
>
> Nabeel, which of your documents provides the best coverage?
>
>
Chapter 33 of the text "Mastering MATLAB 6," contains 31 pages of an
intro in MATLAB OOP. All the basics are covered as well as use of the
less transparent subsref and subsasgn.
Duane Hanselman
www.eece.maine.edu/mm
Steven Lord
"Duane Hanselman" <dua...@eece.maine.edu> wrote in message
news:dea6a327.01122...@posting.google.com...
As an additional reference, the Using MATLAB manual (available here:
http://www.mathworks.com/access/helpdesk/help/techdoc/matlab.shtml) has a
full chapter on MATLAB OOPS, including several examples. Alternately,
Robert, if you're really interested I'll put a little stack class I wrote on
MATLAB Central as a small example. Finally, you can of course look at some
of the classes defined in some of the toolboxes for more complicated
examples (such as the @sym class of the Symbolic Toolbox.)
--
Steve Lord
sl...@mathworks.com
robert bristow-johnson
boy! you burn the midnight oil, don't you Nabeel?
In article <3C2170A5...@mathworks.com> , Nabeel <nab...@mathworks.com>
wrote:
>
> Getting to some of Robert's points:
>
>> 3. we need to be able to treat a "varbase" object that happens to have
>> (1, 1, ...) as its base exactly as a regular MATLAB "double" object. we
>> should be able to mix the two, or if a "varbase" object gets rebased to
>> (1, 1, ...), perhaps rebase() (or "setbase" or whatever) should return a
>> regular old MATLAB "double" object.
>
> Why do you need this?
the fundamental reason is that if, after some operation i happen to end up
with an array that has base of (1, 1,...), then i want to be able to do
*anything* with that array that i used to be able to do in MATLAB. some
MATLAB operations will understandably _make_no_sense_ for arrays that are
not 1-based. for those myriad operations, there is no good reason to write
code that overloads them. but they won't work with a "varbase" object (or
as i would prefer to call it, a "rebase" object), even one with base = (1,
1, ...) without overloading them to the point that they extract the MATLAB
array out of the object and send that to the previous operator. the best
way that i can think of is that ALL of the overloaded operators that work on
"rebase" objects, the last thing they will do is check the base of the
resulting array, and if the base is (1, 1, ...), rather than return a
"rebase" object, a regular MATLAB 1-based matrix variable is returned.
> The reason I'm pointing out this particular
> difference is that when returning a double in response to
> varbase(data,[1,1,1,...]), you lose the the ability to assume you have
> an object after calling a constructor
i don't lose the "ability", i just lose that base attribute. but if all of
the overloaded operators can take a "double" as an argument (along with,
presumedly some "rebase" arguments) and then treat it *exactly* as a rebase
object with base = (1, 1,...), then i haven't lost anything. that is, if
there *is* no base attribute, it is always assumed to be (1, 1,...).
again, my fundamental position is that this base stuff is soooo fundamental
and basic to what MATLAB should be that it should be part of the low-level
definition of a MATLAB "double" thingie (whether you call a variable of
class "double" an "object" or not is a semantic issue AFAIC). now lacking
that (and it appears that even though you and Cleve and company have
produced NO compelling argument that this fix won't be done), i want the OOP
for this class to be designed in such a way that the syntax OF THE USER
would be identical to what it would be if you and Cleve and company *did* do
the right thing and fix this at the lowest level.
that is (here is my doctrine about it): *all* MATLAB numeric array
variables should have an index base attribute attached to it (that defaults
to 1,1). the simplest and best way is if they all simply have that base (or
offset) vector attached to each MATLAB "double" variable, but lacking that,
there will be this additional class with that base (or offset) vector and
such an object that happens to have base (1, 1) (or offset = (0, 0)), then
that array must be treated just like a regular MATLAB variable of *implicit*
base of (1, 1). is that clear?
> - this is a standard assumption to
> make in programming and can have an adverse affect on your code.
> Consider this snippet
>
> % b is an input to your code
> x = varbase(a,b);
> [...]
> baseUsed = base(x);
>
> The getbase call assumes you have an object.
isn't a regular old MATLAB matrix variable essentially an object of class
"double"? my "base()" function does not assume that. it can handle either
the "rebase" class or the "double" class.
> But under your spec, this
> might not always be true, despite having called the constructor. So
> you'd end up having to check for this special case, which ruins the
> elegance of your code.
this is one reason that i am *still* convinced that MathWorks should change
this at the fundamental level, at the basic definition of a MATLAB variable
of which i have learned recently is called "double". now you're right that
the code that implements this class is less elegant (and the fault lies with
TMW's refusal to make this base an intrinsic component of the MATLAB
variable structure) but the intention is so that the *user* code is *more*
elegant. if a user gets back a "rebase" object that happens to have base
equal to (1,1), he should be able to use that like a regular MATLAB array
variable. how is he/she supposed to be able to do that?
> This also can have a negative effect on any
> optimizations that you or your programming language might make that are
> based on having an object. And your code would involve lots of ISA or
> CLASS calls that interrupt the flow.
AGREED!!!!!!! THAT IS WHY MATHWORKS SHOULD FIX THIS UGLY FLAW AT THE ROOT!
(rather than some of us creating this kludgy work around.) the fact that
TMW cannot see this deficiency for what it is, does not speak highly for a
product and group of people that, otherwise, have so much technical
sophistication.
> A good programming practice is to always return the appropriate object
> when you call a constructor. This practice is consistent with other
> MATLAB behavior, and is also consistent with behavior you see in other
> languages. So regardless of what your other preferences are, I'd
> suggest not implementing this. But it's really up to you.
>
> Besides, because of the way my object overloading is autogenerated in
> the "setup" script, you can already use a varbase object as if it were a
> MATLAB double. That's the default behavior defined in "setup".
>
>> disp('rebase: input base must either be a vector or series of
scalers');
>> return;
>
> Aside from the typo ("scalars"), you're probably better off using the
> ERROR function instead:
>
> error("rebase: input base must either be a vector or series of
> scalars")
fine. remember i'm a DSP person that wants to use MATLAB as a tool. i am
not, nor have ever purported to be, a skilled MATLAB programmer. and to
tell the truth, i don't really want to be, but this fix is so fundamental
and salient, that i'll try to learn what i have to to make it happen.
>
>> thought because, just like the matrix shapes have to be correct for +, -, *,
>> /, etc.., now the bases will have to be checked for correctness.
>
> I'm personally more interested in the sizes being correct for these
> operations rather than the bases, but I'd say that's a matter of
> personal preference.
no it isn't, Nabeel. now i'm wondering if you "get it". just like you
cannot add two vectors that are different lengths (because it generates too
many inelegant questions, like what to do with the dangling tail of the
longer vector), you cannot add two arrays of different bases for the same
kinds of reasons.
> I found myself wanting to do simple things like
> scaling or adding a constant to my data - having to construct an object
> just for that reason is a bit tedious. ie, things like:
>
> diag([1 2 3])*p % scale the rows of p by 1, 2, and 3
>
> would become:
>
> varbase(diag([1 2 3]),base(p))*p
of course! because what come out or diag() is a regular old 1-based array
or matrix. to scale the rows of p, which is presumed to be a non-1-based
array, the rules that i posted in the start of the "foundation" thread need
to be followed for the extended, backward compatible version of matrix
multiplication.
> But again, it all depends on what you'd want to do with the object.
>
> I haven't defined an overloaded CAT operator, I'm not sure how I'd like
> that to work. I'm leaning towards having it care about the base, and
> erroring if the bases don't match.
the way it should work, IMO, is that the indices of the upper left corner of
the result should be the same as the indices of the upper left corner of the
concatinated array that goes in the upper left corner. all other indices of
input arrays should be ignored and the index of the resultant array just
picks up with the concatinated array where it left off from the previous
input array.
i.e. X = [A B; C D]; should work just like it does now in MATLAB, except
that the base of A is copied to the base of X.
> I hope this package is useful to you, either in its current form or in
> some derivative of it.
if we can make it elegant to the user, i have no doubt that it will,
_in_time_, become useful to a large number of people and in a decade or
before, Cleve will see the error in not making this part of the basic MATLAB
variable definition. if we can make this to work as i have been envisioning
it, and trying to communicate that vision, i have no doubt of that at all.
it's not that complicated, conceptually, and i still find it incredible that
the vision at TMW has been for years, so limited that this had not been
implemented before the Sig. Proc. Toolbox even came out. especially since
Tom Krauss brought it up at that time. it's amazingly myopic (and
unfortunate).
> Working with your own M implementation of this
> allows you to make whatever choices you want, at whatever pace you want
> to see them happen. Ultimately, this should allow you to have the
> flexability that you're looking for, without having to compromise on the
> features you want to see.
that's what we all want.
--
r b-j
Wave Mechanics, Inc.
45 Kilburn St.
Burlington VT 05401-4750
tel: 802/951-9700 ext. 207 http://www.wavemechanics.com/
fax: 802/951-9799 rob...@wavemechanics.com
--
Eric Jacobsen
<rob...@wavemechanics.com> wrote:
>again, my fundamental position is that this base stuff is soooo fundamental
>and basic to what MATLAB should be that it should be part of the low-level
>definition of a MATLAB "double" thingie (whether you call a variable of
>class "double" an "object" or not is a semantic issue AFAIC). now lacking
>that (and it appears that even though you and Cleve and company have
>produced NO compelling argument that this fix won't be done), i want the OOP
>for this class to be designed in such a way that the syntax OF THE USER
>would be identical to what it would be if you and Cleve and company *did* do
>the right thing and fix this at the lowest level.
>
>that is (here is my doctrine about it): *all* MATLAB numeric array
>variables should have an index base attribute attached to it (that defaults
>to 1,1). the simplest and best way is if they all simply have that base (or
>offset) vector attached to each MATLAB "double" variable, but lacking that,
>there will be this additional class with that base (or offset) vector and
>such an object that happens to have base (1, 1) (or offset = (0, 0)), then
>that array must be treated just like a regular MATLAB variable of *implicit*
>base of (1, 1). is that clear?
FWIW, I agree with Bob's position here. While I fully appreciate
Nabeel's effort and it's utility, it is essentially a patch to try to
work around a fundamental shortcoming in the tool. Given no relief
from the fundamental problem, sadly, Nabeel's workaround is highly
appreciated.
...
>AGREED!!!!!!! THAT IS WHY MATHWORKS SHOULD FIX THIS UGLY FLAW AT THE ROOT!
>(rather than some of us creating this kludgy work around.) the fact that
>TMW cannot see this deficiency for what it is, does not speak highly for a
>product and group of people that, otherwise, have so much technical
>sophistication.
I have similar thoughts about this. It's really mind boggling from my
point of view.
>fine. remember i'm a DSP person that wants to use MATLAB as a tool. i am
>not, nor have ever purported to be, a skilled MATLAB programmer. and to
>tell the truth, i don't really want to be, but this fix is so fundamental
>and salient, that i'll try to learn what i have to to make it happen.
Likewise. I don't really want to have to become a power user to get
this functionality. I use many other tools, like MathCAD, C, and SPW
sporadically, too, and like the ability to not *have* to be a power
user to be productive. It is a tradeoff that I make personally, but
it does make me gravitate toward tools that give me good productivity
bang for the buck. Matlab is, IMHO, so close to being in that
category that it hurts, except for this nagging discrepancy with the
indexing.
...
>if we can make it elegant to the user, i have no doubt that it will,
>_in_time_, become useful to a large number of people and in a decade or
>before, Cleve will see the error in not making this part of the basic MATLAB
>variable definition. if we can make this to work as i have been envisioning
>it, and trying to communicate that vision, i have no doubt of that at all.
>it's not that complicated, conceptually, and i still find it incredible that
>the vision at TMW has been for years, so limited that this had not been
>implemented before the Sig. Proc. Toolbox even came out. especially since
>Tom Krauss brought it up at that time. it's amazingly myopic (and
>unfortunate).
I agree. I think this is also why some of us push so hard on this
problem every time it comes up: the longer TMW waits to fix it, the
harder it will be to fix, and the more resistance there will be to
fixing it. Personally I don't think that's in TMW's interest or the
user's interests (and in this case I mean _all_ users), since it has
the potential to erode Matlab's utility, especially as other tools
increase in popularity and power.
Yves Piguet
in many situations, I also understand that Mathworks wants
to think twice (or more!) before implementing something
like varbase in Matlab's core. Backward compatibility is
not enough to justify any change; consistency is another
one. 0-based indexing must not be a kludge used only by
programmers which are aware of its limitations, but work
everywhere seamlessly; otherwise, learning Matlab will
be a nightmare.
I've probably missed something, but it seems that all
functions which use 1 for the first argument will break
silently when presented with non-1-based arrays. The
(special) function to pick the last element is "end";
one can assume that there are as many functions which
use 1 for the first argument. On a Sun workstation I've
accessed to at EPFL, with Matlab 5.3.1 and many of
the standard toolboxes, I've attempted to evaluate the
number of these functions with
find . -name '*.m' \( -exec /usr/xpg4/bin/grep -q -n
':end' \{\} \; -o -exec /usr/xpg4/bin/grep -q -n
'(end' \{\} \; \) -print | wc
This gets 115 m-files on a total of 704, _without_ counting
those which use size, length, or end in a more complicated
expression or surrounded by spaces. At least 16% of
functions which would most probably break silently.
I'd be interested to know if I've missed something.
We'd probably implement the result in our own software...
Yves
robert bristow-johnson
<pig...@ia.epfl.ch> wrote:
> While I understand that 0-based arrays would be convenient
> in many situations, I also understand that Mathworks wants
> to think twice (or more!) before implementing something
> like varbase in Matlab's core. Backward compatibility is
> not enough to justify any change; consistency is another
> one. 0-based indexing must not be a kludge used only by
> programmers which are aware of its limitations, but work
> everywhere seamlessly; otherwise, learning Matlab will
> be a nightmare.
>
> I've probably missed something, but it seems that all
> functions which use 1 for the first argument will break
> silently when presented with non-1-based arrays.
sure. with the object that Nabeel has created (or the similar one that i
might try to do next month), any non-1-based array is a different object
than a MATLAB "double" and i s'pose the functions that are not overloaded
will refuse to take an object that is not of class "double".
> The
> (special) function to pick the last element is "end";
*this* is a problem. can we overload that "end" function (in the context of
x(end) )? if not, that appears to be a limit to using Nabeel's OOP
solution.
> one can assume that there are as many functions which
> use 1 for the first argument. On a Sun workstation I've
> accessed to at EPFL, with Matlab 5.3.1 and many of
> the standard toolboxes, I've attempted to evaluate the
> number of these functions with
>
> find . -name '*.m' \( -exec /usr/xpg4/bin/grep -q -n
> ':end' \{\} \; -o -exec /usr/xpg4/bin/grep -q -n
> '(end' \{\} \; \) -print | wc
>
> This gets 115 m-files on a total of 704, _without_ counting
> those which use size, length, or end in a more complicated
> expression or surrounded by spaces. At least 16% of
> functions which would most probably break silently.
i expected that functions would have to be overloaded, not for backward
compatibility but for making existing MATLAB utilities available for the
non-1-based arrays. 115 sounds quite finite to me (because, for most
functions, the change will be small). 704 is less finite. but for the
"end" function to be extended sounds like a real problem.
Cleve, this *really* should be fixed at the lower level rather than in a new
class built on top of the current foundation.
r b-j
Bob Cain
Steven Lord wrote:
>
> As an additional reference, the Using MATLAB manual (available here:
> http://www.mathworks.com/access/helpdesk/help/techdoc/matlab.shtml) has a
> full chapter on MATLAB OOPS, including several examples.
Ah, thanks. I have access to that in hard copy.
Jordan Rosenthal
> *this* is a problem. can we overload that "end" function (in the context of
> x(end) )? if not, that appears to be a limit to using Nabeel's OOP
> solution.
Yes, you can overload the end function.
Jordan
Yves Piguet
> *this* is a problem. can we overload that "end" function (in the context of
> x(end) )? if not, that appears to be a limit to using Nabeel's OOP
> solution.
Yes, it should be possible. But what will still miss is a "begin"
special function for the first element.
> i expected that functions would have to be overloaded, not for backward
> compatibility but for making existing MATLAB utilities available for the
> non-1-based arrays. 115 sounds quite finite to me (because, for most
> functions, the change will be small). 704 is less finite. but for the
> "end" function to be extended sounds like a real problem.
115 must be a conservative minimum of m-files. Probably other functions
use length and size. You can add built-in functions, mex files
and other toolboxes...
Yves
robert bristow-johnson
> > *this* is a problem. can we overload that "end" function (in the context of
> > x(end) )? if not, that appears to be a limit to using Nabeel's OOP
> > solution.
Jordan Rosenthal <j...@ll.mit.edu> wrote in message news:<3C23AFCD...@ll.mit.edu>...
...
> Yes, you can overload the end function.
ypi...@netscape.net (Yves Piguet) wrote in message news:<635d97c9.01122...@posting.google.com>...
...
> Yes, it should be possible.
yeah, i guess this should be filed in the "Duh" category since i see
now that Nabeel has an overloaded MATLAB method with that name. i was
paying to much attention to the counstructor and subsref() and
subsasgn() to notice the end.m file.
> But what will still miss is a "begin"
> special function for the first element.
that's true. but that's only a problem for people starting to use the
new indexing functionality. here i have two (rhetorical) points to
make:
1. ya know, if this changable index base functionality is going to be
used initially by enough people to be put off because not every
appropriate standard MATLAB function won't be updated by the time they
can first use it, then that emphsizes my case to TMW and Cleve that
there are more people than you folks appear to be estimating that want
this kind of functionality. if that's the case, why the #$@%^&$%#
can't this be done at the root level with some kinda mission and
priority at TMW? IT'S IMPORTANT!
2. my desire, even if this thing lives in the lowly form of a MATLAB
OOP class, is for all appropriate MATLAB standard functions to be able
to take the "rebase" class argument and at least report that the
function only works for 1-based arguments. or at least to work on the
member array as a 1-based matrix oblivious to the base (and maybe
report that it did that). for functions that have a meaningful
mathematical extension to non-1-based arguments, i would like to see
that implemented but i don't expect that to come out right away for
every existing MATLAB functions. and there might be functions that
will never be gotten to (unless the geniuses at TMW take this on with
some purpose).
> > i expected that functions would have to be overloaded, not for backward
> > compatibility but for making existing MATLAB utilities available for the
> > non-1-based arrays. 115 sounds quite finite to me (because, for most
> > functions, the change will be small). 704 is less finite. but for the
> > "end" function to be extended sounds like a real problem.
>
> 115 must be a conservative minimum of m-files.
yeah, i want to do the elementary functions right away (along with the
central MATLAB operators as well as oft-used core functions like
plot()).
> Probably other functions use length and size.
yes. and that is the test. only where functions (or the proprietary
core MATLAB source code) make reference to an array's length or size
or shape, only there will it need to perhaps be considered whether the
array base be referenced.
> You can add built-in functions, mex files and other toolboxes...
you know, unless TMW takes this on with some imperitive purpose (and
as they say, TMW "is a tough audience" about this), no one can expect
this to expand to serve all mex files and other toolboxes out there.
one thing i would wanna do is
*reform* the Sig Proc Toolbox so that no inappropriate indexing is
required for any arguments. that is where this fundamental flaw in
MATLAB is so apparent (except to the folks at TMW, i guess).
Cleve and MathWorks folk, sorry to be sticking these jabs in there at
every opportunity, but i feel that i have to point this out at every
opportunity. until i can tell that you folks "get it".
best regards to everyone and all have a happy holidaze.
r b-j
Ken Davis
Another thought on the subject... It would probably be sufficient for
most signal processing applications for Matlab to have a startup switch
(or something) that switches between 1-based indexing and 0-based
indexing, controlling the remainder of the session. That way the matrix
manipulators can choose one way and the signal processors can choose
another.
Of course, there are some circumstances where it would be useful to have
both in the same session/environment, but a startup-time switch might go
a long way to quelling the unrest, while being easier to implement. Just
another $0.02 (were getting up near a dollar on this topic).
Ken
Ken Davis
robert bristow-johnson wrote:
>
[snip]
> > The
> > (special) function to pick the last element is "end";
>
> *this* is a problem. can we overload that "end" function (in the context of
> x(end) )? if not, that appears to be a limit to using Nabeel's OOP
> solution.
>
There is no reason why the end function (or any other matlab function)
cannot be overloaded. I have done this myself for some of my classes.
Ken
[snip]
Eli Brandt
Ken Davis <ken....@alcatel.com> wrote:
>Another thought on the subject... It would probably be sufficient for
>most signal processing applications for Matlab to have a startup switch
>(or something) that switches between 1-based indexing and 0-based
>indexing, controlling the remainder of the session.
A global switch would be simple to implement, but as soon as you flip
it to 0 you'd have the same old problem of "for i = 1 : length(x)"
code breaking. So it turns out actually to be less total effort to
have array origin local to each function, as in
http://groups.google.com/groups?hl=en&selm=3C1BCB54.829AFF98%40znet.com
and following articles.
With function-local array origin you'd have to modify find() and other
functions that pass or return indices [1]; in return you'd get
0-or-1-based arrays as you please. With array-local origin you'd have
to modify most all code that uses indexing; in return you'd get, for
example, to represent acausal FIRs nicely. Implementors of DSP
languages can pick their tradeoff.
[1] You know, if the language had a type system, one that recognized
"index" as a type -- and if all index arguments were annotated or
inferred as being of index type -- then you wouldn't even have to
modify those functions; indices would be adjusted automatically.
--
Eli Brandt | el...@cs.cmu.edu | http://www.cs.cmu.edu/~eli/
Ken Davis
In 0-based code you would use: for i = 0:length(x)-1 and for 1-based you
would use for i = 1:length(x). I'm not sure what the "same old problem" is,
but, for i = 1:length(x) should break 0-based code.
Code written for one base should be broken in the other. I was merely
suggesting that signal processors could write their code for 0-based and
vector-matrix people could write their code for 1-based. Then everybody
could be happy.
Regards,
Ken
"Eli Brandt" <e...@gs211.sp.cs.cmu.edu> wrote in message
news:a092ul$c2q$1...@cantaloupe.srv.cs.cmu.edu...
Eli Brandt
Ken Davis <kend...@erols.com> wrote:
>In 0-based code you would use: for i = 0:length(x)-1 and for 1-based you
>would use for i = 1:length(x). I'm not sure what the "same old problem" is,
>but, for i = 1:length(x) should break 0-based code.
>
>Code written for one base should be broken in the other.
What I'm saying is it's not necessary to break either kind of code.
The array base can be made function-local, so each function can use
the form of indexing it prefers, in isolation from other functions'
choice (unless, as discussed, one passes an index value to another).
Matrix code can be written 1-based and DSP can be written 0-based, at
the same time and in the same system, and with updating only a small
subset of legacy code.
Bob Cain
Eli Brandt wrote:
>
> Matrix code can be written 1-based and DSP can be written 0-based, at
> the same time and in the same system, and with updating only a small
> subset of legacy code.
Eli, what legacy code do you see that would need modification? I've
been thinking there wouldn't be any under that scheme.
The biggest problem I see is in documentation and that is not exactly
cheap. As it is, any functions that accept or return indices implicitly
do so relative to 1 origin but as functions begin to proliferate that
accept or return indices either relative to 0 origin or to the callers
origin this detail will have to be more explicitly documented for those
functions both new and old. Just that documentation hit could be too
bitter a pill for MathWorks to swallow this late in the game. Much as I
would like to see it I must admit that in their shoes I would be hard
pressed to take that hit.
Abe Kohen
>
>
> Eli Brandt wrote:
> >
> > Matrix code can be written 1-based and DSP can be written 0-based, at
> > the same time and in the same system, and with updating only a small
> > subset of legacy code.
>
> Eli, what legacy code do you see that would need modification? I've
> been thinking there wouldn't be any under that scheme.
>
> The biggest problem I see is in documentation and that is not exactly
> cheap.
Sure there is a business cost involved, but the improved documentation (and
not just for variable based indexing) would be a big plus for all.
Abe