Is mxCopyPtrToInteger4() not compatible with Interleaved Complex API ?

Dear all,

I am trying modify the FORTRAN Mex Example dblmat.F and compute.F for use with complex data and with the Interleaved Complex API. I compiled with -R2018a.

In order to handle arrays with more than 2 dimensions, I tried to get the dimensions according to the example from the help with mxCopyPtrToIntegre4 and mxGetDimensions like here:

To copy the values to Fortran, use mxCopyPtrToInteger4 as follows:

C Get dimensions of mxArray, pm

mxCopyPtrToInteger4(mxGetDimensions(pm), dims,

+ mxGetNumberOfDimensions(pm))

But when I compile, I get the following error message:

'<...>/dblmat_z.mexa64' is compiled with incompatible options '-R2017b' and
-R2018a'. For more information, see MEX file compiled with incompatible options.

The error does not show up, when mxCopyPtrToInteger4() is not used.

So my question is: Can mxCopyPtrToInteger4() be used with the option R2018a for the Interleaved Complex API model ?

[James Tursa]

The error seems to be that you are using both the -R2017b and -R2018a options at the same time. What is the exact command line you are using to do the compile? Regarding mxCopyPtrToInteger4(), I can't think of any reason it would not work with -R2018a, but for your particular use the dimensions would have to be 4-byte integers, which they are not.

[Delta-Echo N.N.]

Regarding the compilation error, I must admit, that it disappeared after some reformatting - maybe I violated the 72-column-limit of these fixed-format files when writing the mx-function declarations on a quite long line.

And of course you have been right pointing out that on 64-bit systems the dimensions are also 64-bit integers, and therefore mxCopyPtrToInteger4() won't do the right job. Every second dimension came out to be zero. I replaced it with mxCopyPtrToInteger8(), and now I can read the dimensions.

Answer 1

[James Tursa]

See this post:

https://www.mathworks.com/matlabcentral/answers/93860-why-does-the-fortran-mex-api-function-mxcopyptrtointeger4-return-incorrect-results-on-64-bit-matlab?s_tid=answers_rc1-1_p1_MLT

[Delta-Echo N.N.]

Thank you very much for this hint - this fixed my try to get the dimensions out right (see my comment to your first answer above).

I especially appreciate your help, because the original goal of my experiments was to use your Fortran-95 API https://de.mathworks.com/matlabcentral/fileexchange/25934-fortran-95-interface-to-matlab-api-with-extras?s_tid=prof_contriblnk

for a Fortran-MEX-application and to avoid unnecessary copies of in- and output-arrays. Then I realized, that it is based on the separated-complex-API from before R2018a and I thought, if I could adapt the principles to the new API.

That's what I am trying to do now. The last thing I stumpled upon, and which caused some Matlab crashes, is that I had to learn, that complex(16) is not the same as complex*16 (I'm still new to Fortran and confused by old and new notations).

(e.g. https://stackoverflow.com/questions/32935743/why-change-complex16-to-complex16-cause-the-runtime-increased-unreasonabl/32935983)