help with interleaved complex data in mex files

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

help with interleaved complex data in mex files

John W. Eaton
Administrator
I'm looking at fixing Octave's mex support to handle the new interleaved
complex data that was introduced in a recent version of Matlab.  Could
someone compile the attached function with

   mex -R2017b myfcn.c

and then run the nm utility on the resulting mex file and then do the
same with

   mex -R2018a myfcn.c

and send the results to me?  I guess you would need to do this with a
Linux version of Matlab to use nm and version 2018a or newer to use the
-R2018a option for the mex function.

This function is untested, so if there are errors, let me know and I'll
try to fix.

Thanks,

jwe

myfcn.c (698 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: help with interleaved complex data in mex files

Sébastien Villemot-2
Hi John,

Le lundi 10 février 2020 à 11:00 -0500, John W. Eaton a écrit :

> I'm looking at fixing Octave's mex support to handle the new interleaved
> complex data that was introduced in a recent version of Matlab.  Could
> someone compile the attached function with
>
>    mex -R2017b myfcn.c
>
> and then run the nm utility on the resulting mex file and then do the
> same with
>
>    mex -R2018a myfcn.c
>
> and send the results to me?  I guess you would need to do this with a
> Linux version of Matlab to use nm and version 2018a or newer to use the
> -R2018a option for the mex function.
>
> This function is untested, so if there are errors, let me know and I'll
> try to fix.
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.

I also attach the output of nm for both APIs (generated using MATLAB
R2019b, under Debian "Buster" 10 amd64).

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org


myfcn.c (715 bytes) Download Attachment
nm-R2017b.txt (1K) Download Attachment
nm-R2018a.txt (1K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: help with interleaved complex data in mex files

John W. Eaton
Administrator
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



Reply | Threaded
Open this post in threaded view
|

Re: help with interleaved complex data in mex files

chloros
In reply to this post by John W. Eaton
Hi,
move also the statement

plhs[0] = v;

out of the #if clause, otherwise running the code causes an assignment
error.

compiled under windows (R2018): mexfilerequiredapiversion is also
present and the changes between -R2018a and the old api are identical
to what Sebastien already has sent.

best regards

On Mon, 2020-02-10 at 11:00 -0500, John W. Eaton wrote:

> I'm looking at fixing Octave's mex support to handle the new
> interleaved
> complex data that was introduced in a recent version of
> Matlab.  Could
> someone compile the attached function with
>
>    mex -R2017b myfcn.c
>
> and then run the nm utility on the resulting mex file and then do
> the
> same with
>
>    mex -R2018a myfcn.c
>
> and send the results to me?  I guess you would need to do this with
> a
> Linux version of Matlab to use nm and version 2018a or newer to use
> the
> -R2018a option for the mex function.
>
> This function is untested, so if there are errors, let me know and
> I'll
> try to fix.
>
> Thanks,
>
> jwe

myfcn.c (988 bytes) Download Attachment