Prev: solving 2 functions
Next: algebraic loop
From: Guilherme Rocha on 13 Aug 2010 14:05
"James Tursa" <aclassyguy_with_a_k_not_a_c(a)hotmail.com> wrote in message <i43tu5$e8k$1(a)fred.mathworks.com>...
> "Guilherme Rocha" <gvrocha(a)gmail.com> wrote in message <i43s44$hdh$1(a)fred.mathworks.com>...
> >
> > The problem is: the routine I will call from the gateway defines "real" and "integer" variables.
> > What do integer and real types correspond to in terms of integer*1, integer*2, ... and real*4, real*8, ... ?
> > Is there anyway to force integer types to be interpreted as integer*4?
> > Likewise, is there anyway to force real types to be interpreted as real*8?
> >
> > Alternatively, I could just replace all integer and real declarations by integer*4 and real*8 but Fortran is not exactly something I am familiar with so I'd like to keep tinkering with it to a minimum...
>
> The type "integer" in your Fortran is almost certainly an integer*4 type. This will probably be the case even if you are on a 64-bit system. So there will likely be no change required here.
>
> For the real type, it is almost certainly real*4. You can sometimes force these to be real*8 with a compiler switch (look at the compiler doc). That would be the preferred approach. If you manually change all the real to real*8 in the source code, you need to beware of a potential pitfall since any real constants in the program will remain real unless you explicitly convert them in your code. This can bite you, particularly if there are any such constants as part of an argument list to a function or subroutine. Unfortunately, Fortran will not do automatic type promotion of arguments like C and C++ do. If you are not familiar with Fortran then I would suggest avoiding this route if you can. How long is your Fortran code?
>
>
> James Tursa

Hi,

Thanks again for the message.

I did the brute force of converting the declared variables from integer to integer*4 and real to real*8.

For some inputs, I even get the third party routine (glasso) to work.
But this is a somewhat uninteresting case where the function essentially just had to send the input back as the output (long story).
I smuggled a mexPrintf inside the glasso subroutine to make sure it was being called.

For a more typical case, I get a freeze which I believe may be due to data type conflicts. Calls to mexprintf do not get a chance to output anything to the screen so I cannot even pinpoint the problem...

I am using gfortran to compile the fortran code.
The results from a call to gfortran --help did not seem to contain anything related to forcing data type conversions.
Any good buzzwords to search on how to make the switch via compiled?
Or should I try converting the matlab side of the equation to integer*4 and real*4 and give it a shot?

The code itself is not long (240 lines) but the possibility of adding bugs kind of defeats the purpose of reusing code, right?

Thanks again and please, do advice.

G.
From: James Tursa on 13 Aug 2010 14:31
"Guilherme Rocha" <gvrocha(a)gmail.com> wrote in message <i441gk$4kd$1(a)fred.mathworks.com>...
>
> The code itself is not long (240 lines) but the possibility of adding bugs kind of defeats the purpose of reusing code, right?

240 is not that long ... go ahead and post it so we can take a look at what you are dealing with.

James Tursa
From: Guilherme Rocha on 13 Aug 2010 17:33
I figured a way around that seems to be working...

On the gateway routine, I declared all integers as integers and fixed their values so I am sure there will be no mismatches on this variables.
Then I tried declaring the reals on the gateway function first as real*8 (froze) and then as real*4 (did not freeze).

The only inconvenient was in reading the inputs from matlab.
It seems that using mxCopyPtrToReal4 to move the inputs to real*4 variables was not working properly.
As a way around, I first read the real inputs on real*8 variables using mxCopyPtrToReal8 and then copy them to real*4 variables using an explicit call to real as detailed below.

Are there known issues in using mxCopyPtrToReal4 to read inputs from matlab?
If not, I will be preparing a simpler example early next week to figure out what went wrong, so I can perhaps avoid the whole explicit conversion dance.

I will probably use the same approach to check whether the integers are being interpreted as integer*4s or integer*8s.

I am still interested in knowing whether it is possible to force the gfortran compiler to switch variables declared as real as real*4 or real*8 for future reference.
If you can give me any leads on that, I would very much appreciate.

Thanks for all the help.

G.

DETAILS OF MY WAY AROUND mxCopyPtrToReal4:

real*4, DIMENSION(:,:), ALLOCATABLE :: real4_var
real*8, DIMENSION(:,:), ALLOCATABLE :: real8_var

mrows = mxGetM(prhs(1))
ncols = mxGetN(prhs(1))

var_ptr = mxGetPr(prhs(1))
allocate(real8_var(1:mrows, 1:ncols), stat=ok);
allocate(real4_var(1:mrows, 1:ncols), stat=ok);

call mxCopyPtrToReal8(ss_ptr,real8_ss,mysize)
do i = 1,p
do j = 1,p
real4_var(i,j) = real(real8_var(i,j));
end do
end do





"James Tursa" <aclassyguy_with_a_k_not_a_c(a)hotmail.com> wrote in message <i4431e$bcj$1(a)fred.mathworks.com>...
> "Guilherme Rocha" <gvrocha(a)gmail.com> wrote in message <i441gk$4kd$1(a)fred.mathworks.com>...
> >
> > The code itself is not long (240 lines) but the possibility of adding bugs kind of defeats the purpose of reusing code, right?
>
> 240 is not that long ... go ahead and post it so we can take a look at what you are dealing with.
>
> James Tursa
First  |  Prev  | 
Pages: 1 2
Prev: solving 2 functions
Next: algebraic loop