= 27d567bc2d48d9f40e9ccc20ea370b15)
Luke_A_Somers comments on The dangers of zero and one - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (68)
Only make one mistake that makes it past testing.
That's what I meant, though I can see that it's not clear.
In this case a mistake would be writing the code, iterating and testing until you were satisfied, pronouncing it done, and then afterwards catching the error.
Hmm. I can definitely buy that a program of more complexity than this - less easily checked - would have that accuracy rate.
But prime checking is super simple to write and super simple to check. The only way you'd get an error through the obvious testing scheme given is to skip the testing.
You're taking 100 bits of testing (which contain around 80 bits of information if not produced by means of the actual pattern) and treating them as around 13 bits of reliability.
My experience with coding is that stupid obvious mistakes are way more likely than 1/10000. You write something slightly wrong, keep reading it as if it were right, and that's that.
Determining if a number is prime is a bit of a nice case, I suppose, because it's so amenable to testing. The structure of the mistakes you make is unlikely to match the structure of primes, so you'll catch any mistakes more easily.
I'd still consider doing it 10000 times to be extremely difficult. Just adding 10000 six-digit numbers by hand, even with some cross-checking, is quite difficult.
Yes, stupid coding mistakes are more like 1 in 2 than 1 in 10^4; it is the testing that helps here.