High Noon (1952) is a great movie. If you haven’t seen it, you ought to. It’s got a lot of very good stuff in it: Music, characterization, photography, editing, plot, and key grip electric work, but today I want to point out one particularly good bit of dialog.
One of the biggest differences between KenKen puzzles and Sudoku puzzles is that the former are harder to represent compactly. Sudoku puzzles can be represented as a simple string of numbers, but the 2-dimensional cages of KenKen puzzles seem to require a more vebose representation. Fortunately, such a representation needn’t be complicated.
Today I’m going to show the Constraint implementation for a KenKen solver I’m building. This code will cover all the rules of the KenKen game, and will shortly be used in a constraint propogation and search algorithm. It contains several inefficiencies, which will be dealt with later.
Following up on yesterday’s post, I’d like to get started on the construction of a solver for KenKen puzzles, using the same basic constraint-propogation-and-search approach that Norvig used in his Sudoku solver. I’m going to begin with a discussion of the role of constraints in the KenKen solver.
According to Slate, there’s a push afoot to popularize a Sudoku-like game named KenKen. Since it’s already been demonstrated that Sudoku falls easily to a little programming, I thought it would be interesting to (informally) compare and contrast the two games, with an eye to developing a solver for KenKen.
I was looking at Norvig’s Sudoku solver the other day, and suddenly understood a design choice that had previously struck me as bizarre. I think it’s a neat example of how small, seemingly arbitrary things can make your programming either easier or harder, depending on whether or not you get them right.
I am not a good skier. I can look ok on the majority of intermediate slopes, and make my way down diamonds. I’ve never been on a double-diamond in my life. I have a lot to learn. However, I have improved over the years (yes, years: I went a decade between trips to the mountains) and would like to share a few tips that would have made my life easier if I’d known them when I started.
Why, oh why, doesn’t anyone make Bear Treats? (These don’t count.) The box copy practically writes itself:
This is a follow-up to last week’s post, which discussed the fact that fully 30% of the 8086 processor’s 1-byte opcode space is given over to redundant opcodes (i.e. short forms of longer, more general opcodes). Today, I want to look, in a quick-and-dirty way, at how useful those opcodes might have been in practice. From at least one narrow perspective on a particular dataset, the vast majority of them seem to have been pretty worthless.
A useful little tidbit from a friend of a friend:
