- Up - | Next >> |
Many of you may have grown up, professionally speaking, on a diet of logic programming or on even more classical fare. As such, you have been encouraged to think about problems in a generative/constructive way. Constraint programming requires a completely different perspective. This is best illustrated with an analogy:
The traditional way is much like constructing objects with Lego: you put pieces together until you have achieved the desired shape.
The constraint programming way is rather like sculpting or carving: you take away what you don't want until only the desired shape remains.
In constraint programming, you state an ideal, then remove undesirable models from consideration by incremental strengthening of your judgement. You might look at it as computational philosophy... or not, if you happen to be a philosopher! This chapter illustrates the point quite clearly with dependency structures:
we do not assemble the dependency structure by constructively connecting nodes together
instead we state the ideal truth that characterizes what it means for a collection of nodes to be arranged in a dependency structure
then we remove from consideration all models that violate grammatical conditions such as agreement.
It is important not to fall in the generate and test trap. In order to take full advantage of constraint programming, you must model your problem in a way that takes maximal advantage of constraint propagation. In constraint programming, negative information plays an essential role: you first state a universal truth, and then indicate which parts of it are not true. In the end, as Sherlock Holmes might put it, ``what ever remains must be the case.''
- Up - | Next >> |