Re: help with interleaved complex data in mex files

[John W. Eaton]

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