octave-maintainers
[Top][All Lists]
Advanced

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

some notes about mex support in Octave


From: John W. Eaton
Subject: some notes about mex support in Octave
Date: Sat, 8 Jul 2006 03:45:37 -0400

Paul Kienzle and I were having an off-list discussion about mex
support in Octave.  That seemed appropriate when I thought that
adopting the code from Octave Forge would be relatively quick, even
with my plans to change the implementation of the mxArray
object to be a wrapper around an octave_value object.

I did a fair amount of work on this conversion, but the more I
understand about the way the mxArray object is supposed to be used,
the more I think it is impossible to simply wrap an octave_value
object.  Since the mxArray documentation says that it is perfectly
acceptable to screw around with the dimensions and data separately, I
think there is no way that we can do this on top of octave_value (at
least not given the current implementation of octave_value, and I'm
not really interested in making octave_value less safe just to support
mxArray).

The only alternative I see is to implement mxArray separately to match
the documentation for it, then convert to and from octave_value as
needed (when passing values to/from mex functions and Octave, either
by way of calling the mex function or mexCallMatlab).  These
conversions will require copies of the data, which I know is not
ideal, but I think this is the only way to preserve the semantics of
the mx* functions.

Maybe it won't be too hard to do this with templates and some simple
inheritance structure.  All we really have to do is implement a set of
containers.  There are very few actual operations on mxArrays and most
seem to be quite simple.  The mxArray class can be

  class mxArray {
    public:
      ...
    private:
      int class;
      int ndims;
      int *dims;
      char *name;
  };

This will be a virtual base class.  It won't be possible to create an
mxArray object directly.  Only specific derived types can be
constructed.  (And anyway, users will only be able to manipulate these
objects using the mx* functions, same as in Matlab's mex interface).

For numeric data, something like

  template <type T> class mxArray_number : public mxArray {
    public:
      ...
    private:
      T *pr;
      T *pi;
  };

can be instantiated for the logical, char, double, single, and
{u,}int{8,16,32,64} types.

For sparse arrays:

  class mxArray_sparse : public mxArray_number<double> {
    public:
      ...
    private:
      int *ir;
      int *jc;
      int nzmax;
  };

For structs:

  class mxArray_struct : public mxArray {
    public:
      ...
    private:
      int nfields;
      char **fields;
      mxArray **data;
  };

For cells:

  class mxArray_cell : public mxArray {
    public:
      ...
    private:
      mxArray *data;
  };

We leave essentially all memory management to the user, who is
expected to pass pointers around and explicitly use mxDuplicateArray
to make a copies.

We will add an "mxArray *make_mxArray (void) const" member function to
each specific type in Octave that can be converted to an mxArray.  The
new member funtion will return a newly allocated mxArray object of the
appropriate type.  This way, the conversion will be extensible (at
least as much as is possible given the fixed definition of mxArray).
The octave_base_value class will get a default version that throws an
error, so no changes will be required of existing classes derived from
octave_base_value.

Since converting from octave_value <-> mxArray will require a copy,
users who expect to be able to call mxGetPr on the argument to a mex
function and have modifications to that data show up in the mex
function's caller will be disappointed as that will not work.  Then
again, the documentation says that you should not expect it to work in
Matlab either.

Comments?

jwe


reply via email to

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