# Portable declaration of REAL variables in mex gateway for Fortran

4 views (last 30 days)
Zaikun Zhang on 29 Jul 2019
Commented: Zaikun Zhang on 30 Jul 2019
I am writing a mex gateway for a piece of Fortran code.
In the Fortran code, for portability, the floating-point variables are declared as
REAL(kind(0.0D0)) :: x, y, etc
(BTW, I am aware that there are better ways to do it, as discussed at
https://stackoverflow.com/questions/3170239/fortran-integer4-vs-integer4-vs-integerkind-4,
https://stackoverflow.com/questions/10520819/what-does-real8-mean?noredirect=1&lq=1, and
https://software.intel.com/en-us/blogs/2017/03/27/doctor-fortran-in-it-takes-all-kinds )
However, it seems to me that mex supports only REAL*8 and REAL*4, the former being Double, the latter being Single. I got this impression from the following functions/subroutines:
mxIsDouble, mxIsSingle, mxCopyPtrToReal8, mxCopyReal8ToPtr, mxCopyPtrToReal4, mxCopyReal4ToPtr
My questions are as follows.
1. Is it true that mex supports only REAL*8 and REAL*4?
2. Are REAL*8 and/or REAL*4 supported on all platforms? If no, does this mean that MATLAB mex is intrinsically unportable?
3. What is the best way to specify the kind of floating-point variables in mex gateways for Fortran code?
4. Does it improve the portability of the mex gateway if I declare double-precision floating-point variables as
REAL(kind(0.0D0)) :: x, y, etc
or even
integer, parameter :: dp = selected_real_kind(15, 307)
real(kind=dp) :: x, y, etc
Or should I simply declare
REAL*8 :: x, y, etc
Thank you very much!
The following code is an example. See the declaration of x, y, and xs.
#include "fintrf.h"
subroutine mexFunction(nlhs, plhs, nrhs, prhs)
C y = square (x)
C x: a floating point scalar
C y: x^2
implicit none
C mexFunction arguments
integer, intent(in) :: nlhs, nrhs
mwPointer, intent(in) :: prhs(nrhs)
mwPointer, intent(inout) :: plhs(nlhs)
C function declarations:
mwPointer, external :: mxCreateDoubleScalar, mxGetPr
mwSize, external :: mxGetM, mxGetN
integer*4, external :: mxIsDouble, mxIsSingle
C variables
mwSize, parameter :: mwOne = 1
integer, parameter :: dKind = kind(0.0D0)
integer, parameter :: sKind = kind(0.0)
real(kind=dKind) :: x, y ! Does this improve the portablity?
real(kind=sKind) :: xs ! Does this improve the portablity?
C validate number of arguments
if (nrhs .ne. 1) then
call mexErrMsgIdAndTxt ('mex:nInput', '1 input required.')
endif
if (nlhs .gt. 1) then
call mexErrMsgIdAndTxt ('mex:nOutput', 'At most 1 output.')
endif
C validate input
if (mxIsDouble(prhs(1)) .ne. 1 .and. mxIsSingle(prhs(1)) .ne. 1)
! What if the input is a floating point number but neither Double nor Single?
+ then
call mexErrMsgIdAndTxt ('mex:Input', 'Input a real number.')
endif
if (mxGetM(prhs(1)) .ne. 1 .or. mxGetN(prhs(1)) .ne. 1) then
call mexErrMsgIdAndTxt ('mex:Input', 'Input a scalar.')
endif
if (mxIsDouble(prhs(1)) .eq. 1) then
call mxCopyPtrToReal8(mxGetPr(prhs(1)), x, mwOne)
else
call mxCopyPtrToReal4(mxGetPr(prhs(1)), xs, mwOne)
x = real(xs, dKind)
! What if the input is a floating point number but neither REAL*8 nor REAL*4
endif
C do the calculation
y = x**2
C write output
plhs(1) = mxCreateDoubleScalar(y)
return
end subroutine mexFunction

James Tursa on 29 Jul 2019
Edited: James Tursa on 29 Jul 2019
The REAL(kind(0.0D0)) vs REAL*8 discussion (and INTEGER*4 vs INTEGER etc) is a compiler issue, not a mex issue. As long as your compiler understands it, mex will be fine with it. For the systems you are working on, REAL(kind(0.0D0)) and REAL*8 are almost certainly different syntaxes for the same thing. Discussions about which syntax should be used are best left to another forum. MATLAB uses REAL*8 in its documentation, but you can use REAL(kind(0.0D0)) and be just fine.
Zaikun Zhang on 30 Jul 2019
I agree. I will use REAL(kind(0.0D0)) instead of REAL*8, REAL(kind(0.0)) instead of REAL*4. For INTEGER*4, I will write SELECTED_INT_KIND(8), which works well (i.e, lead to 32bit INTEGER) with both -compatibleArrayDims and -largeArrayDims. I will surely come back to inform you if these settings cause problems. Many thanks again!

R2016a

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!