Re: Accessing information returned from 'dir'

[mddejong]

> The expression foo{:,1} returns a comma-separated list (in Matlab, you
> would not even be able to perform the assignment to the variable bar
> -- should Octave also make this an error?).  When you pass a
> comma-separated list to a function, you are passing each element as a
> separate argument.  The typeinfo function expects a single argument,
> but you are passing three.

But that argument doesn't work for bar(1) or bar{1}. If I draw the
parallel to the problem with accessing elements in "foo = dir("./");
foo(1).name", you must write something like "bar(1)." in order to access
the subarray returned by Etienne's example. Octave allows the splice, but
then does not allow you to access the elements as you would expect. The
furthest I got was with nth({bar}, 1), but trying {bar}{1}, {bar}(1) or
any other logical option on the left hand side of an expression failed.

There are two possibilities, and in my opinion, Matlab has chosen the
wrong one. You *should* be able to make a cross-section in a cell array
and expect the result to behave like another cell array. Why not, since a
cell array is just a collection of objects? Otherwise you are faced with
the rather strange inconsistency that matrices *do* allow you to spline
and come up with another matrix. I know, incompatibility with Matlab is
probably Very Bad, but internal consistency is a Good Thing.

While on topic, what is the reason for accessing cell arrays with {}?
Efficiency within Octave's interpreter in terms of storage because it
knows beforehand it is dealing with a cell array instead of a matrix?


My two cents,
Maarten



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------