Re: Really fix indexing in orderfields.m

[Jaroslav Hajek]

On Tue, Jan 27, 2009 at 10:07 PM, Jason Riedy <address@hidden> wrote:
> # HG changeset patch
> # User Jason Riedy <address@hidden>
> # Date 1233089444 18000
> # Node ID 202bd681f367fad0c3966576569483be4deb0350
> # Parent  827f0285a2016fd6ce72d2906e08faea48fb205a
> Really fix indexing in orderfields.m
>
> My previous fix did not work, and the tests were insufficient
> to notice.  There was one original problem; the assignment to
> a non-existent t(:) triggered an error about querying t's size
> before it exists.  I replaced that error with a non-loop that
> happened to pick only one name out of the struct and spread it
> across all the fields.  The syntax struct.(name, name, ...)
> doesn't work, although it'd be nice.
>
> So the final fix is actually to add another loop to index
> t(1), t(2), etc.  Not high-performance, but neither are
> structs.
>
> Sorry.  Struct arrays still hurt my head, so hopefully this is
> a bit more correct.
>

Okay, so please note this patch that replaces the loop by a proper
index expression and also fixes the function to work with
multdimensional structs (maybe you were not aware structs can have
multiple dimensions?):
http://hg.savannah.gnu.org/hgweb/octave/rev/20d23d65cc84

After my recent work at optimizing struct and cell indexing I finally
understand the quirks of cells, structs and cs-lists myself, so I may
give you some explanations:

I see you were surprised that the assigment [t(:).x] = s(:).x doesn't
work if t does not exist. The reason is mostly technical: The number
of elements on the LHS should be known before rhs is evaluated, to be
able to pass proper "nargout" to a function. That's why
colon-subscripting of an empty or non-existent cell or struct is
forbidden (with arrays, an analogical expression attempts to inquire
the shape from the RHS).
Here, there is no function call, so it would be technically possible,
but complicated. Not that Matlab 2007a actually allows the expression,
but treats it as [t(1).x] and silently ignores the rest of rhs, which
I find very confusing (or a bug). That's why I decided to forbid it -
the workaround is easy, just figure out the proper length beforehand,
as in my patch above.
Note that the assignment
n = numel (s); [t(1:n).x] = s(:).x;
will (in development version) be *very* fast because it will actually
only make a *shallow copy* of s.x, i.e. there will be now a single
Cell object referenced by both s.x and t.x. The same would apply if
you substituted one or both of the sides with cells. This makes cells,
structs and cs-lists interchangeable very cheaply if you avoid
looping.
I hope this is going to contribute to performance of some complicated codes.

regards


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