![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Automated Reasoning Workshop
Aug. 17th, 2008 08:51 pmWhen I ran the Automated Reasoning Workshop in 2006 I swore never to do so again. So I'm not quite sure how I ended up running it this year as well. It was a lot less stressful this time round, but then this time round I persuaded Volker Sorge to take responsibility for the finances and frankly running a workshop is a lot more fun if you don't have to worry about money. Volker was, in fact, running a big jamboree Conferences in Computer Mathematics and we just free-loaded on that in various ways. Volker was quite stressed.
The ARW is a slightly funny beast. Typically it runs on five minute talks and long poster sessions which is quite unusual for Computer Science conferences and workshops, at least, which tend to prefer full papers.
It also generally has several panel sessions which had Volker and I scratching our heads to think up topics. In the end I decided on a "Representation Panel", invited some people on it and then let them refine the topic to "It is impossible to automatically generate good representations for automated reasoning problems." This generated a lot of good discussion - representation always does because it is fascinating the way some problems become incredibly easy once you look at them the right way. A typical example is the so-called "mutilated checkerboard" problem. Imagine a square sub-divided into smaller squares (like a chess/checkerboard), now remove two diagonally-opposite corners - can the resulting board be covered by dominos (i.e. rectangles that will cover two of the small squares)?. The answer is "no" and the problem is made easy if you colour the checkerboard with alternating black and white squares, observe a domino always covers one black square and one white square and then observe that two diagonally opposite corners are always the same colour. Therefore there must always be either more black or more white squares. The representational trick is colouring the checkboard, representing it as black and white squares. If you do that the solution is much easier to find than if you don't. Of course its very difficult to see how you could automatically perform such representational tricks.
We managed to link up with the "Doctoral Consortium" for the second panel so we titled it "What should make successful research in Automated Reasoning" and then asked Simon Colton to chair it confident in the knowledge he would seize the opportunity to tell us we were doing it all wrong and, indeed, "no one real wants to prove theorems" was not long in coming. There were some interesting other points too. In particular Ullrich Hustadt asked why we were so bad, in Automated Reasoning, in building useable enduring artefacts - i.e. automated reasoners which more than one person could use and which had a shelf-life longer than a couple of years*.
The posters and meal also went well and the proceedings contained all the abstracts** so all in all I was happy. At the last minute, Volker subsidised the workshop meal for our funded students (we offer travel awards to students presenting posters at the workshop) so I deduce that the finances were looking good as well.
* Having built a couple of automated reasoners which only I could use and which rapidly became unusable to anyone I have some opinions on this, one of which is "never build an experimental system using an experimental programming language".
** something that went unaccountably wrong in 2006.
The ARW is a slightly funny beast. Typically it runs on five minute talks and long poster sessions which is quite unusual for Computer Science conferences and workshops, at least, which tend to prefer full papers.
It also generally has several panel sessions which had Volker and I scratching our heads to think up topics. In the end I decided on a "Representation Panel", invited some people on it and then let them refine the topic to "It is impossible to automatically generate good representations for automated reasoning problems." This generated a lot of good discussion - representation always does because it is fascinating the way some problems become incredibly easy once you look at them the right way. A typical example is the so-called "mutilated checkerboard" problem. Imagine a square sub-divided into smaller squares (like a chess/checkerboard), now remove two diagonally-opposite corners - can the resulting board be covered by dominos (i.e. rectangles that will cover two of the small squares)?. The answer is "no" and the problem is made easy if you colour the checkerboard with alternating black and white squares, observe a domino always covers one black square and one white square and then observe that two diagonally opposite corners are always the same colour. Therefore there must always be either more black or more white squares. The representational trick is colouring the checkboard, representing it as black and white squares. If you do that the solution is much easier to find than if you don't. Of course its very difficult to see how you could automatically perform such representational tricks.
We managed to link up with the "Doctoral Consortium" for the second panel so we titled it "What should make successful research in Automated Reasoning" and then asked Simon Colton to chair it confident in the knowledge he would seize the opportunity to tell us we were doing it all wrong and, indeed, "no one real wants to prove theorems" was not long in coming. There were some interesting other points too. In particular Ullrich Hustadt asked why we were so bad, in Automated Reasoning, in building useable enduring artefacts - i.e. automated reasoners which more than one person could use and which had a shelf-life longer than a couple of years*.
The posters and meal also went well and the proceedings contained all the abstracts** so all in all I was happy. At the last minute, Volker subsidised the workshop meal for our funded students (we offer travel awards to students presenting posters at the workshop) so I deduce that the finances were looking good as well.
* Having built a couple of automated reasoners which only I could use and which rapidly became unusable to anyone I have some opinions on this, one of which is "never build an experimental system using an experimental programming language".
** something that went unaccountably wrong in 2006.
