Re: Help with [] for defined types

[David Bateman]

According to Paul Kienzle <address@hidden> (on 07/29/04):
> Not my intent.  I was thinking of loading them as three separate
> vectors and calling sparse(i,j,v,m,n) via feval.  If the user does not
> have a sparse package, then some sort of fake sparse behaviour could
> be predefined in an octave m-file, such as populating a full matrix.
> I believe extra/fake-sparse has m-files for the task already.  Or it
> could load it into a structure of i,j,v.  Or it could skip that field.

Oh, ok. Its still a bit of a stopgap for a missing sparse type in octave
and it will need some modifications to octave itself. But it shoudl be
workable.

> >Ultimately, I believe the ideal solution is to convert all of the 
> >octave
> >types so that there is no distinction between internal and external 
> >types.
> 
> I heartily agree.  Matlab files are a bit of a special case however in
> that their behaviour is predefined elsewhere and is not a function
> of the new type.  We can either have the type register itself with
> matlab, saying that it can handle matlab type ids xxx, and yyy.  Or
> we can say that each matlab type id is loaded by the function
> matload_xx, and if a type wants to take control of  matlab I/O it will
> have to define
>       function v = matload_xx(stream,bytes) ...
> I think matsave has to be built into the octave_value class, and it will
> be up to the type creator how to represent their type in a matlab
> file.
> 
> >This means that this matlab issue needs addressing, but also what to do
> >with
> >
> >* The type registration, how to do it partially in advance while not
> >  increasing the memory footprint of octave for those that don't use
> >  all of the additional types
> 
> Using matload_xxx functions will do this.

My problem here was more generic. If I have the type octave_foobar, at
the moment octave is informed of its existence through a call to
register_type.  At that point it is dynamically linked to octave and
taking up memory. So in the current scheme if octave is to know in
advance of all of the installed types they all take memory, even those
that aren't used.

What I thought was that a pre_registration function might make sense.
Something like

octave_value_typeinfo::pre_register_type(std::string type_name, 
        std::string type_location)

A DEFUN could be created for this an a when octave is asked for type
type_name it knows where to find it, and these pre-registration could
occur in a global configurationm script.

At the first time octave is asked for the type, it loads the library
it finds at type_location and calls the corresponding register_type()
call.

> >* How to either get rid of stuff like octave_value(NDArray) or allow it
> >  for user types
> 
> Yes.  And some way of accessing types from oct-files without turning
> everything into a .so stored in a system path.  Could be tricky.

Either tricky or very ugly. The ugly solution would be to force the 
inbuilt type to use the same existing mechanisms as the external type.
That is

NDArray x;
...
octave_value retval(x);

would become

NDArray x;
...
octave_value retval = new octave_matrix (x);

As for calls like array_value(), perhaps we could have a lookup table
of functions to access the data in the octave_value. That is something 
like

octave_value a = args(0);
char ** array_value_fn = value_lookup_op(a.type_id(), "NDArray")
NDArray x;
if (!error_state)
  x = *array_value_fn (a);

This would at least be extensible, but no where near as simple as

NDArray x = args(0).array_value();

as we have at present. But the above scheme could be hidden behind a
call like

NDArray x = args(0).value("NDArray");

where the function "value" of the octave_value performs the same as the
above.

> >* Getting the internal types out of the liboctinterp.so library, 
> >including
> >  ls-mat.cc, xpow.cc, etc..
> 
> So rather than having a set of if statements in each function
> testing for type, using something like dispatch() to determine
> which function to call based on the type.

I hadn't really thought that one through that far, just the need for
a clear seperation of liboctinterp.so from the types.

> Interesting thought experiment:  how to make dispatch work for
> plot?

Oh, God there are so many things to think about in such a process. If
seperating the types from liboctinterp.so is the right thing to do then
it has to be as part of a larger effort to define a coherent API. I 
don't know if I'd what to embark on something like that at this point...

Cheers
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary