I’ve finally gotten the Sudokit code together enough to make it available. You can download the zipped source and an executable jar file. The app and the code are both still ugly, but I’ve added a text entry field to make it halfway usable.
There is no documentation. The app is just an experimental solver, trying to mimic human solving techniques and providing a rating for a puzzle’s difficultly. Several puzzles are included to pick from or you can enter your own. The solver has some advanced techniques, and while there are some test puzzles in the “database” that it can’t solve, all newpaper-level puzzles can be solved with only the simplest techniques.
That was the thesis from my original investigation: that if applied methodically, only simple techniques are required to solve newspaper-level problems. The simple techniques being hidden single and naked single. Knowing that, I thought I would test the thesis on a “hard” puzzle from a recent Saturday paper. I couldn’t solve it by hand with the simple methods and had to use some of the subset-based techniques.
Wanting to try that puzzle with Sudokit was enough to get me to add the text entry field (and the log panel at the bottom). Sure enough Sudokit was able to solve it with just the simple techniques. Either I wasn’t methodical enough or Sudokit’s logic is implicitly using more advanced techniques.
I’ve put together a release of the JDBC Providers at berlios. This packages up recent bug fixes and the separation of Java and SQL code which makes it easier to support other DB vendors.
Meanwhile SÃ¸ren and Mikkel are working on a branch to futher separate the DB by using JNDI so we can rely on the servlet container to maintain the DB connections.
I finished the last of the mathschallenge.net math programming problems. Actually, it’s a temporary milestone since new problems are added every few weeks. At right is a graph of problems started per day with a LOESS smoother applied. The data are from the creation date of the program files, and the few problems that I solved without coding are not represented.
A lot of the problems involved combinatorical counting, so it helped that I had just been reading the excellent lecture notes from MIT’s Mathematics for Computer Science course.
SÃ¸ren Berg Glasius has created a JDBC Providers project on BerliOS, which is something like SourceForge. We’re working on making it easier to run the providers on different databases. It already supported MySQL, and he’s adding Sybase. The idea is to put all the SQL code in an external properties file. There is still some code/DB dependencies, which I’m not sure how to get rid of, such as a dependence on the rough DB schema.
The WikiPageProvider interface for JSPWiki has changed again with version 2.3.72, so I’ve updated the JDBC providers which I sort of maintain. 2.3.72 is still in alpha, and I’m not familiar with the new authentication features, which may be limiting my testing. For instance, there’s now a call to move a page in the API, but I haven’t figured out how it’s surfaced on a wiki.
I’ve updated the article on the range check elimination optimization in Java. I added a case that provided a hint to the JIT which helps when the index is otherwise too complex for the JIT to realize that the range check can be eliminated.
I’ve started an article of my investigations into the range check elimination optimization in Java. The optimization aims to reduce unnecessary array subscript index checking, but I haven’t found many details on when the JIT compiler will apply the optimization, and how much time it saves anyway. So far, my investigation explores simple cases, but at least it finds situations where the optimization is applied (index is loop counter) and situations where it isn’t applied (index is computed).