Portable declaration of REAL variables in mex gateway for Fortran
2 visualizaciones (últimos 30 días)
Mostrar comentarios más antiguos
(The same question is asked here: https://stackoverflow.com/questions/57244555/portable-declaration-of-real-variables-in-mex-gateway-for-fortran)
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.
- Is it true that mex supports only REAL*8 and REAL*4?
- Are REAL*8 and/or REAL*4 supported on all platforms? If no, does this mean that MATLAB mex is intrinsically unportable?
- What is the best way to specify the kind of floating-point variables in mex gateways for Fortran code?
- 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
C read input
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
0 comentarios
Respuestas (1)
James Tursa
el 29 de Jul. de 2019
Editada: James Tursa
el 29 de Jul. de 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.
3 comentarios
James Tursa
el 30 de Jul. de 2019
Editada: James Tursa
el 30 de Jul. de 2019
You would almost certianly be OK to use REAL(kind(0.0D0)) instead of REAL*8, REAL(kind(0.0)) instead of REAL*4, etc. in your mex code and you would be just fine. Go ahead and use the standard syntaxes if you want to and the interfaces to the mex API routines should still work correctly. If you ever run into a problem doing this I would sure like to hear about it. The only thing to be careful of, as mentioned in your other post, is if there are compiler settings in play that force a certain syntax to be other than what if would be under default settings. That can certainly mess things up.
Ver también
Categorías
Más información sobre Write C Functions Callable from MATLAB (MEX Files) en Help Center y File Exchange.
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!