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

[Prabhu Ramachandran]

>>>>> "PP" == Pearu Peterson <pearu at cens.ioc.ee> writes:

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

I just checked out f2py2e from cvs.  I had goofed earlier.  I have a
local install of Python and also a global one (both the same version).
I accidentally installed f2py as root somewhere else.  It works
beautifully now.  There was just one hitch.  I had to link
cvs/f2py2e/scipy_distutils to cvs/scipy/scipy_distutils

Once I did that f2py2e installed just fine now it also builds
flaplace.so very nicely.

[Prabhu on transposing arrays ...]

    PP> I think that the intermediate steps are different (this shows
    PP> also in different error results). I just ignored transposing
    PP> stuff as the test problem is symmetric, right?. It's a mess
    PP> and a headache to deal with different array orderings, even if
    PP> you are fully aware about the issue.  Somekind of rules need
    PP> to be worked out, double-checked, and documented in order to
    PP> ease the pain ;) And I didn't care about bugs also as we are

Yes, that is what I was asking about.  I think we'll do this instead.
I'll work on a quick draft document -- "The newbie guide to
scipy.weave" or something.  I'll try to cover what I've done with the
test problem and try to illustrate numeric, weave, inline and f2py.
I'll let the experts correct it.  So maybe you can write a section on
array transposing and stuff.

    PP> studying the speed differences and here only the number of
    PP> operations are relevant - they should be same in all test
    PP> cases for different approaches so that the results will be
    PP> comparable. So, I think we should count operations, not bugs,
    PP> though it would be nice to get those fixed as well.

Of course, I wasnt saying that it was a bug.  Actually if you look at
my code the numeric version of timeStep will not re-use computed
variables.  In fact there is no way to do this in pure numeric.  Only
inline, weave, f2py and pure Python let you do this.  i.e. once u(i,j)
is computed the next (i or j) computation will re-use this latest
value.  Numeric uses temporaries so you cant do it.  So, I know that
the numeric results *will* be different from that of the rest.
However, I only wanted clarifications on f2py and what one must worry
about when one uses f2py.

Anyway, my question is u(i,j) as referred to in either Python (u[i,j])
or in blitz or f2py -- do they mean the same thing?  Or is it that
when I write a loop in fortran that uses a numeric array I must make
sure that u(i,j) == u[j,i] ??

I ask this because there is hope that someday inline fortran is
possible and it looks to me that inline fortran is just as easy (if
not easier) to write as inline c++.  Also, if we are sure of getting
more speed with easier to write/understand code, its worth while
writing the loops in fortran.  I'd really like to know what one should
watch out for when one writes fortran code that is used from Python.

Thanks,
prabhu