There’s No Such Thing As Certainty

Wouldn’t it be nice to know we’re created completely correct software that has no errors or mistakes whatsoever?  How about just one super simple function?  In that case, maybe we could do exhaustive testing and try every single possible combination of inputs – that would be fine, and maybe a good idea if the inputs are small enough to allow it.  And yet it’s all a case of some beautiful wishful thinking, to believe or hope that at least in principle we might be able to achieve absolute certainty of correctness through testing, or through proofs, or through something somehow.

Tests will tend to find errors, yet no matter how thorough, they obviously won’t prove the absence of all errors. There might be catastrophic bugs left in a program that’s undergone extensive testing.  Formal proofs seem like they might be a hope for gaining complete control and certainty, but a proof itself could contain an error. Even with automated verification tools for proofs, the tool used for verification could have a bug.

So sometimes we could do exhaustive testing, trying every single possible combination of inputs, and verifying each and every output result is correct.  Unfortunately, an obvious problem we’d still face is that the tests could have bugs. But even ignoring this, significant bugs could remain in tested code due to undefined behavior (in C and C++ and perhaps other languages).  When a program invokes undefined behavior, one possible result is that everything proceeds exactly as the author planned and hoped.  This is perhaps the worst of all possible testing outcomes, because weeks or months or years later, upon changing the compiler, or the hardware used for testing, or the time of day, or upon changing anything at all really, the executable could begin to fail.  Even for program code that invokes no undefined behavior at all, a bug in the compiler or a fault in the hardware might allow a test to pass when it should fail. I read an amusing story about a program created via machine learning that found the most optimal solution was to use a short circuit that existed due to a defect in the substrate of the development board.  The program worked perfectly on the defective board, and nowhere else.

The only recommendation in all this is to watch out for attempting perfection.  There’s better uses for our time!

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s