octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Really fix indexing in orderfields.m


From: Jaroslav Hajek
Subject: Re: Really fix indexing in orderfields.m
Date: Wed, 28 Jan 2009 19:04:51 +0100

On Wed, Jan 28, 2009 at 4:00 PM, Jason Riedy <address@hidden> wrote:
> And Jaroslav Hajek writes:
>> 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?):
>
> Thank you! I know about the multi-dims (I've written a few
> partial matfile readers), but I was hung up on the field part.
>
>> I see you were surprised that the assigment [t(:).x] = s(:).x doesn't
>> work if t does not exist.
>
> No, that was the obvious part. My disappointment was that t.("f1",
> "f2") doesn't work to slice by fields like R's df$c("f1", "f2").
> If it did, then t = s.(names) would be the easiest (and likely
> fastest) method.
>

That's an interesting point. I don't think Matlab supports the syntax,
however. And it seems a little weird (though the logic is obvious).
Maybe we could just extend "getfield" to support this, i.e. "t =
getfield (s, names)".
But anyway I think that structs with more than, say, a dozen of fields
are very rare, so I don't see optimizations here as necessary
(currently getfield is m-file so it would loop anyway).
Instead of a struct with lots of fields, one may be better off using a
list of keys and values separately, and use lookup + indexing (lookup
now works with strings and does a binary search).

> The surprise here is that t.("f1", "f2") returned *only* t.f1.
> Right now, I can't spend the time on making this work, so chalk it
> up to a future patch.
>

I don't think this is supposed to work like that - it should give you
a parse error. Do you have a counterexample?

>> 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.
>
> Thank you for all the indexing work! It very well might help for my
> data analysis side.  Although now I seem to be hitting a memory
> leak / gc issue. sigh. Have to work down to a test case to see if
> it's my code's problem or not.
>

You're welcome. Bug reports are also welcome, of course.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]