# [Tutor] Fitting data to error function

Danny Yoo dyoo at hashcollision.org
Mon Mar 16 03:48:21 CET 2015

```> 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
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