From octave-sources-request at bevo dot che dot wisc dot edu Sat Mar 10 10:31:11 2001 Subject: Re: Cell array support From: "Jianming" To: "Paul Kienzle" Cc: "octave-sources" , "John W. Eaton" Date: Sun, 11 Mar 2001 00:28:52 +0800 Hi, Thanks for the comments. First, I would like to admit that I did not think about compatiability at all when I wrote this patch. I wrote it because I need it to use it in some octave code of my own. I need to access an array of matrices, where each matrix can be of different sizes. 1) For consistency, I think Array-Cell.cc is better placed in liboctave/, following the example of Array-b, Array-ch, Array-d etc. In addition, Cell.cc and Cell.h should be moved to liboctave as well, again for consistency, to be similar to dMatrix etc. 2) Apparently, magically, when I dereference the cells, I get empty matrices, i.e. [](0x0). Perhaps there is some conversion going on? Maybe John can shed some light on this. 3a) Yes, narrowing conversion is used. b) IMHO, there should be a clear distinction between 0, [] and {}. 0 is the base type for scalar, [] for matrix, and {} for cells. Hence, just as Matrix(2,:) = 0 should *not* delete the 2nd row of matrix Matrix, Cell{2,:} = [] should *not* delete the 2nd row elements of cell Cell. Similarly, just as Matrix(2,:) = [] should delete the 2nd row of Matrix, Cell{2,:}={} should delete the 2nd row of Cell. This is what is implemented in my patch (hopefully). The relationship between cells and matrix is the same as the relationship between matrix and scalars. Hence, for your example, x(m,n)=x(i,j) where x(i,j) is [], will not delete x(m,n). However, I can still delete using x(i,:)={}. NOTE: The following two lines should be added to OPERATORS/op-cell.cc in order that the above works: DEFASSIGNOP_FN (assign3, cell, cell, assign) : : INSTALL_ASSIGNOP (op_asn_eq, octave_cell, octave_cell, assign3); c) I think we should remove the "cellness" of a single element, just as we remove the "matrixness" of a 1x1 matrix. However, converting back to cell should not be a problem, because the cell_value of octave_matrix and octave_scalar will return a cell containing a single element. Hence, we try to "reduce" an object whenever possible, but also provide the avenue to "upgrade" an object when needed. This is also done between matrix and scalar. d) I agree that there should be a distinction between x{i,j} and x(i,j). However, I'm not proficient enough in lex and yacc to do it. Hence, for my patch, x{i,j} and x{i,j} are the same. Ideally, we should have d=[1 2 3 4 5] d{1} ans = [1 2 3 4 5] Instead, now we have d{1} ans = 1 which is wrong. One way to do is the following. When {} is used for indexing, the object, e.g. d, is converted to a cell first before the actual index ops. For this, we can use the cell_value function. Once we are able to distinguish between d{1} and d(1), I do not see a need to preserve the cellness of a single element. Lastly, I'd like to point out that the patch is not meant to be a complete one. In particular, complex, complex_matrix, strings etc support are not added. Also, point 3(d) is not implemented. A lot of improvements still needs to be done. Regards Jianming ----- Original Message ----- From: "Paul Kienzle" To: "Jianming" Cc: "John W. Eaton" ; "octave-sources" Sent: Wednesday, March 07, 2001 2:40 PM Subject: Re: Cell array support > Jianming, > > I've had a chance to look at your cell-array patches and I have a couple > of comments. Note that I have not applied and tested it, so some of the > comments may be out of line. > > 1) Putting Array-Cell.cc in liboctave/ seems like a bad idea because it > ties liboctave to the interpreter (octave values are only defined in the > context of the interpreter which is using them). Either you should move > the full machinery of dynamic type support into liboctave, including > the operators specific to this dialect of numerical programming, or you > should move Array-Cell.cc back into src/Cell.cc where I had it. > > 2) I don't see how you force the assign fill element to be > octave_value(Matrix(0,0)). The best I can tell without applying your > patch is that filled elements will contain octave_value(), which will > lead to complaints about unknown type in the octave interpreter if > you dereference one of the filled cells. This may be a better solution > conceptually, but for compatibility you should fill with []. Since Octave > has lists and structs, you only need cell arrays for compatibility, > so you might as well make them as compatible as you can. > > 3) I don't see an explicit dereferencing function for cell arrays. > I suspect you are using the narrowing conversion to convert a single > element cell-array into a base octave value. I explored this possibility > but decided against it. Consider the cell x(i,j) which contains []. > If you then do x(m,n) = x(i,j), the narrowing conversion will convert > x(i,j) to [] and the indexed assignment will treat this as a deletion > operation. Alternatively, [] will automatically be converted to > {[]}, which means you won't be able to do x(i,:) = [] to delete row i. > > The other problem is that removing the "cellness" of a single element > cell array will cause functions that change their behaviour depending > on whether they get a cell array or some other type will not work for > single element cell arrays. IIRC, the narrowing conversion applies > after the operation is complete (which is why you can't force an > octave value to be complex unless you have a non-zero imaginary part), > so this is a potential problem. > > I agree that it is annoying that x(i) returns a cell or a list rather > than the contents of the cell or the list, but there will always be > cases where you want to preserve the "cellness" or "listness" of the > single element list. To get around this, matlab invented the x{i,j} > syntax for dereferencing cell arrays, and octave invented nth(x,i) > for dereferencing lists. I chose to support nth(x,i) since it was > easier to implement, but I think proper x{i} support is required for > compatibility. Again, if you don't need it for compatibility, why > bother with cell arrays at all? > > Paul Kienzle > pkienzle at kienzle dot powernet dot co dot uk > <<--- snipped ------->> _________________________________________________________ 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 -------------------------------------------------------------