"PP" == Pearu Peterson <pearu@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