Benjamin Goertzel wrote:
Hi,
Possibly this could be approached by partitioning the rule-set into
"small chunks of rules that work together", so that one didn't end up
trying everything against everything else. These "chunks of rules"
might well be context dependent, so that one would use different chunks
at a dinner table than in a work shop. There would need to be ways to
combine different chunks of rules, of course, so e.g. a restaurant table
would be different from a dinner table, but would have overlapping sets
of rules. (I hope I'm not just re-inventing frames...)
The issue is how these contexts are learned. If context have to be
programmer-supplied, then you ARE just reinventing frames....
"Context formation" is a tricky inference problem in itself
-- Ben
Well, my rather vague idea was to start with a very small rule set, that
didn't need to be partitioned, and evolve rule-sets by statistical
correlation (what tends to get used with what). As new rules are added,
at some point clusters would need to separate (for efficiency). I
suppose this could all be done with activation levels, but that's not
the way I tend to think of it.
OTOH, if the local cluster can't handle the deduction, it would need to
check the "most closely associated/most activated" clusters to see if
they could handle it. Not sure how well this would work. Clearly it
has no more theoretical power than having all the rules in a large
table, but I feel it would be a more efficient organization.
Also, I don't have any "definition" of rule yet. It's not at all clear
that it would be easy to translate into something a person not familiar
with the details of the hardware and software would understand. (If a
certain area of RAM is mapped to a video camera, reading/writing the ram
will naturally mean something very different than it would mean in other
contexts. Writing to it might be a request to alter the scene . (A
silly way to do things, but it's for the sake of the point, not for real
implementation.) I'm not at all sure that rules of the form "if x do y,
then check for result z (if not raise exception w)" will suffice, even
if you allow great flexibility as to what x, y, z, and w are interpreted
as. Possibly if they could be generalized functions (with x and z
limited to not causing side effects).
-----
This list is sponsored by AGIRI: http://www.agiri.org/email
To unsubscribe or change your options, please go to:
http://v2.listbox.com/member/?list_id=303
