Fortran comparison Re: [SciPy-dev] scipy.weave versus simple C++.

[Pearu Peterson]

On Sun, 13 Jan 2002, Prabhu Ramachandran wrote:

> >>>>> "PP" == Pearu Peterson <pearu at cens.ioc.ee> writes:
> 
>     PP> 1) Build fortran wrapper: f2py -c flaplace.f -m flaplace #
>     PP> here you need f2py from CVS
> 
> I've been having a hard time getting my version of f2py (2.5.391) to
> do this but cant seem to get it right.  Does f2py 2.5.393 have this
> feature or is the CVS version absolutely necessary?

Yes, currently it is absolutely necessary. The corresponding code in
2.5.x is broken due to the recent fast changes in scipy_distutils.
In fact, you'll need also get scipy_distutils from its CVS then. After I
will check some things, I'll make a new snapshot available soon.

>     PP> As a result you'll get flaplace.so in the current directory.
> 
> Also what about the transposing of the arrays??  Eric was talking
> about transposing the array.  I quickly read some of your examples and
> internally you seem to do the necessary adjustments (swapping n and m)
> to get the right array, right?  If so, technically the result of your
> fortran code should be identical to the c++ version?  Please remember
> that the order of execution is important, i.e. the array must be
> accessed in the same sequence if not the intermediate step results
> will be different.  However, both versions will converge but I'm just
> curious about the intermediate steps too.

I think that the intermediate steps are different (this shows also in
different error results). I just ignored transposing stuff as the test 
problem is symmetric, right?. It's a mess and a headache to deal with
different array orderings, even if you are fully aware about the issue.
Somekind of rules need to be worked out, double-checked, and documented in
order to ease the pain ;)
And I didn't care about bugs also as we are studying the speed differences
and here only the number of operations are relevant - they should be
same in all test cases for different approaches so that the results will
be comparable. So, I think we should count operations, not bugs, though it
would be nice to get those fixed as well.

Pearu