Python hits the spot

[Siegfried Gonzi]

Bengt Richter wrote:

> Have you never chased a bug that only shows up in secondary effects?
> In C code, the most common way for that to happen is storing something
> through a bad pointer, but instead of getting a memory fault, it corrupts
> some data structure or data value. The value could be used 20 minutes later
> and cause GPF then, or e.g., it could be data that's part of a calculation,
> but maybe it's only overwriting the least significant half of a floating
> point number, so you get the effect systematic bias or random error injected
> into your calculation, but nothing else. If you don't look for explanations
> of last-decimal errors, this kind of thing can persist a long time. OTOH,
> you could be corrupting numbers that are used in an iterative calculation
> that mysteriously starts to take longer to converge, and does so in a systematically
> increasing way, because the corrupting data varies systematically with time.
> Or you could be corrupting data structures and sabotaging memory management
> without causing immediate GPF, etc. etc.

The explanation is good and could explain the bad behavior. But note: I 
use the same C code on Windows and on Linux! On Windows I used SWIG and 
Visual C++. On Linux I used gcc and SWIG.

Theoretically I could do the following: trying to use the Fortran code 
instead of the C code. The C code relies on a Fortran 77 code. I pinched 
the C code from the netlib (or so). But I could try to use F2PY in 
combination with the Fortran 77 code.

The F2PY would have the advantage that I am not forced to write 
explicitely pointer-wrapper functions in Python in order to use the code 
which comes from SWIG.


The above could also explain why under Windows the system sucks down, 
but it is not destroyable!


S. Gonzi