Ben:
> I don't want to give a formal definition in the context of this email
> discussion...
>
> The informal notion is "a piece of procedural knowledge is something
> that can directly be used to generate a series of actions".
>
> Here "directly" should be interpreted to mean "with low computational cost."
>
> The actions may be motor actions, cognitive actions, or whatever.
> [...]
> discussion...
>
> The informal notion is "a piece of procedural knowledge is something
> that can directly be used to generate a series of actions".
>
> Here "directly" should be interpreted to mean "with low computational cost."
>
> The actions may be motor actions, cognitive actions, or whatever.
> [...]
>
> Motor knowledge is one kind of procedural knowledge
>
> Another kind, for instance, is how to control an inference trajectory
> carried out by a logical reasoning module, to effectively produce
> correct conclusions in a given context
> [...]
>
> Another kind, for instance, is how to control an inference trajectory
> carried out by a logical reasoning module, to effectively produce
> correct conclusions in a given context
> [...]
>
> The problem is that in practice the task of turning this declarative
> knowledge into actions can be too computationally expensive. (And I'm
> talking about algorithmic cost here, of course, not just
> programming-language or OS-related overhead.)
>
> In Novamente we have a process called "predicate schematization" whose
> purpose is to take **knowledge about procedure** that is expressed in
> logical, declarative form, and turn it into **procedural knowledge**
> that is expressed in the form of executable Combo programs.
>
> Predicate schematization is sometimes very fast, but sometimes is more
> complex and may require tricky inferences.
> [...]
> knowledge into actions can be too computationally expensive. (And I'm
> talking about algorithmic cost here, of course, not just
> programming-language or OS-related overhead.)
>
> In Novamente we have a process called "predicate schematization" whose
> purpose is to take **knowledge about procedure** that is expressed in
> logical, declarative form, and turn it into **procedural knowledge**
> that is expressed in the form of executable Combo programs.
>
> Predicate schematization is sometimes very fast, but sometimes is more
> complex and may require tricky inferences.
> [...]
>
> "Eggs should be boiled for eating" is an example of a case where
> predicate schematization may effectively be performed on the fly...
>
> On the other hand, addition is an example of a case where predicate
> schematization needs to be done once and for all, resulting in an
> "add" procedure being pre-compiled and ready for execution.
>
> Only amateur human adders need to use logical reasoning to add. The
> rest of us use an algorithm that was produced during a learning period
> and is now well-reified and can be applied without any logical
> reasoning. You can see small children go through this transition when
> they learn to add.
>
> In the actual software structure, nodes are identified by Handle
> objects, and if there is a Procedure object associated with a node,
> the Procedure is stored in a ProcedureRepository table indexed by the
> node's Handle.
>
> > This destroys the nice uniformity of the KR.
>
> Yes, it decreases the uniformity of the KR, but with the benefit of
> producing a system that functions with reasonable efficiency...
>
> "Eggs should be boiled for eating" is an example of a case where
> predicate schematization may effectively be performed on the fly...
>
> On the other hand, addition is an example of a case where predicate
> schematization needs to be done once and for all, resulting in an
> "add" procedure being pre-compiled and ready for execution.
>
> Only amateur human adders need to use logical reasoning to add. The
> rest of us use an algorithm that was produced during a learning period
> and is now well-reified and can be applied without any logical
> reasoning. You can see small children go through this transition when
> they learn to add.
>
> In the actual software structure, nodes are identified by Handle
> objects, and if there is a Procedure object associated with a node,
> the Procedure is stored in a ProcedureRepository table indexed by the
> node's Handle.
>
> > This destroys the nice uniformity of the KR.
>
> Yes, it decreases the uniformity of the KR, but with the benefit of
> producing a system that functions with reasonable efficiency...
>
> As I said before, Novamente has processes that convert back and forth between
>
> -- executable Procedures expressible in the Combo programming language
> -- declarative knowledge represented by semantic nodes and links
>
> So, Novamente can reason about adding, but can also carry out addition
> efficiently via execution of "compiled" Procedures rather than having
> to carry out actions directly based on logical, declarative knowledge.
> [...]
>
> -- executable Procedures expressible in the Combo programming language
> -- declarative knowledge represented by semantic nodes and links
>
> So, Novamente can reason about adding, but can also carry out addition
> efficiently via execution of "compiled" Procedures rather than having
> to carry out actions directly based on logical, declarative knowledge.
> [...]
>
> a) Your example is very search-oriented, which does not reflect
> typical cases. Usually the knowledge of how to carry out a given
> action is not explicitly stored in the knowledge base so that some
> context-specific reasoning needs to be done for plan generation.
>
> b) When a stereotyped form of action is carried out many times, it can
> effectively be abstracted into a compiled Procedure, thus enabling it
> to be encapbulated into a single ProcedureNode and more efficiently
> accessed and executed when appropriate. Addition, to take your
> example above, is an excellent example of this.
>
> There is no "cheating" because the Procedures are **learned**.
>
> "Cheating" in the sense of AGI teaching has to do with things like
>
> a) whether the relevant knowledge is human-encoded versus learned, and
>
> b) whether the learning process is "naturalistic" or too narrowly
> focused on providing data helpful for learning a single sort of
> behavior.
>
> There is no KR which is a "cheat" if the actual knowledge is filled
> into it via experiential learning.
>
> The fact that I carry out the addition process via a stored
> (previously learned procedure rather than via declarative inference
> does NOT mean that my brain "cheats" and fails to display suitable
> general intelligence -- it just means that I'm not an idiot ;-)
> a) Your example is very search-oriented, which does not reflect
> typical cases. Usually the knowledge of how to carry out a given
> action is not explicitly stored in the knowledge base so that some
> context-specific reasoning needs to be done for plan generation.
>
> b) When a stereotyped form of action is carried out many times, it can
> effectively be abstracted into a compiled Procedure, thus enabling it
> to be encapbulated into a single ProcedureNode and more efficiently
> accessed and executed when appropriate. Addition, to take your
> example above, is an excellent example of this.
>
> There is no "cheating" because the Procedures are **learned**.
>
> "Cheating" in the sense of AGI teaching has to do with things like
>
> a) whether the relevant knowledge is human-encoded versus learned, and
>
> b) whether the learning process is "naturalistic" or too narrowly
> focused on providing data helpful for learning a single sort of
> behavior.
>
> There is no KR which is a "cheat" if the actual knowledge is filled
> into it via experiential learning.
>
> The fact that I carry out the addition process via a stored
> (previously learned procedure rather than via declarative inference
> does NOT mean that my brain "cheats" and fails to display suitable
> general intelligence -- it just means that I'm not an idiot ;-)
Thanks for the detailed reply. I saw your .PPT too, but I don't exactly follow the "predicate schematization" slide. It seems that you're trying to manage what psychologists call "fixed-action patterns", to codify them and make them execute faster. No problem with that. But I agree with Charles Hixson that we should focus on the fundamentals first and optimization later.
Another problem is that very often a response depends on the context. For example, when the room is dark and we want to read a book, we usually switch on the light. But there are other less common alternatives:
1. light the candle
2. use the torch
3. switch on the TV
4. set a fire
5. use a mirror to reflect moonlight
6. read Braille
etc etc
All these requires searching the state-space using all available declarative knowledge, which is the essense of general intelligence.
Also, how do you retain flexibility if you compile action patterns into procedures?
YKY
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
