You know that feeling you get when someone gives you advice that you don't care about at the time but turns out to be prophetic? I just had that experience...
Boxes
Even though my background includes a significant amount of experience with artificial intelligence algorithms, I rarely use AI systems in my day-to-day work. The reason has to do with repeatability and provability. The various types of neural networks are relatively easy to construct and train, but act as black-box systems. You know the input, you see the output, but you don't know how the system generated the output from the input. Moreover, if you train a neural network with different initial weights or a different order through the training set, then it will result in a different learned configuration.
While black-box AI systems may generate accurate results, the training process is NP-complete -- you don't know ahead of time how much training it will take or whether it can actually learn. Moreover, these systems can be very good at memorizing training sets. Don't over-train your black box unless you want it to memorize the training set and completely screw up on the testing set.
In contrast to neural networks, fuzzy logic and genetic algorithms are gray box systems. You kinda know how they work. Given the input, it generates output and you can see how it came up with the output decision. However, barring very simple fuzzy logic systems, you cannot really tell what the output will be until you run the input though the system. You can see how it made the decision, but not before running it.
Finally, there are white-box AI systems like Bayesian networks. You know the input, the output, and how it will make the decision. The only real problem here is configuring the system. Since you need to know the probabilities, you really only have two choices. You could compute the probabilities before hand, but this requires you to have enough data to statistically compute the probabilities and be able to characterize the various statistical factors. The other choice is to use a gray-box or black-box system to learn the probabilities, in which case the probabilities may not be provable or optimal.
Dusting Off
I recently had a need for "a solution", where "provable" and "deterministic" are not requirements. This is a perfect situation for using AI. I wrote my own AI library many years ago. Basically, I didn't like any of the existing systems (not flexible enough for my own needs) and it was easier to build my own than adapt around existing systems. However, it has been years since I used it and I only vaguely remember the configuration options.
A couple of things really surprised me. First, my AI library was written in 1990 and last maintained in 1996. (Last bug fix was in 1994.) I didn't even know if it would compile with the latest GCC. My first surprise was that it compiled cleanly with "gcc -Wall". It even passed its benchmark and regression tests.
As I gawked at the output, I thought, "This is great! I wish I remembered how it worked!" Then I looked at the source code... There are huge paragraphs that describe how every function works and how to use it. Completely documented. Even the variables have reasonable names: no "int i,j" or "float q[12]" or "double phi,theta". Instead the variables have names like 'CutoffThreshold' and 'float *weights; /* network weight matrix */'. The comments even cite books and pages as references.
Way Back When...
I had a professor back in college who drilled "style" into all of us. He had three basic rules that, if broken, would result in a zero on your homework.
- Always comment your code. If the code is more complex than a simple loop, then describe what it does.
- C permits 64-character variable names (well, it did back then). Variable names should be descriptive and not generic. Single letter variables (i, j, x, y) are only permitted for very short loops. Greek letters should never be used for variable names unless you are programming in Greece.
- Don't use features specific to a compiler or operating system. Stick with portable standards. If you must use something specific, encapsulate it so a replacement won't impact the rest of the code.
We obeyed because we wanted to pass the class. However, the lesson was never lost on me. I still "over-comment" my code.
I looked up my notes and found a great quote from the professor (from notes I took in 1988): "Always comment your code because you never know when you will refer to something you wrote 20 years earlier." Wow -- he even nailed the duration.
