[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: help with interleaved complex data in mex files
From: |
John W. Eaton |
Subject: |
Re: help with interleaved complex data in mex files |
Date: |
Tue, 11 Feb 2020 10:47:37 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 2/11/20 4:39 AM, Sébastien Villemot wrote:
First, I had to modify the source code to get it compiled under R2017b
API. One should test "#if MX_HAS_INTERLEAVED_COMPLEX" instead of "#if
defined(MX_HAS_INTERLEAVED_COMPLEX)", since the macro is defined in
both APIs. See the fixed source code attached.
OK, I didn't notice it was used this way and assumed it was either
defined or not. I've fixed things in Octave so that it should always be
defined to either 1 or 0.
I also attach the output of nm for both APIs (generated using MATLAB
R2019b, under Debian "Buster" 10 amd64).
Thanks.
I don't intend to try to match the exact versioned symbol names. We
aren't trying to provide binary compatibility.
I'm guessing that one of these symbols like mexfilerequiredapiversion is
used to know whether the mex file was built using the -R2017b or -R2018a
option. I had already decided to do something similar. So, in Octave,
I'm doing this:
* When compiling a mex file, the -R2017b/-R2018a option determines
which actual mxArray constructor functions to call. So if we are
compiling with -R2018a, we will create mxArray objects that have
interleaved complex values.
* If compiling with -R2018a, create, compile, and link a file that
adds a symbol to indicate that the mex file was compiled to expect
interleaved complex arrays. I suppose I could instead do this for all
mex files and make the value of the symbol contain the information
instead of just relying on the existence of the symbol itself. Maybe
that would be better as it would allow more flexibility.
* When calling a mex file, check to see whether it was built to
expect interleaved complex values. Mark the mxArray objects that are
passed to the mex function so that they will be translated from
octave_value objects to the proper representation as needed (mxArray
with interleaved vs. separate complex).
* On return from the mex file, translate the values back to
octave_value objects. We already do this part, but until now we only
had mxArray objects with separate real/imag arrays to represent complex
values.
Internally, Octave has always used interleaved complex arrays, so this
change in Matlab opens up the possibility for better performance for mex
functions in Octave as we should be able to do less work transforming
values from one representation to the other.
I hope to have a patch ready for testing sometime later this week.
jwe