[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MEX interface
|
From: |
Christopher Hulbert |
|
Subject: |
Re: MEX interface |
|
Date: |
Wed, 21 Jun 2006 21:40:54 -0400 |
On 6/21/06, John W. Eaton <address@hidden> wrote:
I checked in some changes to add partial support MEX files in Octave.
Currently it is a bit limited when compared to the interface in Matlab
7.x, but it does work for some examples (there are now a few in the
examples subdirectory). Most of this work was done by Paul Kienzle
starting in 2001, but I made a few changes when adapting the code from
Octave Forge.
This is good. Personally I'd rather see more documentation on using
the octave function in .oct files. I've been so busy I've never
gotten around to learning it. My MEX functions are typically
extremely simple because I keep the core code outside of the MEX
function,so writing an octave function wouldn't bother me.
Octave now searches for .oct, .mex, and .m files. The mkoctfile
script has a new --mex option which tells it to use .mex as the output
file extension instead of .oct (of course this only works if the code
you are compiling uses the .mex interface; it doesn't magically make a
.oct file turn into a MEX file).
One thing I like is the different mex extensions on each platform so
that multiple platform mex functions reside in the same directory
(mexa64,mexglx,mexw32,mexsol2,etc.). I think if octave is going to
support mex functions it ought to keep the platform extensions.
Currently the mxArray object can only handle a few different types of
objects (2-d numeric arrays, structs, and character strings). Paul
and I have discussed changing the implementation so that an mxArray
object is just a wrapper around an octave_value object. I think this
will help to quickly support more types, but Paul points out that
there may be some problems:
On 21-Jun-2006, Paul Kienzle wrote:
| There are some concerns about using octave_value:
|
| 1) the overhead of unwrapping and wrapping octave values for every
| single get/set to a field or cell array (minor concern ---
| better to have maintainable correct code if the overhead isn't
| too great)
| 2) still need to maintain field name -> field index mapping for
| the duration of the mex routine, and hope that folks don't
| rely on it between calls to the mex function.
| 3) mxGetPr should return the same pointer everytime it is called
| for the same value; make sure that each time the matrix is
| extracted from the octave value and assigned to a variable that
| the reference count isn't incremented, causing fortran_vec() to
| make a unique copy.
| 4) mxGetPr/mxGetPi on complex data will need to keep track of
| whether the data is RIRIRI or RRRIII or it will need to keep
| a copy in RRRIII. This will need to be restored to the correct
| order prior to calls to mexCallMatlab or return to Octave.
| 5) mxSetPr/mxSetPi aren't possible. For example, the following
| sequence is allowed according to the documentation:
|
| mxFree(mxGetPr(v));
| s = mxMalloc(mxGetElementSize(v)*100);
| /* initialize s */
| mxSetPr(v,s); mxSetM(v,10); mxSetN(v,10);
| /* continue to work on s */
|
| I don't know how common this sort of code is. To handle it
| properly, we will either need to hold on to the values in
| mxArray until the function exits then put them in an octave_value
| (my current strategy) or extend the array class so that we
| can give it an external pointer.
An even more common case (at least in my experience) is:
array = mxCreateNumericMatrix(0,0,mxDOUBLE_CLASS,mxREAL);
ptr = call_some_function_returning_a_ptr_to_data();
/* Do some stuff with ptr or not */
mxSetM(array,N); mxSetN(array,1);
mxSetPr(array,ptr);
By creating empty matrices you avoid matlab creating the memory. I
don't know if this was explicitly covered in your notes.
|
| A hybrid strategy may work. Use octave_value for everything
| but handle Pr,Pi and map keys specially.
I suppose we could aso modify Octave's struct class to keep track of a
numeric index if that makes implementing this feature any easier.
I also think it would be possible to modify the internals of Octave to
store real and imaginary data separately, but I'd like to avoid that
if possible.
Now that I have something checked in, I think the mex directory in
the main branch of the Octave Forge CVS can be removed. I did not
copy over the mex script or man page. Should we preserve that? Paul
has also pointed out that we may want to call it something else to
avoid clashing with Matlab's mex script for those users who have both
Matlab and Octave installed on the same system.
Also, declarations for the mxArray interface are in a file called
matrix.h (this is the name used by Matlab). This will cause trouble
on systems that have case-insensitive filesystems since we already
have a Matrix.h header file. Suggestions for what to do about this
problem are welcome.
Well, I usually don't include matrix.h explicitly, I just include
mex.h which will include matrix.h, so if users don't explicitly
include matrix.h the issue won't come up.
My next step will be to try to implement more of the interface and
convert the mxArray object to use octave_value.
Finally, my goal with the mex interface is to get something that
will work for at least some code written for Matlab. I don't expect
it to be perfect and efficiency is not my main goal. It's also kind of
painful to be doing this since the mx interface seems so low-level and
clunky compared to C++ objects which can easily be made to clean up
after themselves when they go out of scope (for example). I would
like to think that people will only use the MEX interface when
necessary, but realistically, I'd bet that people will start using it
instead of working directly with Octave objects because it's the way
Matlab works.
Comments or suggestions?
Well, I only briefly looked at octave internals (it's just not in my
job description :( ), but I got hung up for a while on creating
structures to return. Alas, I had little time, but perhaps better
documentation (which matlab seems to do really well) would ease that.
Thanks,
jwe