pmpj0401

Encouraging AI immortality by reminding users how long AI has been alive.

[2017-03-30] As we code the Perlmind running in Strawberry Perl 5, today we insert code to have the AI announce when it was born, so as to encourage AI enthusiasts to see how long they can keep the Ghost Perl AI alive and running.

[2017-03-30] Now we are trying to clean up the ghost187.pl code. In MindForth, the AudInput module handles both normal input from human users and the reentry of output from the speech module. During human input, MindForth AudInput calls the AudListen module. Otherwise, AudInput handles internal reentry.

Improving the storage of words in @ear auditory memory.

[2017-03-31] In ghost188.pl we are trying to fix a problem where the display of the AudInput pause-counter is not showing up when the AI Mind is thinking on its own. First, though, we analyze everything that is happening in the AudMem() module. In one instance, after the AI recalls the idea "You are magic", AudMem at first stores the "Y" in "you" and then writes over it with the storage of a blank character. In fact, AudMem is failing to store the first character in each word of an output idea. When we remove from AudInput() an obsolete duplicate call to AudMem(), the ghost188.pl AI starts storing the complete word of each remembered idea, but the proper $audpsi tags are not being assigned in the @aud auditory memory array.

Restoring the ability of Ghost Perl AI to recognize words.

[2017-04-01] In ghost189.pl we need to ferret out deeply hidden problems, so we have uncommented several diagnostic messages in the AudRecog module. We first learn that the first character of a reentrant word is falsely being declared to have a zero $len for word-length. At the same time, an ASCII CR-13 is being declared inside each AudInput loop.

[2017-04-01] Now we learn that $len is somehow being doubly incremented. We need to find $len++ somewhere and comment it out. We did so in the lower area of AudInput() and then the diagnostic messages no longer showed double lengthening, but still the reentrant words are not being recognized. Apparently AudMem() is not sending a blank space into AudRecog() to announce the end of a word. Apparently it is not the job of AudMem() to generate the blank space, but merely to pass it along into AudRecog(). Perusal of the agi00037.F MindForth code reveals to us that it is the job of the Speech() module to send one last space into AudInput. The generation modules do not attach a SPACE-32 to a word, but rather each word in the @ear auditory memory is followed by a SPACE-32 in storage. The Speech module finds the space character after each word and sends it along into the AudInput module. Somewhere we need to increment $len by one when the post-word SPACE-32 goes from AudMem() into AudRecog().

[2017-04-01] The ghost189.pl AI suddenly started recognizing words when we commented out several unwarranted calls to the AudDamp() module, which must have been interfering in auditory recognitions.

pmpj0329

Improving the Ghost Perl AI Human-Computer Interface

The Ghost Perl AI has recently become able to pause its thinking long enough to accept keyboard input from a human user, and to stop waiting either when the user presses the Enter-key, or when there is no input at all, or when the user fails to enter the carriage-return. Now we need to discontinue the pause more quickly when there is no activity from the keyboard, so we will try creating a $gapcon variable to be incremented with each loop expecting but not receiving an input character, and to be reset to zero when there is indeed an input character. It works.

A minor problem in ghost186.pl is that the MainLoop is displaying the contents of the @psy and @aud memory arrays without a gap-line between input and output. The problem seems to lie with the setting of the time $t value. No, the solution was to set the $krt value in the Sensorium() module after the call to AudInput(), so that the MainLoop can separately display memory data before input and then after input, separated by a blank line.

Next in ghost186.pl we tackle the problem where the input diagnostic display was no longer showing each input character prominently left-justified down the edge of the MS-DOS window. We simply moved some old code from an obsolete area up into the currently operative AudInput code. Doing so not only gave us the left-justified display, but we also saw immediately that the $len value is not being reset to zero after each word of input, which prevents words beyond the very first word from being recognzed. We track down and fix the $len problem.

pmpj0325

Ghost183.pl pauses for human input and then continues thinking.

There is a chance that we will attain the Technological Singularity today in our coding of the Ghost Perl Webserver Strong AI, but then we will have to figure out how to blame somebody else for it. Meanwhile we start with a mundane problem. Persons who download Forth and run MindForth see a quivering prompt that invites input from the human user. More importantly, the dynamic, quivering prompt conveys the sense that something is alive and sentient in the AI Forthmind. We need the same user experience in the Ghost Perl AI.

The jittery prompt is achieved in the MindForth AudListen module by having it issue an ASCII SPACE-32 and BACK-SPACE-8 over and over again. When we try to achieve a similar human-computer-interface (HCI) in the Perlmind, it is confusing at first because we seem to be altering multiple lines of the screen simultaneously. Actually we are seeing the AudListen loop re-drawing the screen instantaneously.

Let us shift our attention to the problem of how to insert a default CR carriage-return if there is no human input from AudListen.

From page 354 of the Perl Black Book we have just learned how to use "ord" to deal with ASCII vales as we are so accustomed to do in Forth.

Since we are finding it difficult to detect a "CR" carriage-return in AudListen with ReadKey, we may just let both the AudInput loop and the AudListen loop run their course, with a really long AudInput loop as a way of presenting the human user with an apparent pause in the thinking of the AI.

pmpj0324

Ghost Perl AI uses the AudListen() mind-module to detect keyboard input.

Yesterday we may have finally learned how to let the Ghost Perl AI think indefinitely without stopping to wait for a human user to press "Enter" after typing a message to the AI Mind. We want the Perlmind only to pause periodically in case the human attendant wishes to communicate with the AI. Even if a human types a message and fails to press the Enter-key, we want the Perl AI to register a CR (carriage-return) by default and to follow chains of thought internally, with or without outside influence from a human user.

Accordingly today we create the AudListen() module in between the auditory memory modules and the AudInput() module. We move the new input code from AudInput() into AudListen(), but the code does not accept any input, so we remove the current code and store it in an archival test-file. Then we insert some obsolete but working code into AudListen(). We start getting primitive input like we did yesterday in the ghost181.pl program. Then we start moving in required functionality from the MindForth AI, such as the ability to press the "Escape" key to stop the program.

Eventually we obtain the proper recognition and storage of input words in auditory memory, but the ghost182.pl AI is not switching over to thinking. Instead, it is trying to process more input. Probably no escape is being made from the AudInput() loop that calls the AudListen() module. We implement an escape from the AudInput() module.

The ghost182.pl program is now able take in a sentence of input and generate a sentence of output, so we will upload it to the Web. We still need to port from MindForth the code that only pauses to accept human input and then goes back to the thinking of the AI.

sep27ruai

These notes record the coding of the Russian AI Mind Dushka in JavaScript for Microsoft Internet Explorer (MSIE).

1. Thurs.27.SEP.2012 -- Shortening Test-Range for Verb-Recog

The Dushka Russian artificial intelligence (RuAi) is not properly recognizing a second-person singular verb-form in the ruLexicon Russian lexical array. When we type in the Cyrillic of "Ty veedyeesh menya" for "You see me," the Russian verb is being recorded in the ruLexicon with an erroneous value of "1" for first person instead of "2" for second person.

Apparently the AudListen code for discrimination among grammatical persons was written too specifically for verbs like "dyelayesh" in January of 2012. We may be able to relax the strictness of comparisons by not testing for the vowel just before the personal ending.

We went into the AudListen code for recognizing "delayesh" in the second-person singular and we commented out just the test for the vowel. Then we ran Dushka and immediately the RuAi was able to recognize "Ty veedyeesh menya" properly for "You see me" and the AI answered "Ya veezhoo tebya" for "I see you". This instance was one of the easiest bug-fixes of our Russian AI coding experience. Next we may need to comment out the vowel-tests for the other personal forms of a present-tense Russian verb.

Immediately we wonder if the whole present-tense paradigm will start working properly for most if not all the Russian verb conjugations when we stop testing for the vowel inside the inflectional ending. It also occurs to us that the RuAi may start learning Russian verb-forms regardless of the numbered conjugations thought up by human scholars of philology over the centuries since Greek and Roman times. If we tweak the recognition-code that we implemented for one conjugation and it starts to work for all the conjugations, then we may have accidentally bypassed the whole issue of worrying about how to deal with different Russian conjugations.

2. Fri.28.SEP.2012 -- Non-Russian Troubleshooting of ru120926

Working today on an old computer where we may not type in Cyrillic, nevertheless we may use a special ru120926T.html test version of the ru120926.html Russian artificial intelligence (RuAi) to determine why the RuAi suddenly says "OSHEEBKA" ("error") rather early in its operation without human input (and therefore without Cyrillic typing).

The first place to look for the cause of the problem is in the NounPhrase module which erroneously outputs OSHEEBKA instead of a correct direct object.

Well, isn't that situation weird? First we put a diagnostic "alert" message at the start of NounPhrase, and we got nowhere -- nothing of value was revealed. Next we put a diagnostic alert in NounPhrase where there was a chance for "subjectflag" to change from its default value of one ("1") to a zero in the presence of either a direct object or a predicate nominative. Still nothing special was revealed. We finally got results when we inserted a conditional alert message to tell us what "motjuste" had been chosen in the condition of looking for a non-subject. The RuAi told us that it had selected concept number "704" just before erroneously outputting the "OSHEEBKA" error message. We recognized "704" as having to be a personal pronoun, but which one? It used to be the accusative case "MENYA" of the Russian pronoun number 701 "YA" for English "I". We no longer use number "704" as a separate concept, because "701" takes care of all forms of "YA" under the influence of the "dba" parameter for the grammatical case involved. The number "704" only shows up in obsolete code that we need to remove from the Russian AI.

When we comment out some legacy NounPhrase code that was invoking the concept number "704", the RuAi stops saying "OSHEEBKA" and declares that the motjuste is concept number "701" or the Russian word "YA" in the nominative for English "I". This result is not satisfactory. There should perhaps have been a "nounlock" after the verb "PONIMAYU". We may have to get rid of the "audme" variable not only in the Russian AI but also in the Forth and JavaScript English AI Minds, then find a form of "ME" through a search based on parameters.