Re: rewrite of structs - advice sought

[Jaroslav Hajek]

On Tue, Jun 22, 2010 at 5:20 PM, John W. Eaton <address@hidden> wrote:
> On 22-Jun-2010, Jaroslav Hajek wrote:
>
> | 1. general opinions about this? Is this a worthy goal for Octave? So
> | far it had been mostly fun, now the hard work (debugging) begins, so
> | I'd like to know if I should abandon the effort in time.
> |
> | 2. naming: I chose octave_map and octave_scalar_map, so that
> | octave_map and Octave_map only differ in capitalization. Since
> | Octave_map should eventually go away, this almost-nameclash seemed OK
> | to me, but I'm open to objections.
>
> Is there a less radical set of changes that could be made that would
> improve performance but leave the existing interface while not having
> two internal implementations?

I don't know. I initially considered having the polymorphism inside
octave_map directly, but it was getting clumsy. In most other cases,
data is polymorphic at octave_value level as well (with the exception
of idx_vector).

Having a simpler, specialized class for the scalar struct is actually
a key idea. It should be easier and more efficient to work with, e.g.
use m.contents (key) instead of m.contents (key)(0) etc.

> I guess I don't see why you need to
> completely replace the old interface with something new.

Because the data structure was completely different.

>   Instead,
> wouldn't it be possible to change the internals of Octave_map to be
> more efficient and add whatever new methods make sense or are needed
> for the new internal representation?
> Rather than allowing conversion
> to/from a new octave_{scalar,}map and the old Octave_map classes, you
> would only have to convert the new internal layout when needed by the
> old interface functions.
>

See above. I guess you'd have to suggest an implementation for this.

best regards

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