Re: Really fix indexing in orderfields.m

[Jaroslav Hajek]

On Wed, Jan 28, 2009 at 7:55 PM, Jason Riedy <address@hidden> wrote:
> And Jaroslav Hajek writes:
>> 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).
>
> In Octave, definitely. If you're using structs as an imitation of R's
> data frames, then having dozens of fields is not uncommon.  Or if you're
> using it to slice a database[1] without knowing much about the data
> structure.
>
>> 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).
>
> Well, yes, and you're also better off performance-wise writing a C++
> extension. ;)
>
>> > The surprise here is that t.("f1", "f2") returned *only* t.f1.
> [...]
>> I don't think this is supposed to work like that - it should give you
>> a parse error. Do you have a counterexample?
>
> That probably is a parse error, but put a cell array in there:
>  t = struct ("foo", {1, 2}, "bar", {3, 4});
>  nm = fieldnames (t);
>  t.(nm)
> will return the first field. It probably should issue an error,
> or a warning if existing code assumes that behavior. So there's
> a cellstr -> string conversion happening somewhere...
>
> t.(nm{:}) errors out, as currently is appropriate.
>
> Jason
>
> Footnotes:
> [1]  I have a toy, *simple* DBI adapter for SQLite.  I need to rework
> the matrix stuffing before it's ready for wide release, but it's at
>  http://jriedy.users.sonic.net/cgi/jriedy/cgit/cgit.cgi/osdbi/
> if you want a laugh.  I haven't tested it against a development version
> of Octave yet.  Handy for throwing plot-generating data between Octave,
> R, and other tools, although definitely not the right choice for most
> uses.
>

This seems interesting. Do you intend to include this in OctaveForge?
There's a database package, but I think it provides only raw sql
queries (maybe I'm wrong).

Anyway, if in the future you will want the fast slice-by-names
operation, I think the best way is to rewrite getfield as a compiled
func and optimize that.

cheers

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