A Genetic Programming Approach to Automated Software Repair.
cs.virginia.edu
cs.virginia.edu
If your code has an integer range of several 10's of thousands of input possibilities and it costs you next to nothing to run it why not exhaustively test that function?
That way your confidence goes up tremendously, just a couple of edge cases vs the whole range, I know which one I'd pick.
The run output would simply be two columns of integers, very easy to scan for errors. (the output should be equal or monotonous increase from day by day, and should not hang...).
Of course that's after the fact, but there is really no routine so trivial that you can get away without really testing if it does what you intended.
http://events.berkeley.edu/index.php/calendar/sn/eecs.html?e...
Attend if you can!
If you can write an algorithm that finds bugs, then you've really got something.
It's the automated programming paradox. You can't automate programming because you have to tell the automaton what to program... which is called programming.