Some balanced heterozygote superiority fitness trios caused exception

[mars0i]

It seems that when you give the program two sets of fitnesses and both represent balanced heterozygote superiority (even though to different degrees), the program fails with an exception.

[mars0i]

The problem only occurs with some configurations. e.g. N=200, start at freq 100. But not 100, 50; or 240, 120. (Maybe it's not only with symmetric het sup?)

[mars0i]

Example:

S.make_setchain_from_fitns ~fork:false 200 100 1 1 [{w11=0.9; w12=1.0; w22=0.9}; {w11=0.6; w12=1.0; w22=0.6}]

causes an exception in recombine at indexes i=100 (col in prev gen), j=0 (rows of old matrices), i.e. the first row considered at the initial frequency. In the hi_mult step, I think (check). And the problem is that sum_rest_plus_qi is supposed to get <= 1, and it stays just above it. 100 is also the exact midpoint of the frequencies.

This may be a float-slop problem. sum_rest_plus_qi starts out at almost 1.0: 1.00000000000000044..., and remains (not quite as, but very) close to 1.0.

But if that's the problem, I may have to be careful fixing it, because the crossovers are very subtle in some cases.

[mars0i]

I now believe that float-slop was the problem, and I've replaced the comparison functions to deal wit this. (Issue #11 is a continuation of those changes.)

1. The problem only occurs with some sizes and initial frequencies.
2. Examination of the state of data in recombine when the exception occurs in this example:

S.make_setchain_from_fitns ~fork:false 200 100 1 1 [{w11=0.9; w12=1.0; w22=0.9}; {w11=0.6; w12=1.0; w22=0.6}]

showed that the failure to find a crossover point at the first attempt to apply recombine at frequency 100 (i.e. after processing all of the earlier frequencies) was due to the fact that (a) all of the values in both the p and q vectors were very near 1.0, but the higher values were above 1.0 (which should never happen--these are maxes and mins of probabilities), but only by a very small amount. So what happened is that the sum never got <= 1.0, as it was supposed to. But it got very close to 1.0.

3. The generation 1 plot for the above example looks like a simple plot. It looks like there's only one curve. So it's plausible that the values are very close at some points--in this case at n=100--and calculating the values can mess things up due to float slop. (You can create other generation 1 plots with very close lines without getting the exception, though.)

I'm taking off the bug label, but leaving this issue open. I'd like to do additional checks in the future. Resolving issue #10 may help with that.