Ben:
> It's a little more than that (more than just speed optimization),
> because the declarative knowledge may be uncertain, but the procedure
> derived from it will often be more determinate...
> [...]
>
> Well, we are trying to make NOvamente actually do stuff (and
> succeeding, to a limited but nontrivial extent so far). We already
> have got the fundamentals figured out and are at the point where we
> actually need to make our system work in an interesting way, and that
> means that doing theorem-proving internally every time an action needs
> to be taken is just not acceptable.
> [...]
>
> because the declarative knowledge may be uncertain, but the procedure
> derived from it will often be more determinate...
> [...]
>
> Well, we are trying to make NOvamente actually do stuff (and
> succeeding, to a limited but nontrivial extent so far). We already
> have got the fundamentals figured out and are at the point where we
> actually need to make our system work in an interesting way, and that
> means that doing theorem-proving internally every time an action needs
> to be taken is just not acceptable.
> [...]
>
> Two answers:
>
> 1)
> NOte that the compiled procedures may involve calls to the system's
> main memory, and may sometimes invoke inferences internally. So there
> is an interweaving of execution of compiled instructions and
> on-the-fly mining of the knowledge and when necessary inference based
> on the knowledge base.
>
> 2)
> In a situation like you mention above, the choice of whether to read
> Braille, light a fire, etc., would be carried out inferentially within
> Novamente. But once the choice was made, some stored procedures would
> be used to carry out the individual choices. For instance, reading
> Braille would take the form of stored procedures rather than
> on-the-fly logical inference. And, lighting a fire would probably be
> done by spontaneously piecing together a procedure based on stored
> subprocedures learned during previous fire-lighting experiences....
>
> 1)
> NOte that the compiled procedures may involve calls to the system's
> main memory, and may sometimes invoke inferences internally. So there
> is an interweaving of execution of compiled instructions and
> on-the-fly mining of the knowledge and when necessary inference based
> on the knowledge base.
>
> 2)
> In a situation like you mention above, the choice of whether to read
> Braille, light a fire, etc., would be carried out inferentially within
> Novamente. But once the choice was made, some stored procedures would
> be used to carry out the individual choices. For instance, reading
> Braille would take the form of stored procedures rather than
> on-the-fly logical inference. And, lighting a fire would probably be
> done by spontaneously piecing together a procedure based on stored
> subprocedures learned during previous fire-lighting experiences....
Alright, I assume you have a reasonable way of dealing with procedures. My concern is really about KR. The question is do you *segregate* memory into declarative, episodic, and procedural memory.
I just don't see why procedural knowledge should be mixed with declarative memory in the same container. If you put procedural knowledge in a separate memory space then you can use a more standard / conventional KR for declarative knowledge.
[ I have not thought about how to apply procedural knowledge, that probably involves a lot of heuristics, and we can discuss that at a later time. ]
YKY
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
