From octave-sources-request at bevo dot che dot wisc dot edu Wed Mar 7 07:50:43 2001 Subject: Re: Cell array support From: Paul Kienzle To: Jianming Cc: "John W. Eaton" , octave-sources Date: Wed, 7 Mar 2001 06:40:58 +0000 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 On Tue, Mar 06, 2001 at 01:00:01PM +0800, Jianming wrote: > Hi, > I've divided the patches as you have requested. I did it manually. > Hopefully it applies cleanly. > > I've looked at Pual's patch. Mine's mainly the same as his. The only > difference is that my octave_cell is based on octave_base_matrix, while he's > not. > > I've also adopted his idea of using a function call assign_fill_element > to fill an array during resize (Array-idx.h and Array2-idx.h). Previously > mine was an object creation, which can be quite slow. However, I've moved > the function call into Array Class, so that the object creation function > assign_fill_element() is instaniated automatically, instead of creating one > for each of the objects. In addition, this is a static function, returning a > static element. Hopefully g++ is clever enough to know what to do. I tried > to put a const qualifier for the function as well to give more clues to the > compiler, but was told by g++ that that is not allowed for static function > calls. > > I've not seen any noticable speed difference after applying the patch. > > So here are the patches: > > 1. errmsg: basically changes range error messages to reflect better > where they come from. Just a minor patch while doing debugging > 2. base-mat: move assign function into base-mat instead of having one in > each of re-mat, cx-mat, bool-mat, cell. > 3. arrayassign: replace static class with assign_fill_element > 4. cell: improve cell support (currently only scalar and matrix, others > can be added very easily). > > Regards, > Jianming > > > ----- Original Message ----- > From: "John W. Eaton" > To: "Jianming" > Sent: Saturday, March 03, 2001 2:01 PM > Subject: forwarded message from Paul Kienzle > > > > Here is Paul's cell array patch. I haven't had time to really look at > > it closely, and I'm not even sure it will apply cleanly to the CVS > > sources now. > > > ------------------------------------------------------------- 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 -------------------------------------------------------------