[Top][All Lists]

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

Re: Help with [] for defined types

From: Paul Kienzle
Subject: Re: Help with [] for defined types
Date: Wed, 28 Jul 2004 20:38:37 -0400

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

This means that this matlab issue needs addressing, but also what to do

* 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

- Paul

reply via email to

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