[Numpy-discussion] Re: [SciPy-user] doctest fortran I/O synchronization
Pearu Peterson
pearu at scipy.org
Fri Oct 10 07:54:07 EDT 2003
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
More information about the NumPy-Discussion
mailing list