Improve Hypothesis's ability to shrink sums

[DRMacIver]

This improves Hypothesis's ability to shrink examples which depend on the sum of two values.

The motivating example for this is the following:

import numpy as np
import hypothesis.strategies as st
import hypothesis.extra.numpy as nps
from hypothesis import given

int16s = nps.from_dtype(np.dtype('int16'))

bounded_lists = st.lists(int16s, max_size=1).filter(lambda x: sum(x) < 256)

problems = st.tuples(
    bounded_lists,
    bounded_lists,
    bounded_lists,
    bounded_lists,
    bounded_lists,
)

@given(problems)
def test_sum_does_not_overflow(p):
    assert sum([x for sub in p for x in sub], np.int16(0)) < 5 * 256

This fails because you can get an overflow if the sum is large and negative. The ideal minimum example for it in Hypothesis's ordering is ([], [], [], [-1], [-32768]), but previously we rarely found that.

This comes from the SmartCheck paper and I'm running some evaluations in part based on that paper and it annoyed me that Hypothesis didn't normalize example. This PR is part one of two in fixing that.

[Zac-HD]

Generally looks good to me, with a few minor comments. Merge at your own discretion 😄

(I also love the motivation for this change!)

[Zac-HD]

To fail with m=0, n=100, this must use < not <=

[DRMacIver]

Whoops, yes, thanks.

[Zac-HD]

I think this should be m >= 1, so that m can be driven all the way to 0, right? Also looks like putting the comparison before the call to trial might avoid trying to incorporate a bad buffer. (these probably cancel each other in practice but I'd find it easier to follow the other way)

[DRMacIver]

No, this is correct. We know m > 0. If m = 1 we want to run trial(0, n + 1) and then stop regardless of what it returns. I'll add a comment to clarify the logic.

[Zac-HD]

Aaah, right. That does make sense, but a comment would certainly be good!