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.

Sat.21.AUG.2010 --
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 JavaScript, we had coded a mechanism for InStantiate to 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 false "seq".