Re: [major] struct array indexing in tip

[Jaroslav Hajek]

On Sun, Jan 25, 2009 at 12:55 PM, Thorsten Meyer <address@hidden> wrote:
> Hi,
>
> Jaroslav Hajek wrote:
>
> octave:173> [b(1:2, [1,3]).name] = deal("aaa", "ddd", "ccc", "fff");
> error: A(I,J,...) = X: dimensions mismatch
>
> Is that intended behaviour?
>
>
>
> This stuff never worked correctly, so it's hard to judge by older
> versions, but I think that given that cs-lists aren't allowed to have
> shape, they should automatically reshape when assigned to lvalues like
> a{1:2,3:4}. This following patch should guarantee this.
> http://hg.savannah.gnu.org/hgweb/octave/rev/35656d6ad061
>
>
> Does that mean, that  [b(1:2, [1,3]).name] internally still has shape? I
> thought that
>      b(1:2, [1,3]).name
> is a cs-list without shape, that gets converted to a vector (of some kind of
> pointers into the b structure array) by the [] operator.
>
> regards

No, the code doesn't work like that. b(1:2, [1,3]) used as an
expression yields a linear cs-list (see octave_cell::subsref and the
octave_value_list::octave_value_list (const Cell&) constructor).
However, when used on lhs of assignment, the indexing expression do
*not* evaluate to some kind of lists of references or pointers;
instead, the octave_lvalue object retains the index chain and a
pointer to the "root" object. To allow further processing, it also
computes the element count for the expression and eventually evaluates
subscripts with "magic ends" (see tree_index_expression::lvalue).
The assigment handling code (tree_multi_assign::rvalue) builds up all
the lvalue expressions, sums their size (to get proper nargout for
rhs), evaluates rhs, partitions the cs-list yielded by rhs and calls
octave_lvalue::assign, that in turn calls subsasgn on the root object.
In fact, I think it's better than building up an array of references
because this allows us to optimize stuff like [a(1:n).b] = c{:} to be
performed using a shallow copy.
However, the bulk of work is passed down to the (optimized)
Array<T>::assign methods (via the Cell interface), and these respect
the shape matching rules of normal array assignments. That's why the
portion of cs-list needs to be reshaped.

OK, sorry for the technical bogus. The short answer is yes, internally
the expression has shape, but when evaluated, it loses it.

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz