pmpj0408

Retroactively setting associative $seq tags for direct objects of verbs.

In the ghost194.pl AI, we have a problem where the direct-object $seq of a verb is being indeed properly assigned for human user input, but not for reentrant ideas being summoned from experiential memory. Because the $seq is not yet known when a verb comes in, the $seq value must be assigned retroactively when the direct object of the verb comes in. The situation where the process works for human input but not for a reentrant idea, suggests that the cause of the problem could simply be that the value of some pertinent variable is not being reset as needed.

This problem of the retroactive assignment of the associative $seq tag for a verb is difficult to debug. It may involve making the reentry routine equal to the human-input routine, or it may involve porting into Perl some special code from the 24jul14A.F version of MindForth. We have meanwhile been offering in the computer-science compsci subReddit a suggestion that students in need of an undergraduate research project might look into the Ghost AI software coded in Strawberry Perl 5 as an opportunity to select a mind-module to work on. We feel some urgency to debug our code and get it working as well as possible when we are inviting undergraduate students and graduate students and professors to take over and maintain their own branch of the AI Mind development. There is a steep learning curve to be surmounted before participants in such an artificial general intelligence (AGI) project may move forward in AI evolution. So now we go back to the problem of debugging the retroactive assignment of $seq subsequent-concept tags.

We search our ghost194.pl source code for "$psy[" as any instance where a $seq is being inserted either currently or retroactively into a flag-panel row of the @psy conceptual array. We discover that a $verbcon flag for seeking direct or indirect objects is governing the storage of the $seq tag in the Parser() module. Immediately we suspect that the $verbcon flag is perhaps being set during actual human user input but not during the reentry of an idea retrieved from memory. We check and we see that $verbcon is set to unity ("1") in the Parser() module when the part-of-speech $pos variable is at a value of "8" for a verb. The $pos value is set in the OldConcept() module when a known verb is recognized.

We insert a diagnostic message about the direct object in the Parser() module, and the message shows up during human user input, but not during reentry. Apparently the Parser() module is not even being called during reentry. No, it is being called, but the $verbcon flag is not being set properly during reentry. When we comment out the reset of $verbcon at the end of the AudInput() module and we move the reset to the Sensorium() module, we start seeing the assignment of direct-object $seq tags during the reentry of ideas recalled from memory. However, in a later session we must deal with the new problem that improper direct-object $seq flags are being set for personal pronouns during human user input. No, we debug the problem now, simply by resetting time-of-verb $tvb at the start of the EnThink() module, to prevent an output-sentence from adjusting associative tags for a previous sentence with a previous time-of-verb. The AI becomes able to receive "i know you" as input and then somewhat later say "YOU KNOW ME."

pmpj0327

Perl Mind Programming Journal

[2017-03-26] The main problem with the ghost184.pl Perlmind is that it does not supply an automatic carriage-return CR-13 if the human user neglects to press the Enter-key. This defect prevents the AI from going back to its own chains of thought when a human user has begun but not completed a message of input.

[2017-03-26] We may be able to fix the problem by supplying a CR-13 carriage-return when the input loop of the AudInput module is making its last loop. We try it, and it seems to work, but we find that ReEntry() does not work after an incomplete human input is supplied with a CR-13 in the AudInput module. We deploy a diagnostic message or two and we learn that the $len variable is not at zero when ReEntry() is called, thus perhaps interfering with the proper function of AudInput. Let us try setting the $len variable to zero at the start of the ReEntry module.

Ghost 185.pl Strong AI enters each input character into memory.

[2017-03-27] In the Strong AI ghost185.pl it is time to change from the re-entry of complete sentences back into the Mind to a more immediate re-entry of each phoneme (character) back into the Mind. In AudInput(), when we start sending each input character directly into AudMem(), nothing gets recognized, perhaps because we need to change the characters to uppercase. We also start incrementing time "t" before AudInput() calls AudMem(), and we start getting auditory recognition of an input word. When we preserve the inner loop of AudInput but we comment out the outer loop for whole words, we start getting a display of the storage of input in memory.

Next we need to implement the switch-over from storing input to generating output. It appears that we are not getting memory-storage of output because time "t" is not being incremented. We also need to turn a nested AudInput() loop into just a one-time sequence. Then in Speech() we set $pho before we call AudInput() for the reentry of Speech() output. Suddenly we begin seeing both the input and the output as stored in conceptual and auditory memory. We tweak ghost185.pl a little and we upload it.

may3mfpj

The MindForth Programming Journal (MFPJ) is both a tool in developing MindForth open-source artificial intelligence (AI) and an archival record of the history of how the AI Forthmind evolved over time.

1 Tues.3.MAY.2011 -- Encountering the WHO Problem

In the most recent release of MindForth artificial intelligence for autonomous robots possessing free will and personhood, our decision to zero out post-ReEntry concepts is only tentative. If the mind-design decision introduces more problems than it solves, then the decision is reversible. It was disconcerting to notice that the newest version of MindForth could no longer answer who-are-you questions properly, and would only utter the single word "WHO" as output in response to the question. We expect the necessary bugfix to be a simple matter of tracking down and eliminating some stray activation on the "WHO" concept-word, but there is a nagging fear that we may have made a wrong decision that worsened MindForth instead of improving it, that delayed the Singularity instead of hastening it, and that argues for an AI working group to be nurturing MindForth instead of a solitary mad scientist.

2 Tues.3.MAY.2011 -- Debugging the WHO Problem

In the InStantiate mind-module, both WHO and WHAT are set to zero activation as recognized input words, under the presumption that such query words work in a mind by a kind of self-effacement that lets the information being sought have a higher activation than the interrogative pronoun being used to request the information. Today at first we could not understand why the setting to zero seemed to be working for WHAT but not for WHO. Eventually we discovered that only WHAT and not WHO was being set to zero in the ReActivate module, with the result that all instances of the recognized WHO concept were being activated at a high level in ReActivate. When we fixed the bug by having both InStantiate and ReActivate set WHO to zero activation, the AI Mind began giving much better answers in response to who-queries. Immediately, however, other issues popped up, such as how to make sure that neural inhibition engenders a whole range of disparate answers if they are available in the knowledge base (KB), and whether we still need special variables like "whoflag" and "whomark". In general, we tolerate special treatment of words like WHO and WHAT with the caveat that we expect to do away with the special treatment when it becomes obvious that we can dispense with it.

Table of Contents

• 1 Tues.3.MAY.2011 -- Encountering the WHO Problem

• 2 Tues.3.MAY.2011 -- Debugging the WHO Problem