One idea proposed by Minsky at that conference is something I disagree with
pretty radically. He says that until we understand human-level
intelligence, we should make our theories of mind as complex as possible,
rather than simplifying them -- for fear of leaving something out! This
reminds me of some of the mistakes we made at Webmind Inc. Contra Minsky
and Webmind, in Novamente I've sought to create the simplest possible design
that accounts for all the diverse phenomena of mind on an emergent level.
Minsky is really trying to jam every aspect of the mind into his design on
the explicit level.
It is hard for me to tell if you are actually disagreeing with Minsky here. I agree that one should throw absolutely everything into the mix when building a solution, but probably for different reasons than Minsky has.
Chemical engineering has an interesting problem space that is fairly unique in its structure, and consequently developed general problem solving algorithms that I still find to be very unique and at the same time enormously useful in theoretical computer science. For whatever reason, these algorithms and techniques just don't seem to all that familiar to most people in practice, which may be part of why chemical engineering is perceived as being such a difficult discipline to learn. A major component of what chemical engineering is about is taking arbitrarily complex systems (a mixture of chemical, thermal, and mechanical), with the assumption of inconsistent and incomplete information, and then solving, reducing, transforming, and modeling said system to a quasi-deterministic system that you can run more conventional calculations on with some degree of predictive accuracy. This is very frequently an obscenely complex optimization problem because no tidy mathematical solution exists, often but not always a consequence of the facts about the nature of the system being inconsistent, incomplete, or not quite correct.
As a chemical engineering student, you are taught to take absolutely every fact, equation, and expected result you can think of or discover before starting with the reduction to quasi-determinism. As a heuristic, the more information and weird edge cases you put into the system, the better the predictive quality of the final product. Now, a lot of people get the impression that this leads to information overload, but there are established algorithms and techniques to systematically reduce all this complexity and one finds with experience that by throwing *more* stuff into the pile, it is to actually easier to build a good model and makes resolving inconsistencies and uncertainties to reasonable or adequate values easier. More information tends to produce superior models via induction.
From this perspective, one cannot build an accurate "simple" model unless one starts with a very complex model that includes everything remotely related to the system in question no matter how irrelevant seeming. As often happens in chemical engineering systems, the exclusion of equations and facts to make a simpler initial model very frequently reduces the quality and accuracy of the simplified model. Furthermore, there is no theoretical justification for exclusion because that is predicated on having a good model of the system in the first place. Yet virtually every approach to AGI design (and much software design in general) is based on starting with a simple model and building upward to a "correct" model, or starting with complexity and not even bothering to properly reduce it, very questionable methods for solving non-toy system models that contain uncertainties or are incomplete. A problem with this is that you usually end up at a different "correct" solution working from the simple model upward than if you start with a complex model and work downward, and the downward model will almost always be more accurate if developed by someone accustomed to working that way. Unfortunately, system reduction and modeling algorithms and heuristics of the kind used in chemical engineering do not seem to be taught in computer science even though they have always been eminently relevant as far as I could tell.
My perspective of AGI and theoretical computer science in general has long been influenced by my history with chemical engineering and I have found it immensely useful for tackling very tough design space problems in computer science (and not just AGI), especially since computer science tends to be more consistent than chemical engineering as a general rule. It is something of a truism that half of chemical engineers end up working in computer science, probably because many design problems in computer science look like really clean versions of chemical engineering system problems. My model of AGI now is clean and elegant, but I started by throwing everything and the kitchen sink into the original pile and systematically reducing that to a deterministic system model a la chemical engineering. If I forgot something important, I just had to re-model the system and account for the diffs in the solution, a fairly mechanical exercise that didn't really require me throwing things away.
So yes, I think starting with the most complex model possible is a superior method, given that one has system reduction skills. AGI is a dirty enough theoretical system space currently that I don't see how a good solution can be arrived at any other way; it would not really be possible with any other kind of system and I don't see why AGI would be an exception. I'm sure people will disagree though. Computer science and chemical engineering both deal with the same kinds of systems, yet they developed very different methodologies for modeling them, primarily because computer science assumes a kind of logical perfection in the assumptions of a system and chemical engineering assumes dirty and imperfect information.
cheers,
j. andrew rogers
-------
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
