Fri.20.AUG.2010 -- Restoring the "recon" System
We had to upload the 19aug10A.F MindForth with only semi- successful code that answered a who-query with "BE" instead of "IS". In BeVerb we could force the word "IS" to be selected, but then the wrong predicate nominative was chosen. In our new code we want to explore why the switch from "BE" to "IS" was causing problems.
In our recent 19aug10A.F code we had a conflict between
activation-thresholds for the governance of program-flow.
The old "recon" system was using a threshold of "20" and
the new "beact" system was using a threshold of "12". It
has occurred to us meanwhile that we might solve some
problems by tracking down the etiology of the "beact"
activations and exerting an upwards push on them so that
they would share the same threshold level of "20" with
the "recon" system -- which was at a point carefully
chosen to avoid spurious associations.
In our 20aug10A.F AI code, let us see what forces are
at work to influence and shape the "beact" levels.
The "beact" variable is first stored within the VerbPhrase
module, as the activation on the winning verb selected for
inclusion in a sentence. As we use a diagnostic message to
reveal the values of both "beact" and ordinary "act"
within VerbPhrase, we discover that they hold numerically
the exact same values. Why, then, are the threshold
levels so different?
We should probably start using "predact"
(for "predicate activation") instead of simple "act" to
test the quasi-recon threshold, so that "beact"
and "predact" together will make more sense as variables.
The "recon" comparison involved setting a threshold of
twenty (20), below which validly associated verbs were
empirically not being found for a mystery noun, so that
the noun could be treated as the proper subject of a "what-
is" question. Perhaps we could proceed by returning to
reliance upon the recon-system, and by using the WhatIs
module or its likeness as the arena for decisions about
invoking the WhoBe module.
If we shift things around here and not only go back to
using the "recon" system, but also use "recon" to
differentiate between calling WhatIs and WhoBe, then we
have made a major change in MindForth which may lead to
the creation of an AI worth studying for many neophyte AI
programmers. Only the AI that thinks and works is worth
studying and reverse-engineering. How we arrived at
the working AI will not be anywhere near as important as
figuring out how the AI-complete software works, so that
AI coders can work on maintaining and improving the AI.
In our work now on implementing the generation of who- queries and on the successful retrieval of knowledge stored when who-queries are answered, we discover now that conditions in the MindForth program are much messier and problematically more complicated than we had imagined. For instance, it causes a problem if we enter "Andru is a robot" and the AI associates the be-verb to the article "A" instead of to "ROBOT". The problem is that we can not retrieve the basic knowledge that "Andru is robot". If we enter "Andru is robot" without the article "a", we can ask "what is andru" to retrieve the knowledge, but the AI answers, "ANDRU BES ROBOT", as if "be" were a regular verb that may take an inflectional "s" ending.
Just now we typed in "andru is robot" and "what does
andru be". We received the answer, "HE BE ROBOT".
We seem to recall that either in Forth or in
skip over an article when storing the association between
an input verb and its direct object. Since we can not find
such code, it probably does not exist. We will compose new
code to do the job. Since we can intercept "a" or "the"
and not store them as a "seq" associated with a verb, at
the same time we can set a "lackseq" flag to indicate that
there exists a condition where a recent engram lacks
a "seq" value. Then we can wait for a candidate "seq" to
come in, and we can have InStantiate or some other
competent module retroactively store the valid "seq" while
resetting the "lackseq" flag to zero.
It looks as though InStantiate stores the "seq" value
only retroactively, anyway, so we may superimpose code to
prevent the articles "a" and "the" from being stored as a