[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MEX interface
From: |
Joe Koski |
Subject: |
Re: MEX interface |
Date: |
Wed, 21 Jun 2006 19:55:44 -0600 |
User-agent: |
Microsoft-Entourage/11.2.3.060209 |
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