3 ms·
Not totally silly. Just last Friday I was writing a Python hypothesis-based test using constrained-random stimulus generation. The target function under test
by dbcurtis 10y ago
Not totally silly. Just last Friday I was writing a Python hypothesis-based test using constrained-random stimulus generation. The target function under test is rather complicated because it is coded to be space and time efficient. It is not so easy to read and reason about, surprise, surprise. But there is a straight-forward, easy to ready, while-loops-and-simple-if's implementation that is slow and inefficient, but it's not too hard to convince yourself it produces the correct answer. So I use that in my test driver to generated expected results. It's certainly possible for both implementations to contain bugs, but extremely unlikely for them both to report the same wrong answer for the same stimulus.
- llimllib 10y agoHere's an example I wrote where I test the fast API against the (probably correct) brute-force version: https://github.com/llimllib/ckmeans/blob/master/ckmeans.py#L147 https://github.com/llimllib/ckmeans/blob/master/ckmeans.py#L...
- di4na 10y agoJust nitpicking about "extremely unlikely for them both to report the same wrong answer for the same stimulus". This assumption is what are "blind implementation voting systems" were based on, and it was proved to not survive that well in practice. It may totally work in your case, but you may be interested in looking at the work on Nancy Leveson at the MIT (all links are from her website) http://sunnyday.mit.edu/papers/nver-tse.pdf http://sunnyday.mit.edu/papers/nver-tse.pdf http://sunnyday.mit.edu/critics.pdf http://sunnyday.mit.edu/critics.pdf http://sunnyday.mit.edu/papers/nver2.pdf http://sunnyday.mit.edu/papers/nver2.pdf http://sunnyday.mit.edu/papers/consistent-comp.pdf http://sunnyday.mit.edu/papers/consistent-comp.pdf This body of work launched quite a controversy, but well, it is still here...