> Thanks for the help! As you mentioned, using scipy.special.erfc was a much
> better idea. Below is a copy of my program and the stack trace, showing a
> new error. It seems that the first auto correlation works, however the
> second fails.
At this point, the program is large enough that we need to apply
alternative techniques besides reading the entire program and trying
to keep it in our head at once. One approach that is often successful
is to check the _user functions_ in isolation, because they should be
separable and independently testable.
You've written a few functions in your program. In particular:
##################################################
def fit(x,a,b,c): ...
def E_o(x): ...
def E_rin(x): ...
def E_iin(x): ...
def E_(x): ...
def integrand(t,t_d): ...
def integrand(x,y): ... ## why is this being defined twice?!
def G(y): ...
def phi(x): ...
def M(x): ...
def E_out(x): ...
def integrand1(x,y): ...
def G1(y): ...
##################################################
A function-based perspective will ask the following questions:
1. What is the documented purpose of each of these functions?
2. What are the expected inputs and output types for each of
these functions?
3. Which of these functions have unit tests to spot-check their quality?
I can say for certain, without looking at any significant code, that
something is strange with regards to integrand. Your program has
defined this twice, and that's almost certainly not right.
The strategy here is to pinpoint where the problem is: we can't
possibly say that the whole program is broken, so we try to scope the
problem down to a manageable size.
You mention that the first auto-correlation is producing good results.
What functions are involved in the computation of the first
auto-correlation?
Another technique to try to scope is to look at the stack trace and
the involved functions. The stack trace says that the following
functions are involved at the point of the program breakage:
G1
quad
integrand1
E_out
E_
In particular, note the tail end of the stack trace:
> 7 def E_out(x):
> ----> 8 E_in_w = fft(E_(x))
It is on the call to:
fft(E_(x))
that things break with the IndexError. Note that fft() is provided by
the scipy library. For the purposes of debugging, let us assume that
all external third-party libraries are bug-free.
What does fft expect to receive as an argument? We can read the following:
http://docs.scipy.org/doc/scipy/reference/generated/scipy.fftpack.fft.html#scipy.fftpack.fft
Since fft is erroring out: there's only one possibility: E_(x) is not
providing a value that's appropriate to fft().
Why would it do that? Two possibilities:
1. E_ is buggy and needs investigation.
2. E_ is fine, but the inputted value of x is one that E_x is not
defined to handle.
And so we start the investigation by considering those two
possibilities. Start with #1.
Do you know if E_ is fine? What is it supposed to do? What is the
shape of its input? What is the shape of its output? Is its output
something that fft() is designed to handle?
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
