Constraints Revisited

In search problems, you often have a great many potential solutions in your space that never need visiting. Many of these solutions are obviously contradictory, and can be discarded early. By applying constraints and enforcing consistency of constraints on your solution space, you can prune off contradictory solutions before starting your search. Thus, can many problems with exponentially large numbers of potential solutions be reduced to much smaller, much more tractable problems of fewer solutions.
There. I said it.

Update: My constraint library is going well. I think it is approaching actual usefulness. Yesterday I fixed my domains so that they can contain arbitrary disjoint ranges of values; like unions of a bunch of different intervals. Today I'm implementing iterative depth first search, and the corresponding tests, as well as a couple new constraints like allDiff and notEq. Using operator overloading in Scala, constraint problems look like this:

val a = problem.newVar
val b = problem.newVar
a + b := 20
a - b := 10
problem.solve

and then you inspect the resulting values of 'a' and 'b' to find out what the solution is. Right now, since I don't have the search implemented and can only propagate constraints upto arc-consistency, problems like the above don't return a definite answer, just a range. But other problems that aren't so tricky do generate definite answers, and in any case, the current implementation correctly narrows the potential solutions for 'a' to "10 < x < 20" and for 'b' to "0 < x < 10". Since the naive alternative is an infinity of integers, you can undoubtedly see the utility.

Other Interesting Things:
I used TDD to begin the project, and I'm pleasantly surprised. It seems almost the natural way of doing it: stubbing out your project with client code (in test form) gets the ball rolling and the mental wheels turning. If you don't know where to start, pretend you already finished and write some tests to make certain you did a good job. They fail, you fix. No more staring at a blank page.
And unit tests are life! I think I would die if I had to do a project without them. I'm starting to find that the more unit tests I add, the better I feel. It's like a drug. Write the test, fix the bug, refactor rinse repeat. Soon I'll be one of those guys who has to have 100 percent code coverage. Nathan Hungry. Nathan Want Code Coverage.

Manic Programming

Originally this post was going to be about Constraint Programming; but I've discovered, as I've attempted to write about it, that Constraint Programming is too technical. I just don't understand it well enough to explain it properly. There is, out there, a concise and correct explanation of Constraint Programming; I just can't produce it. So I'll talk about something else: something that is not technical, but totally subjective and therefore not bound by correctness or accuracy. I turn to my own topic: Manic Programming by Nathan.
Manic Programming is the phrase I've coined for myself to describe my own tendency to do a lot of different things without getting anything in particular done. I do a lot of hobby projects, and they all seem to have a characteristic short lifespan: they go on for awhile, and then I find a branch point somewhere and speed off on a tangent. I've heard this tendency described as "shaving the yack": to get lost in the depths of some portion of a problem. In my own case there remains so much I don't know (and may never know) about the computer field, that my curiosity gets the best of me and in lieu of finishing the project I'm working on, I invariably go off and try something else.
Now I'm not sure that there is anything wrong with not finishing hobby projects; they are, after all, just hobby projects. No one is paying me to do them. However, it would be nice to be like a photographer or an artist, and have a ready made pile of projects to show off to interested individuals. Instead I have a heap of partial works which can be enjoyed only by me.
So what is it that prevents me from finishing projects? I don't really know, but I can observe this general thing: that projects get boring. Part of it is that you become familiar with the concepts that spawned the project in the first place, and curiosity therefore dwindles. Another part of it is that finishing is tedious. In the Mythical Man Month, somewhere there's a graph which shows that the ratio of difficulty between a product and a do-it-for-yourself project is 9 to 1 which I think is basically true. Finishing really is hard. Polishing really is tedious, and in most cases it's just more fun to leave it and do something else.
And in defense of myself I'm not sure that Manic Programming is a bad thing! I do cover a lot of ground with my many orphan projects. It is my breadth first search of the knowledge tree. I do like to learn, but all at once and not one at a time. It probably hurts my marketability that I do not emphasize one particular thing, and people can't say "that guy, he is good at X". No I'm not good at X, but I'm mildly familiar with Y and Z.
I have neglected this blog for awhile, mostly because my enthusiasm ran out and I moved on to other things (the mania strikes again). However, I feel the need now to resume. Notice: perhaps the one thing that saves me from the mania, is my tendency to revisit old discarded projects and apply to them new methods. And behold, I revisit this blog after a period of neglect! And what new methods will I apply here? I wonder. Perhaps some code samples? A bit of technical jargon? Some inaccurate technical expositions on NP-Completeness? Stay tuned to find out.