I don't want to spend too much time on this, so I'll sum up a few things.
The major difference between computer science and chemical engineering as a system model is that chemical engineering has no real axioms. Consequently, you get some inconsistencies that have to be resolved that don't really show up in more formal systems like computer science. On the other hand, methods for dealing with unsolvable sets of equations by brute-forcing reducible algorithmic approximations is relevant, if against the sensibilities of computer science. Computer science problems reduce much more cleanly generally.
The set of facts IS the model, and you can change them at will and re-derive a model that represents a good generalized approximation of the facts. Very induction-like. Most of the equations in ChemE are experimentally derived and empirical anyway, and refactoring the model is always a real possibility e.g. if specs change or the quality of one of the equations used in the model turns out to be very poor and must be re-derived experimentally. But as I alluded to above, there are standard techniques for brute-forcing past obstacles that would blunt formal reduction but which do not substantially damage the final model. Since the facts are never certain, allowing a bit of noise/error into the model to get around a problem is considered acceptable.
The messy model isn't pretty, and you are pretty much guaranteed to have a little error built in, but it isn't brittle either (unlike formal software design methodologies) and easily adapts to changing facts. It can deal with things like inconsistent definitions. It certainly makes for pretty good rough drafts of software models that can be polished up later.
What I find interesting about this is that it is a mature methodology for doing something very analogous to algorithmic induction on finite systems, but with the interesting feature that it has established methods and algorithms for bypassing formal reduction roadblocks. Since predictive accuracy is very important, these methods have been through an evolutionary sieve for optimality.
It isn't the solution for every problem, but it is an excellent and proven tool for deriving system models that can not easily be formally described, and it seems to me to have a sound mathematical basis for being good at this. Not a particularly useful tool for every problem, but good for AGI in my opinion.
But to bring it all back to what originally brought this up in the first place, this type of reduction works best with an initial model that doesn't leave anything out. There is no silver bullet here, just a better way of solving some classes of design problem in my opinion.
j. andrew rogers
-------
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
