Hi Todd, On 10 Oct 2003, Todd Miller wrote:
I'm trying to make a doctest to verify that the different flow patterns of f2py interfaces work with different varieties of numarrays (normal, byte-swapped, misaligned, dis-contiguous, type-converted). I'm trying to test this out under Linux with g77, and (it seems like) I'm having trouble synchronizing the Fortran I/O with Python's C I/O.
Given foo.f:
subroutine in_c(a,m,n) real*8 a(n,m) Cf2py intent(in,c) a Cf2py depend(a) :: n=shape(a,0), m=shape(a,1) do j=1,m do i=1,n write (6,1) a(i,j) 1 format( $, 1F3.0, ', ') enddo print *,'' enddo end
And given f2py_tests.py:
"""
foo.in_f(a) <snip>
I could not run given tests as they were not complete and had typos. For instance, foo.f defines in_c but in test string you are using in_f. Also AFAIK, Python I/O will not catch I/O from Fortran. Any way, when I modify in_c to in_f then the following code a = numarray.arange(15., shape=(3,5)) print a foo.in_f(a) outputs: [[ 0. 1. 2. 3. 4.] [ 5. 6. 7. 8. 9.] [ 10. 11. 12. 13. 14.]] 0., 1., 2., 3., 4., 5., 6., 7., 8., 9., 10., 11., 12., 13., 14., You probaly would not expect this. This is related to different storage order in C and Fortran, of cource, and you have disabled f2py ability to take into account this by using intent(c). So, when you would not use intent(c), that is, in foo.f is a line Cf2py intent(in) a then the following output occurs: [[ 0. 1. 2. 3. 4.] [ 5. 6. 7. 8. 9.] [ 10. 11. 12. 13. 14.]] 0., 5., 10., 1., 6., 11., 2., 7., 12., 3., 8., 13., 4., 9., 14., The arrays look transposed because in Fortran your row index varies faster, that is, a transposed array is displayed. To sum up, don't use intent(c) and change the order of loops in in_f function to get matching results. HTH, Pearu