Re: Help with [] for defined types

[Paul Kienzle]

On Jul 28, 2004, at 3:53 AM, David Bateman wrote:

> According to Paul Kienzle <address@hidden> (on 
> 07/28/04):
> > I've considered adding sparse support to mex by calling the
> > functions "spfind" to get the matrix out of the octave value and
> > "sparse" to put the matrix back into a sparse value.  You could
> > do something similar in load/save for the matlab binary type.
> > Until octave has a sparse type of its own it can include fake
> > sparse m-files for these two functions which save the result
> > in full matrices.  If octave-forge is present, then it will pick up
> > Andy's version of the functions.  I guess you will also need
> > "issparse" to detect whether the matrix type is a sparse matrix
> > before storing it.
>
> But the matlab load/save code is all concentrated in ls-mat*.cc and so
> some supporting code will be needed there to load the matrix. Loading
> them as full matrices and then converting them to sparse seems to be
> against the wholw spirit of using sparse matrices in the first place..

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.

> 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.

> * 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.

> * 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.

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

- Paul