From octave-maintainers-request at bevo dot che dot wisc dot edu Tue May 7 10:43:27 2002 Subject: Re: Cell array changes for Octave From: "John W. Eaton" To: "Cai Jianming" Cc: "octave-maintainers mailing list" Date: Tue, 7 May 2002 10:43:14 -0500 On 7-May-2002, Cai Jianming wrote: | > Octave, along with some modifications. There is still some more work | > to do to properly support "x{ }" style indexing, but most of the other | | IMHO, I think we would need to define the proper semantics of each | indexing/assignment before the implementation. Should we follow Matlab? Yes, I'm working on that now. We'll be able to support subsref and subsasgn, at least. I'm also working on structure arrays, since that is also needed. | > octave:3> y(1,2) = x | > error: A(I, J) = X: X must be a scalar or the number of elements in I | must | > error: match the number of rows in X and the number of elements in J | must | > error: match the number of columns in X | > error: evaluating assignment expression near line 3, column 8 | | > So you can see that indexing to insert a cell inside a cell doesn't | > work yet. I need to make "x{ }" style indexing and indexed assignment | > call different functions than are used for the "x( )" style indexing | > and indexed assignmend operations. | | y(1,2) = {x} will work as intended, i.e. embed cell x as a cell element of | y. No, not with the changes I've made so far based on your patches: octave:3> x = {1,2} x = { [1,1] = 1 [1,2] = 2 } octave:4> x(1,2) = {3,4} error: A(I, J) = X: X must be a scalar or the number of elements in I must error: match the number of rows in X and the number of elements in J must error: match the number of columns in X error: evaluating assignment expression near line 4, column 8 And besides, if this worked, it would be incompatible with Matlab: >> x = {1,2} x = [1] [2] >> x(1,2) = {3,4} ??? Assignment has more non-singleton rhs dimensions than non-singleton subscripts. >> x{1,2} = {3,4} x = [1] {1x2 cell} So we need to handle the "x( )" and "x{ }" forms of indexing separately. | > * Should we implement lists as a special case of Cell arrays? I | > think yes, but maybe there is a reason not to? Should lists be | > marked as deprecated and removed in a future version of Octave? | | Actually, I don't see the need for lists once we have proper support for | cell arrays. In fact, passing of parameters for functions should be done via | cells, as done in Matlab. I think they call their argument lists "comma separated lists" and they are similar to cell arrays, but slightly different. For exmaple x = {1, 2} is a two-element cell array and x{:} produces a two-element comma separated list. You can write foo (0, x{:}, 3} to pass the arguments 0, 1, 2, and 3 to the function foo, but you can't write foo (0, x, 3) to do the same thing. So I think the two things (cell arrays and comma separated lists) must be distinct. Octave already uses the octave_value_list object for arguments lists and the ov-list data type is just a way of packaging octave_value_lists so that they can be passed around as an octave_value, so I think it will be easy to make Octave's current list data type become the "comma separated list" type. jwe