Question about scientific calculations in Python

[Martin Kaufmann]

On 12 Mar 2002 19:25:50 GMT, Paul Hughett
<hughett at mercur.uphs.upenn.edu> wrote:

>You might want to take a look at bblimage, which is an extension to
>Python written in C; it emphasizes high performance, but the set of
>operations implemented so far is oriented toward medical image
>processing.  It supports pretty much all the basic operations (+,-, ...
>sin, cos, exp, etc) on n-dimensional images in the usual integral and
>floating point types (but not complex, alas; I haven't starting playing
>with FFTs yet).  The URL is
>
>         http://www.uphs.upenn.edu/bbl/bblimage

Thanks, I had a look at the webpage. It really looks interesting to
me. But the basic calculations really faster than the one in SciPy or
Scientific Python?

>It really depends on how many diffraction patterns you need to do.  It
>doesn't make sense to spent two months learning C to save even 99% of
>a ten-hour computation that you're going to do only once.  (Unless
>your real purpose is to learn C.)  On the other hand. if you have to
>do a few hundred patterns, then it might be a good investment of time.

I will have to do it several times I guess... So 99% improvement in
speed would really be nice.

>For what it's worth, my own experience is that (b) using C for the
>heavy lifting and Python to glue the pieces together can be very
>effective if you implement the right piece in the right language.  I'm
>using bblimage for registration and segmentation of hundreds of volume
>images at half an hour apiece.  The current code runs almost as fast
>as plain C (about 4 times faster than a competing C++ implementation
>not particularly optimized for speed) but the Python code that glues
>it all together is easier to modify and experiment with than a C++
>implementation would be.

How do you glue C and Python together? Do you use any of the wrappers
(SWIG, weave etc.) or do you do it the hard way? I just didn't
understand the whole story about these PyObjects.

>One general comment: The performance killer in many applications like
>this is doing the innermost loop in the interpreted language (Python,
>Matlab, etc).  If you can recast your algorithm as operations on
>arrays rather than individual numbers, and your language does the
>implicit loops over the elements efficiently, you typically get 10x or
>so improvements in speed.  

Do you mean the array calculation of NumPy?

Thanks,

Martin