[SciPy-dev] Cython, f2py and GSoC

Dag Sverre Seljebotn dagss at student.matnat.uio.no
Fri Mar 27 10:51:21 EDT 2009


Sturla Molden wrote:
> On 3/26/2009 8:43 PM, Dag Sverre Seljebotn wrote:
>
>   
>> b) While there's a clear technical seperation between Fortran <-> C and 
>> C <-> Cython, the main challenge is the same both places (dealing with 
>> strided arrays on a C level) and so it's benefitial to have them within 
>> the same project.
>>     
>
> Do you need to pass strided arrays to Fortran? Would not a local copy 
> suffice?
>   
Thanks for the feedback. You know a lot more about this than me so I'm
very grateful for any input.

Is it necesarrily easier? There's two tools generating respectively C 
and Fortran code, and one of those tools need to emit the logic to do 
the copying, in either C or Fortran. Which one seems almost arbitrary.

(Note that with Cython one should be able to pass any Python object 
implementing PEP 3118 to Fortran as an array, so we can't use NumPy's 
copy function (and we shouldn't introduce a dependency on NumPy for 
this). But it's not much code either way.)

Some sort custom struct (or change of signature in some other way)
containing the bounds of the array are necesarry anyway.

But even if I think the work amount is the same, contiguous memory is a 
simpler concept and perhaps more robust to maintain etc. from a project 
management perspective. Hmm..

> Also consider that the Fortran 2003 function C_F_POINTER (used to 
> convert a C pointer to a Fortran array pointer) assumes the C pointer 
> references a continuous array. You would have to pass in the original 
> unstrided array, create one Fortran pointer with C_F_POINTER and then 
> index this with appropriate strides. Most likely the Fortran compiler 
> would react to these strides by making its own local copy, which would 
> make these efforts a bit futile. It is easier to always pass contiguous 
> arrays to Fortran, and in most cases just as efficient.
>   
Yes, that was exactly the plan. And if the dimension ordering is
different I suppose a copying reshape call is needed.

Since it seems doing the copying either side is about the same amount of
work, my idea was that copying in Fortran would have the advantage that
it moves the decision to the Fortran compiler,  which is smarter and
knows more. (That, and you say "most cases" and I'm too much of a 
perfectionist...)

Is it possible to write Fortran code in a way which doesn't make the
compiler copy, in case you know that memory use is a bigger problem than
speed? If so I'd say that settles the issue for my part, no point
"turning a feature off".

If not, we may very well heed your suggestion. (Ideally one should 
benchmark I suppose...)

Dag Sverre




More information about the SciPy-Dev mailing list