help-octave
[Top][All Lists]
Advanced

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

Re: Linking Octave to Cantera - concatenation error


From: Judd Storrs
Subject: Re: Linking Octave to Cantera - concatenation error
Date: Sat, 5 Dec 2009 18:23:45 -0500

On Sat, Dec 5, 2009 at 5:12 PM, John W. Eaton <address@hidden> wrote:
> As I recall, we really couldn't decide whether these were actually
> useful and thought it would be best to just use cell arrays of objects
> if you need to put them in a container of some kind.
>
> Could someone please explain why this feature is needed and how it is
> useful or better than using cell arrays of class objects?

Probably cell objects are just fine for new code.

The strongest argument for adding support compatibility with existing
Matlab code as in Emil's case. In terms of whether it makes sense or
not, Octave already does allow concatenation of struct arrays. If it
makes sense for a struct I'm not sure why objects would be different?

octave:1> a.field1 = "a" ;
octave:2> b.field1 = "b" ;
octave:3> [a b]
ans =
{
  1x2 struct array containing the fields:

    field1
}
octave:4> b.field2 = "b2" ;
octave:5> [a b]
error: invalid structure concatenation

Of course cell arrays don't enforce object uniformity so that could be
an advantage of an object array over a cell array--you would be sure
that you have compatible only objects. On the other hand, that does
get hairy, and I don't know how inheritance should work in the mix
though... should you be able to make a base class array? If anyone
cares I can try and figure out if Matlab allows mixed arrays with a
common base class. I agree it is confusing and cell arrays work just
fine.

Possibly, methods could be more efficient by acting on an array of
objects instead of looping over each element of a cell? Just
speculating here.

> | octave:3> { a b }
> | ans =
> | {
> | }
>
> Here, the result is a cell array containing both class objects.
> Nothing is printed for each element because there is no display method
> for the class FOO.  Maybe Octave should print some default message in
> that case, but it currently does not.  That part at least should be
> relatively easy to fix.

I didn't think of that. Right after I sent the mail I did briefly
wonder why I didn't get an indexing error before closing the
terminal... ;) I think that probably answers Emil's question: use {a
b} instead of [a b].


--judd



reply via email to

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