From octave-sources-request at bevo dot che dot wisc dot edu Tue Jun 5 20:37:41 2001 Subject: Re: Cell array support From: "Jianming" To: "Paul Kienzle" Cc: "octave-sources" , "John W. Eaton" Date: Wed, 6 Jun 2001 09:31:52 +0800 Hi, I hope you have seen my recent cell array patch on octave-sources. Here are some more thoughts I have when digging through octave code, trying to implement more cell functions. > IMHO, "x(idx) = []" for deletion is already pretty arbitrary (shouldn't it > produce a dimension conflict?), so I don't put too weight on consistency. > > I would be happier if deletion was identified in the parser, rather > than relying on the semantics of assignment from a particular value. > Something like "clear x(idx)" would be even less confusing. And less > error prone: consider "x(j) = b" where you are expecting a scalar b, > but someone passed b as [] instead. However, interpreting assignment > from and empty matrix as deletion of the indexed values is the defacto > standard, at least in Matlab, RLaB, SciLab and Octave. The assignment to empty values causes deletion at the underlying Array and Array2 classes. For matrix, empty values are []. For octave, empty values are {}. That is way the deletion cellvar(idx)={}will require no addtional work for the parser, and indeed for the intermediate classes, which is quite convienent and clean. Hence, I would not recommand special code to perform cellvar(idx)=[]. However, for consistency with Matlab etc, I guess we can create a special variable called maybe DELCELL. In octave, DELCELL={}, in Matlab etc DELCELL=[]. Hence, the users would use cellvar(idx)=DELCELL, and porting would not be a problem. > I was considering {} as a dereferencing operator which could produce > a multi-valued output, or when used as an lvalue, receive a multi-valued > output. For example, > > d=[1 2 3 4 5]; > [a,b,c] = d{1:2:5} > a = 1 > b = 3 > c = 5 > > Or as an lvalue > > clear d; > [d{2:3}] = sort([11 15 13]) > d = { > {1,1} = [] > {1,2} = [ 11 13 15 ] > {1,3} = [ 1 3 2 ] > } > This is best done by merging the code of octave_value_list and octave_cell. Matlab is able to do this painlessly because their CELL values are actually the values received from and passed to the functions. If we can take their approach, then the above will come automagically, after some patches to the parser. Hence I recommend merging octave_cell and octave_value_list, and make one the typedef of the other so that there will be less problems with legacy code. In fact, octave_value_list is a one dimensional octave_cell with some special methods for value list it self. > Also, you have to decide if you want to be able to conveniently splice > cell arrays into an argument list à la Matlab: > > t = f(x,d{:}) > > Regarding implementation, there is no need to change lex.l and the > change to parse.y is simple. Search for "'{' arg_list" and change the > associated function call to reflect that it is using brace indexing > rather than parenthesis. You could for example add another parameter > to make_index_expression to distinguish between '(' and '{', and extend > tree_index_expression in pt-idx.{cc,h} to do what you want. That will > be tricky. ditto. Little problem to implement when octave_cell and octave_value_list merge. Any comments? Regards, Jianming _________________________________________________________ Do You Yahoo!? Get your free at yahoo dot com address at http://mail.yahoo.com ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------