About our new dishwasher…<\/p>\n
A couple of years ago I taught a course called ‘Introduction to Artificial Intelligence Programming’ \u2014 largely because I was available when no-one else was. It turned out to be great fun, and not least because I’d been through the same course one year as a student, and another as a Teaching Assistant, and could finally teach it the way I wanted to.<\/p>\n
The course had been moving towards trendy-but-hardly-AI stuff like Java, so I was happy to yank it back to the delights of Prolog, and basic AI techniques like state-space search.<\/p>\n
Prolog is a fantastic way to approach programming, for various reasons. You can’t help but learn about logic too \u2014 you’re basically programming with a subset of first-order predicate logic. You absolutely can’t hack it, the way that you can with most procedural languages. If you’re not exactly sure what a piece of code you’ve written means, it’ll bite back, hard. It’s a perverse joy to see students go through the Three Stages of Prolog. The First Stage is: ‘Bah. This is just a toy. It couldn’t possibly be actually useful for anything.’ The Second Stage is: ‘SHIT. This suddenly got hard and I don’t understand it any more.’ (The Second Stage only really exists because of the First Stage, which gives them a lethally false sense of security.) The Third Stage, which most (but not all) reach, is: ‘Oh, I<\/em> get it.’ That light-bulb moment is wonderful to see, when it happens. It’ll never be unclear to them again.<\/p>\n Prolog is to AI programming as Latin is to natural language. You don’t just learn the language \u2014 indeed, in some ways that’s the least thing that you learn. Latin teaches you about language itself. Prolog teaches you about AI: formal logics, knowledge representation and inference, search strategies.<\/p>\n Anyway, about our new dishwasher…<\/p>\n One of the small-but-important rules of thumb that I tried to teach the students on the course was not to define some predicate in terms of the conditions under which it isn’t<\/em> true. A Prolog clause might look like this:<\/p>\n \nmortal(X) :- man(X).\n<\/p><\/blockquote>\n \u2014 which says that some property, ‘mortal’, is true of some thing, ‘X’, if some other property, ‘man’, is also true of that thing. ‘Every man is mortal’, in other words. And that’s fine. On the other hand:<\/p>\n \nnot_immortal(X) :- man(X).\n<\/p><\/blockquote>\n Logically, this is completely equivalent, since (one assumes):<\/p>\n \nnot_immortal(X) :- mortal(X).\n<\/p><\/blockquote>\n But clarity, which is every bit as important as logical soundness, goes flying out of the window. Consider how we might define ‘immortal’ using our original definition of ‘mortal’:<\/p>\n \nimmortal(X) :- \\+ mortal(X).\n<\/p><\/blockquote>\n The \\+ symbol is the typical Prolog symbol to represent a logical ‘not’, so this reads: ‘Something is immortal if it isn’t mortal’ (assuming a closed world), and that’s clear enough. Consider now how we’d define ‘immortal’ using our second definition of mortality:<\/p>\n \nimmortal(X) :- \\+ not_immortal(X).\n<\/p><\/blockquote>\n That’s: ‘Something is immortal if it isn’t not immortal’, and it’s entirely boneheaded. We’ve defined mortality in terms of the absence<\/em> of immortality. Start sprinkling such double-negatives in Prolog \u2014 as in any representational system \u2014 and you’re very quickly lost. The mistake is right at the beginning, where we defined ‘not_immortal’. It has no place in logic programming.<\/p>\n Anyway, about our new dishwasher…<\/p>\n Apart from the program settings on our new portable dishwasher, there are two ‘options’ settings. The first, when selected, causes the dishwasher to increase the water temperature to 140 degrees before it begins to clean. It’s labelled: ‘Water Heat’. The second option is labelled:<\/p>\n \nNo Heat Dry\n<\/p><\/blockquote>\n