

A Genetic Programming Approach to Automated Software Repair.  - mrlebowski
http://www.cs.virginia.edu/~weimer/p/weimer-gecco2009-preprint.pdf

======
jacquesm
Very interesting stuff. I did notice that this bug was due to a broken test
procedure, a simple test loop during the initial write would have brought this
problem out instantly.

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.

~~~
scott_s
That's an excellent point - if you have a finite range, why not test all of
it? - and I know software testing researchers who look into just that. The
difficulty to keep in mind is that in a large code base, there are going to be
many small pieces that have a different finite range.

~~~
unignorant
You might try something like CUTE:

<http://osl.cs.uiuc.edu/~ksen/cute/>

------
mrlebowski
Westley Weimer has a presentation on the same @ Stanford University today at
2pm (1 hr from now) in Gates 104

Map -
[http://maps.google.com/maps?f=q&source=s_q&hl=en&...](http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Gates+104,+stanford&sll=37.0625,-95.677068&sspn=45.957536,93.076172&ie=UTF8&ll=37.430173,-122.172963&spn=0.001414,0.00284&t=h&z=19)

~~~
unignorant
He is at Berkeley tomorrow:

[http://events.berkeley.edu/index.php/calendar/sn/eecs.html?e...](http://events.berkeley.edu/index.php/calendar/sn/eecs.html?event_ID=22841)

Attend if you can!

------
extension
Don't get too excited, this requires unit tests to detect the bug. In other
words, if you already have a pretty good understanding of the bug, this thing
will evolve a fix for you instead of having to write it yourself.

If you can write an algorithm that _finds_ bugs, then you've really got
something.

~~~
wlievens
A bug is a defect. A defect is a deviation from the intended meaning of the
program. To automatically detect that, you will need a formal specification of
the meaning of the program.

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.

