这个问题比我预料的要有趣。对我来说,最初的解决方案看起来太复杂了。我不相信复杂,所以我自己尝试了一种解决方法,这个方法更简单,而且很容易证明是正确的。我应该把比较放在小于或等于,而不是小于。在四处玩来比较两种速度后,我无意中,就只测试了两种情况,发现原来的解决方案有缺陷。我还发现,尽管我的解决方案——加上刚才提到的修正——比提议的解决方案慢。在
建议的解决方案在24个可能的案例中有5个失败。我让作者来纠正他的功能。我甚至都没试着确定他的错误发生在哪里。但是我提供了以下函数,用于测试。在
有一些工具可以测试代码覆盖率。这个问题和解决方案的有趣之处在于,完全测试解决方案的覆盖范围在粒度上需要小于行级别。在
在下面的代码中,将建议的函数传递给test_intersection。如果24个可能的案例中有一个失败,它将抛出一个异常。我的解决方案和在内部使用元组的修改都通过了24个。原来的解决方案中有5个失败了。在发布这篇文章之后,我意识到还有一些额外的案例可以添加。([3,4],[3,7]),([3,7],[3,7]),([4,7],[3,7]),以及行的“间隔”向后的变体。在def test_intersection (f):
assert not f ([1,2], [3,7])
assert f ([1,3], [3,7])
assert f ([1,4], [3,7])
assert f ([4,5], [3,7])
assert f ([4,8], [3,7])
assert f ([7,9], [3,7])
assert not f ([8,9], [3,7])
assert not f ([2,1], [3,7])
assert f ([3,1], [3,7])
assert f ([4,1], [3,7])
assert f ([5,4], [3,7])
assert f ([8,4], [3,7])
assert f ([9,7], [3,7])
assert not f ([9,8], [3,7])
assert not f ([1,2], [7,3])
assert f ([1,3], [7,3])
assert f ([1,4], [7,3])
assert f ([4,5], [7,3])
assert f ([4,8], [7,3])
assert f ([7,9], [7,3])
assert not f ([8,9], [7,3])
assert not f ([2,1], [7,3])
assert f ([3,1], [7,3])
assert f ([4,1], [7,3])
assert f ([5,4], [7,3])
assert f ([9,7], [7,3])
assert not f ([9,8], [7,3])