Re: MEX interface

[Joe Koski]

on 6/21/06 7:18 PM, John W. Eaton at 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.
> 
> 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).
> 
> 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.
> | 
> | 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.
> 
> 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?
> 
> Thanks,
> 
> jwe


John, et al,

Strange. This morning I tried octave-2.1.73 with the octave-forge mex
approach on the LLNL SundialsTB download, with disastrous results. It was
just an experiment to see if I could do it, I have no urgent need for
Sundials, a differential equations solver.

The "build" didn't work with many, many "syntax errors." This was on my Mac,
still with the old OS X 10.3.9. The LLNL folks use a MATLAB script as a
replacement for a makefile to build SundialsTB.

You're probably already be doing it, but SundialsTB

  http://www.llnl.gov/casc/sundials/

would be a good test case for the new octave mex compiler.

On a positive note, I do have OS X 10.4 ordered for my Mac G5. I've been
hanging back because I had some consulting "deliverables" due, and if
Fortran, Octave or some home-built X11 applications had stopped working, I
would have been in big trouble. Now maybe I'll have some time to build
2.9.6, and give some better Mac-oriented feedback and testing.

Joe