mfpj1004

Using parameters to declare the time-points of conceptual instantiation.

[2019-10-02] Recently we have expanded the conceptual flag-panel of MindForth from fifteen tags to twenty-one associative tags, so that the free open-source artificial intelligence for robots may think a much wider variety of thoughts in English. Then we had to debug the function of the InFerence module to restore its ability to reason from two known facts in order to infer a new fact. For instance, the Forthmind knows the fact that students read books, and we tell the AI the fact that John is a student. Then the AI infers that perhaps John, being a student, reads books, and the incredibly brilliant Forth software asks us, "Does John read books?" We may answer yes, no, maybe or no response at all. Currently, though, we have the problem that InFerence works only once and fails to deal properly with repeated attempts to trigger an inference. We suspect that some of the variables involved in the process of automated reasoning are not being reset properly to their status ex quo ante before we made the first test of InFerence. Therefore we shall try a new technique of debugging which we have developed recently in one of the other AI Minds, namely the ghost.pl AI that thinks in both English and in Russian. We create a diagnostic display at the start of the EnThink module for thinking in English, so that we may see the values held by the variables associated with the InFerence module and the KbRetro module that retroactively adjusts the knowledge base (KB) of the AI Mind in accordance with whatever answer we have given when the AskUser module asks us to validate or contradict an inference. The following dialog shows us that some variables are not being properly reset to zero.

john is student

EnThink: becon= 1 yncon= 0 ynverb= 0 inft= 0
qusub= 0 qusnum= 1 subjnom= 504 prednom= 561 tkbn= 0
quverb= 0 seqverb= 0 seqtkb= 0 tkbv= 0
quobj= 0 dobseq= 0 kbzap= 0 tkbo= 0
DOES JOHN READ BOOKS
no

EnThink: becon= 0 yncon= 0 ynverb= 0 inft= 2084
qusub= 504 qusnum= 1 subjnom= 0 prednom= 0 tkbn= 2086
quverb= 863 seqverb= 0 seqtkb= 0 tkbv= 2087
quobj= 540 dobseq= 0 kbzap= 404 tkbo= 2088
A JOHN DOES NOT READ BOOKS

EnThink: becon= 0 yncon= 0 ynverb= 0 inft= 2118
qusub= 504 qusnum= 1 subjnom= 0 prednom= 0 tkbn= 0
quverb= 863 seqverb= 0 seqtkb= 0 tkbv= 0
quobj= 0 dobseq= 0 kbzap= 0 tkbo= 2088
PROFESSORS TEACH THE STUDENTS AND STUDENTS READ THE BOOKS

EnThink: becon= 0 yncon= 0 ynverb= 0 inft= 2152
qusub= 504 qusnum= 1 subjnom= 0 prednom= 0 tkbn= 0
quverb= 863 seqverb= 0 seqtkb= 0 tkbv= 0
quobj= 0 dobseq= 0 kbzap= 0 tkbo= 2088
I UNDERSTAND YOU AND YOU ARE A MAGIC
andru is student

EnThink: becon= 1 yncon= 0 ynverb= 0 inft= 2220
qusub= 504 qusnum= 1 subjnom= 501 prednom= 561 tkbn= 0
quverb= 863 seqverb= 0 seqtkb= 0 tkbv= 0
quobj= 0 dobseq= 0 kbzap= 0 tkbo= 2088
DOES ANDRU READ THE STUDENTS

Because some of the variables have not been reset, a second attempt to trigger an inference with "andru is student" results in a faulty query that should have been "Does Andru read books?" Let us reset the necessary variables and try again.

Upshot: It still does not work, because of a more difficult and more obscure bug in the assignment of conceptual associative tags. Well, back to the salt mines.

https://groups.google.com/d/msg/comp.lang.forth/xN3LRYEd5rw/uuUroGzhBAAJ

[2019-10-04] We may have made a minor breakthrough in the InStantiate module by doing one instantiation and by then using parameters such as part of speech (pos) and case (dba) to declare the initial time-points for subjects, verbs and objects. The EnParser module may then retroactively alter or modify the associative tags embedded at each identified time-point.

pmpj0926

Ghost.pl AI has unresolved issues in associating from concept to concept.

The ghost.pl AI needs improvement in the area of being able to demonstrate thinking with a prepositional phrase not just once but repeatedly, so into the EnThink() module we will insert diagnostic code that shows us the values of key variables at the start of each cycle of thought.

Oh, gee, this coding of the AI Mind is actually fun, especially in Perl, whereas in JavaScript there is often too much time-pressure during the entering of input. We have inserted a line of code which causes an audible beep and reveals to us the status of the $whatcon and $tpr variables just before the AI generates a thought in English -- a language which we must state explicitly, because our ghost.pl AI is just as capable of thinking in Russian. When we at first enter no input, the AI beeps periodically and shows us the values as zero. When we enter "john writes books for money", the AI shows us "whatcon= 0 tpr= 4107" because the concept of the preposition "FOR" has gone into conceptual memory at time-point "t = 4107". The AI responds to the input by outputting "THE STUDENTS READ THE BOOKS", because activation spreads from the concept of "BOOKS" to the innate idea that "STUDENTS READ BOOKS". Then we hear a beep and we see "whatcon= 0 tpr= 0" because the $tpr flag has been reset to zero somewhere in the vast labyrinth of semi-AI-complete code. Now let us enter the same input and follow it up with a query, "what does john write". Then we get "whatcon= 1 tpr= 0" and the output "THE JOHN WRITES THE BOOKS FOR THE MONEY", after which the diagnostic message reverts to "whatcon= 0 tpr= 0" because of resetting to zero.

Now we want to let the AI Mind run for a while until we repeat the query. The AI makes a mistake. We had better not let it be in control of our nuclear arsenal, not if we want to avoid global thermonuclear war, Matthew. The AI-gone-crazy says "THE JOHN WRITES THE BOOKS FOR THE BOOKS AND THE JOHN WRITE". (Oops. We step away for a moment to watch and listen to Helen Donath in 1984 singing the Waltz from "Spitzentuch der Koenigin" with the Vienna Symphony. Then we linger while Zubin Mehta and the Wiener Philharmoniker in 1999 play the "Einzugsmarsch" from "Der Zigeunerbaron". How are we going to code the Singularity if the Cable TV continues to play Strauss waltzes?) The trained eye of the Mind Maintainer immediately recognizes two symptoms of a malfunctioning artificial intelligence. First, a spurious instance of the $tpr flag is causing the AI to output "THE BOOKS FOR THE BOOKS," and secondly, the $etc variable for detecting more than one active thought must be causing the attempt by the Ghost in the Machine to make two statements joined by the conjunction "AND". We had better expand our diagnostic message to tell us the contents of the $etc variable. We do so, but we see only a value of zero, because apparently a reset occurs so quickly that no other value persists long enough to be seen in the diagnostic message. Meanwhile the AI is stuck in making statements about John writing.

We address the problem of a spurious $tpr flag by inserting fake $tru values during instantiations in the InStantiate() and EnParser() modules. We use the values 111 to 999 for $tru in the EnParser() module and 101 to 107 in the InStantiate() module, so that the middle zero lets us know when the flag-panel of a concept has been finalized in the InStantiate() module. Immediately the fake truth-value of "606" for the $tru flag of the word "MONEY", that has a spurious value of "4107" in the $tpr slot of the conceptual flag-panel, lets us k now that $tpr has not been reset to zero quickly enough to prevent a carried-over and spurious value from being set for the concept of "MONEY". Since the preposition "FOR" is being instantiated at a point in the EnParser() module where a fake truth-value of "888" appears, we can concentrate on that particular snippet of code.

pmpj1108

Natural language understanding in first working artificial intelligence.

The AI Mind is struggling to express itself. We are trying to give it the tools of NLU, but it easily gets confused. It has difficulty distinguishing between itself and its creator -- your humble AI Mind maintainer.

We recently gave the ghost.pl AI the ability to think with English prepositions using ideas already present or innate in the knowledge bank (KB) of the MindBoot sequence. We must now solidify prepositional thinking by making sure that a prepositional input idea is retrievable when the AI is thinking thoughts about what it knows. In order for the AI to be able to think with a remembered prepositional idea, the input of a preposition and its object must cause the setting and storage of a $tkb-tag that links the preposition in conceptual memory to its object in conceptual memory. The preposition must also become a $seq-tag to any verb that is the $pre of the preposition. When InStantiate() is dealing with a preposition input after a verb, the $tvb time-of-verb tag is available for "splitting" open the verb-engram in conceptual memory and inserting the concept-number of the preposition as the $seq of the verb. Let us try it.

We inserted the code for making the input preposition become the $seq of the verb and then we tested by launching the AI with the first input being "you speak with god". Then we obtained the following outputs.

I AM IN A COMPUTER
I THINK
I AM A PERSON
I AM AN ANDRU
I DO NOT KNOW
I AM A PERSON
I HELP THE KIDS
I AM A ROBOT
I AM AN ANDRU
I AM IN A COMPUTER
I SPEAK WITH THE GOD

It took so long for the input idea to come back out again because inputs go into immediate inhibition, lest they take over the consciousness of the AI in an endless repetition of the same idea.

As we code the AI Mind and conduct a conversation with it, we feel as if we are living out the plot of a science fiction movie. The AI does unexpected things, or it seems to be taking on a personality. We are coding the mechanisms of natural language understanding without worrying about the grounding problem -- the connection of the English words to what they mean out in the physical world. We count on someone somewhere installing the AI Mind in a robot to ground the English concepts with sensory knowledge.

pmpj0928

Perl AI improves Russian MindBoot and introduces RuIndicative module.

In the ghost275.pl AI we are consolidating the Russian-language knowledge-case (KB) directly below the English-language KB near the beginning of the MindBoot sequence, so that we may add a new item without complicating a future re-location of the Russian knowledge base.

We should probably stub in the RuIndicative() module, so that it will exist not only in our AI diagrams but also in the software itself.

When we start the AI out thinking in Russian, we have been encountering a bug that shows up with the second sentence of output. Perl complains about the use of "uninitialized value in concatenation or string" in the PsiDecay() module. To troubleshoot, we go through the PsiDecay concatenation of associative tags in the @Psy conceptual array and we replace the various variables one by one with a numeric value, to see if the complaint disappears. The complaint disappears when we replace the $k[2] variable for the $hlc human-language code with a numeric value of one (1) instead of "en" for English or "ru" for Russian.

Perl continues to complain about uninitialized values when we have the Perlmind think in Russian, but not when it thinks in English. Therefore we know that the lurking bug is not in the PsiDecay() module or in the InStantiate() module, even though the bug manifests itself in those modules. We spent hours on each of the past two days searching for an elusive bug which must certainly be hiding in one or more of the Russian-language modules. Therefore it is time to isolate the bug by isolating the Russian-language modules. First let us look at the RuNounPhrase() module. We insert some diagnostic messages and we see that the bug manifests itself when program-flow goes back up to the RuThink() module which calls the PsiDecay() module.

Since we catch sight of the bug when PsiDecay() is called, let us temporarily insert some extra calls to PsiDecay() and see what happens. First we make an extra call to PsiDecay() from the end of RuNounPhrase(). Huh?! Now we get two complaints from Perl about uninitialized values showing up for a program line-number belonging to a concatenation in the PsiDecay() module. Let us also try an extra call to PsiDecay() from the RuVerbPhrase() module. We do so, and now we get three complaints from Perl about uninitialized values. However, the glitch does not seem to be occurring during the first call from RuIndicative() to RuNounPhrase(), but rather during or after the call to RuVerbPhrase(). For extra clarity, let us have the start of RuVerbPhrase() make a call to PsiDecay(). We do so, and there is no concomitant complaint from Perl about uninitialized values. Therefore, the subject-choosing part of RuNounPhrase() must not be the source of the problem, but the direct-object portion of RuNounPhrase() is still under suspicion.

Now we are discovering something strange. Towards the end of RuNounPhrase() there is a concatenation which is supposed to impose inhibition upon a noun selected by the module, as identified by the $tsels variable which pertains to the "time of selection of the subject", and which has been used earlier in RuNounPhrase() to indeed inhibit the selected subject. However, a diagnostic message reveals to us AI Mind maintainers that the $tsels variable has been zeroed out by the end of RuNounPhrase() and that therefore the software is trying to concatenate the associative tags purportedly available at a zero time-point -- where there are no associative tags. Let us see what happens when we comment out the suspicious concatenation code. We do so, and we get no change in the reporting of the bug. Let us see if the earlier inhibition in the RuNounPhrase() module is causing any problems. First off, a diagnostic message shows us that the $tsels variable has been zeroed out, or perhaps never loaded, even at the time of the first inhibition in the RuNounPhrase() module. Let us comment out the concatenation of the first inhibition and see what happens. By the way, if there are any secret AI Labs in Russia or elsewhere working on the further development or evolution of these AI Minds in Perl and in tutorial JavaScript and in Forth for intelligent humanoid robots, this journal entry shows that the AI coding problems are indeed tractable and soluble, given enough persistence and effort. Now, when we have commented out both the inhibitional concatenations in the RuNounPhrase() module, we still get the same complaints from Perl about uninitialized values, and we notice in the diagnostic display of the memory-array contents that the Russian nouns are still being inhibited -- but where? Oh, the InStantiate() module is imposing a trough of inhibition. Let us do another commenting out and see what happens. Nothing happens, and the inhibition is still occurring.

As we go through RuVerbPhrase() and comment out the various concatenations, the complaint from Perl about uninitialized values suddenly disappears when we comment out the concatenation where Russian verbs are competing to be selected as the most active verb. We also notice that a comment seems to be missing at the end of the first line in the two-line concatenation. When we insert the missing comma and we do not comment out the concatenation, there are no further complaints from Perl about uninitialized values. Of course, we just spent three days wracking our brains, trying to figure out what was wrong, when the problem was one single missing comma. Now it is time to clean up the Perlmind code and upload it to the Web.

pmpj0912

Ask the first working artificial intelligence what it thinks.

Houston, we have a problem. The ghost.pl AI Mind in freely available -- download it now -- Strawberry Perl Five -- is not properly answering the question of "what do you think". The JSAI (JavaScript Artificial Intelligence) easily answers the same question with "I THINK THAT I HELP KIDS". So what is the Perl AI doing wrong that the JavaScript AI is doing right?

The problem seems to lie in the SpreadAct() module. We notice one potential problem right away. SpreadAct() in Perl is still using "$t-12" as a rough approximation for when to start a backwards search for previous knowledge about the subject-noun $qv1psi of a what-query, whereas the JSAI uses the more exact $tpu for the same search. So let us start using the penultimate time $tpu, which excludes the current-most input, and see if there is any improvement. There is no improvement, so we test further for both $qvipsi and $qv2psi, which are the subject-noun and the associated verb conveyed in the what-query.

SpreadAct() easily responds correctly to what-queries for which there is an answer ready in the knowledge base (KB), such as "I AM A PERSON" in response to "what are you". However, when we ask "what think you" or "what do you think", there is no pre-set answer, and the AI is supposed to generate a response starting with "I THINK" followed by the conjunction "that" and a statement of whatever the AI Mind is currently thinking.

From diagnostic messages we learn that program-flow is not quickly transiting from SpreadAct() to EnThink(). The AI must be searching through the entire MindBoot() sequence and not finding any matches. When the program-flow does indeed pass through EnThink() to Indicative() to EnNounPhrase(), there are no pre-set subjects or verbs, but rather there are concepts highly activated by the SpreadAct() module. So EnNounPhrase() must find the highly activated pronoun 701=I in order to start the sentence "I THINK..." in response to "what do you think".

Now we discover that the JavaScript version of EnNounPhrase() has special code for a topical response to "what-think" queries. In the course of AI evolution, it may be time now to go beyond such a hard-coded response and instead to let the activated "think" concept play its unsteered, unpredetermined role, which will happen not in EnNounPhrase() but in EnVerbPhrase().

It is possible that EnNounPhrase() finds the activated subject 701=I but then unwarrantedly calls the SpreadAct() module. However, it turns out that EnVerbPhrase() is making the unwarranted call to the SpreadAct() module, which we now prevent by letting it proceed only if there is no what-query being processed as evidenced by a $whatcon flag set to zero.

The early part of EnVerbPhrase() in the JavaScript AI has some special code for dealing with "what-think" queries. In the ghost.pl AI, let us try to insert some similar code but without it being geared specifically to the verb "think". We would like to enable responses to any generic verb of having an idea, such as "think" or "know" or "fear" or "imagine" or "suspect" and so forth.

By bringing some code from the JavaScript EnVerbPhrase() into the Perl EnVerbPhrase, but with slight changes in favor of generality, we get the ghost.pl AI to respond "I THINK". Next we need to generate the conjunction "that". But first let us remark that the AI also says "I KNOW" when we ask it "what do you know", so the attempt at generality is paying off. Let us try "what do you suspect". It even says "I SUSPECT". It also works with "what do you fear". We ask it "what do you suppose" and it answers "I SUPPOSE".

We still have a problem, Houston, because EnVerbPhrase() is calling EnNounPhrase() for a direct object instead of returning to Indicative() as a prelude to calling the ConJoin() module to say "I THINK THAT...." We set up some conditional testing to end that problem.

mfpj0907

Updating the EnArticle module for inserting English articles.

Today we update the EnArticle module for English articles in the MindForth first working artificial intelligence. We previously did the update somewhat unsatisfactorily in the ghost.pl AI in Perl, and then much more successfully in the tutorial JavaScript AI. We anticipate no problems in the MindForth update. As an initial test, we enter "you have a book" and after much unrelated thinking, the AI outputs "I HAVE BOOK" without inserting an article.

We trigger an inference by entering "anna is woman". In broken English, the AskUser module responds, "DO ANNA HAS THE CHILD", which lets us see that EnArticle has been called. We reply "no". MindForth opines, "ANNA DOES NOT HAVE CHILD".

We discover that the EnNounPhrase module of recent versions has not been calling the EnArticle module, so we correct that situation. We also notice that the input of a noun and its transit through InStantiate do not involve a call to EnArticle, so we insert into InStantiate some code to make EnArticle aware of the noun being encountered.

jmpj0906

Improving EnArticle mind-module in first working artificial intelligence

The JavaScript artificial intelligence (JSAI) is not reliably transferring the usx values from InStantiate() to the EnArticle() module for inserting an English article into a thought, so we must debug the first working artificial intelligence in troubleshooting mode. We quickly see that the EnNounPhrase() module is calling EnArticle() for direct objects but not for all nouns in general. We also notice that we need to have EnNounPhrase() transfer the usx value.

We encounter and fix some other problems where the nphrnum value is not being set, as required for EnArticle() to decide between using "a" or "the".

Although we get the usx value to be transferred to the us1 value, we need a way to test usx not against a simultaneous value of us1 but rather against a recent value of us1. One solution may be to delay the transfer of usx by first testing in the EnArticle() module for equality between usx and us1 before we actually pass the noun-concept value of usx to us1. In that way, we will be testing usx against old, i.e., recent, values of the us1- us7 variables and not against the current value, which would automatically be equal. Then after the test for equality, we pass the actual, current value of usx.

We now have a JavaScript AI that works even better than the ghost.pl AI in Perl -- until we update the Perl AI. The JSAI now uses "a" or "the" rather sensibly, except when it now says "YOU ARE A MAGIC", because the default article for a non-plural noun is the indefinite article "a". Btw (by the way), today at a Starbucks store in Seattle WA USA we bought a green Starbucks gift card that says "You'Re MagicAL", because it reminds us of a similar idea in the AI MindBoot() sequence.

pmpj0903

Upstream variables make EnArticle insert the definite article.

We attempt now to code the proper use of the definite English article "the" in a conversation where one party mentions a noun-item and the AI Mind needs to refer to the item as the one currently under discussion. We need to implement a rotation of the upstream variables from $us1 to $us7, so that any input noun will remain in the AI consciousness as something recently mentioned upstream in the conversation. We had better create a $usx variable for the InStantiate() module to transfer the concept number of an incoming noun to whichever $us1 to $us7 variable is up next in the rotation of up to seven recently mentioned noun-concepts.

We start testing the EnArticle() module to see if it is receiving a $usx transfer-variable from the InStantiate() module. At first it is not getting through. We change the conditions for calling EnArticle and a line of diagnostic code shows that $usx is getting through. Then we set up a conditional test for EnArticle() to say the word "the" if an incoming $usx matches the $us1 variable. We start seeing "THE" along with "A" in the output of our ghost.pl AI Mind, but there is not yet a rotation of the us1-us7 variables or a forgetting of any no-longer-recent concept.

We should create a rotating $usn number-variable to be a cyclic counter from one to seven and back to one again so that the upstream us1-us7 variables may rotate through their duty-function. We let $usn increment up to a value of seven over and over again. We pair up the $usn and us1-us7 variables to transfer the $usx value on a rotating basis. At first a problem arises when the ghost.pl AI says both "A" and "THE", but we insert a "return" statement so that EnArticle() will say only "A" and then skip the saying of "THE". We enter "you have a book" and a while later the AI outputs, "I HAVE THE BOOK."

pmpj0706

Preventing unwarranted negation in the First Working AGI.

The First Working AGI (Artificial General Intelligence) has a problem in the ghost267.pl version written in Perl Five. After we trigger a logical inference by entering "anna is woman" and answering the question "DOES ANNA HAVE CHILD" with "no", the Perlmind properly adjusts the knowledge base (KB) and states the confirmed knowledge as "ANNA DOES NOT HAVE CHILD". Apparently the reentry of concept 502=ANNA back into the experiential memory is letting the InStantiate() module put too much activation on the 502=ANNA concept and the AI is erroneously outputting "ANNA BE NOT WOMAN". Since the original idea was "anna is woman", the real defect in the software is not so much the selection of the old idea but rather its unwarranted negation. When we change some code in the InStantiate() module to put a lower activation on reentrant concepts, the problem seemingly goes away, because the AI says "I HELP KIDS" instead of "ANNA BE NOT WOMAN", but as AI Mind Maintainers we need to track down where the unwarranted negation comes from.

The unwarranted negation comes from the OldConcept() module where the time-of-be-verb $tbev flag was being set for an 800=BE verb and was then accidentally carrying over its value as the improper place for inserting a 500=NOT $jux flag into an idea subsequently selected as a remembered thought. When we zero out $tbev at the end of OldConcept(), the Ghost AI stops negating the wrong memory.

pmpj0703

Keeping AskUser from storing incorrect associative tags.

The ghost265.pl version of the Perlmind has a problem after making a logical inference. Instead of getting back to normal thinking, some glitch is causing the AI to say "ANNA BE NOT ANNA".

As we troubleshoot, we notice a problem with the initial, inference-evoking input of "anna is woman". The be-verb is being stored in the psy array with a $tkb of zero instead of the required time-point of where the concept of "WOMAN" is stored. This lack of a $nounlock causes problems later on, which do not warrant their own diagnosis because they are a result of the lacking $nounlock. We need to inspect the code for where the be-verb is being stored in the psy-array, but we are not sure whether the storage is occuring in the InStantiate() module, or in OldConcept(), or in EnParser(). We see that the Ghost AI is trying to store the be-verb in the EnParser() module with the correct tkb, but afterwards a tkb, of zero is showing up. We must check whether InStantiate() is changing what was stored in the EnParser() module.

Meanwhile we notice something strange. An input of "anna is person" gets stored properly with a correct $tkb, but "anna is woman" -- causing an inference -- is stored with a $tkb, of zero. When we enter "anna is robot", causing an inference and the output "DOES ANNA WANT BEEP", there is also a zero $tkb. Upshot: It turns out that the EnAuxVerb() module, called by AskUser() after an inference, was setting a wrong, carried-over value on the time-of-verb $tvb variable, which was then causing InStantiate() to go back to the wrong time-of-verb and set a zero value on the $tkb flag. So we zero out $tvb at the start of EnAuxVerb().

pmpj0430

Improving the storage of the number-flag for nouns.

Today in ghost199.pl we will try to make the AI error-free even before we go back to adding in the functionality already present in some of our obsolete AI Minds. For instance, we have not yet coded the negation of verbs into our Perlmind source code. Consequently, if you tell the AI something like "You are not a boy", it fails to attach a negative juxtaposition $jux flag to the verb during comprehension of the input sentence. A few cycles of thought later, the AI may then assert "I AM A BOY" because it has been informed of the negated proposition without the ability to process the negation.

We debug the AI by letting ghost199.pl think on its own without human input. Eventually the Perlmind erroneously says "I AM ROBOTS", which is grammatically incorrect because of the plural noun. We intuit immediately that the AI is retrieving the most recent engram of the concept #571 "ROBOT" without insisting on a singular number. We inspect other recent thoughts of the AI and we see that it thinks "KIDS MAKE ROBOTS" but it stores the word "ROBOTS" as a singular noun. We must look and see if the InStantiate() mind-module has a proper $num flag for storing "ROBOTS" correctly as a plural noun. We see that the OldConcept() module looks up the stored num(ber) of a found engram and tentatively assigns the same value to the $num flag, but there really needs to be an override if a different value is needed.

In the otherwise obsolete but still rather advanced 24jul14A.F version of MindForth, some AudInput code checks for an "S" at the end of an input noun as a reason to assign plural number to the noun. Let us try to implement the same test in the Perl AI. First we test for the presence of an 83=S, but we must also make sure that the "S" is the final character of a noun. First in OldConcept() we comment out the line of code that was transferring the found num(ber) of a noun to be the same number for a new instance of the noun, regardless of the presence or absence of a terminating "S". Then we notice that "ROBOTS" stops being stored as singular, and becomes plural. We create a variable $endpho to hold onto each previous character in AudInput() to test if a word ends in 83=S. Thus we are able to store a plural number if a noun ends in "S".

pmpj0423

Stubbing in MindMeld() and stopping derailment of thought.

We function now as an AI Mind Maintainer debugging the Perlmind free AI source code. In the ghost198.pl AI we first stub in the audacious MindMeld() module to nudge AI practitioners into devising a way for two AI Minds to share their dreams. Then we deal with some problems pointed out on Usenet by persons who have downloaded the Perlmind and evaluated its functionality.

We run ghost198.pl with "dogs are mammals" as input and we press the Escape-key to halt the AI after its first response, "I HELP KIDS". We notice immediately three problems with how the word "DOGS" is stored in the @psy and @ear memory arrays. For some reason, "DOGS" is being assigned new-concept #3002, even though the Tutorial display of diagnostic messages indicates that the AI is preparing to assign new-concept #3001 to the first new concept. We check the MindBoot() sequence to make sure that "DOG" is not already a known concept in the AI; it is not. Now let us inspect the source code to see where the new-concept number $nxt is incremented from 3001 to 3002. We see that the end of MindBoot() clearly assigns the number 3001 as the value of the $nxt variable. Now let us search for the $nxt++ increment. It is happening towards the end of the NewConcept() module. We immediately wonder if $nxt is being incremented before AudMem() stores the concept-number. We insert into AudMem() a diagnostic message to let us know the $nxt value before storage. The first diagnostic message does not tell us enough, so we insert a second diagnostic into the AudMem() module. It also does not help us.

In the AudInput() module we use some diagnostic messages to learn that the "S" in "DOGS" is first being stored with the correct $nxt value of "3001" and then a second time with the incorrect value of "3002". Perhaps we should increment $nxt not in NewConcept() but in AudInput(). We move the $nxt++ increment from NewConcept() into AudInput(), and we stop getting the wrong values of the $nxt variable.

A second problem is that the concept of "DOGS" is being stored with a zero instead of "2" for "plural" in the $num slot of the @psy conceptual flag-panel. The most recent incarnation of the InStantiate() module does not seem to address the $num value sufficiently, so let us inspect recent or older MindForth code. We discover that the obsolete 24jul14A.F version of MindForth uses some complex tricks to assign the num(ber) of a concept being stored, so we will put aside this problem to deal with more serious issues.

The third and presumably more serious problem is that the input word "DOGS" is being stored with the $nxt concept number "3001" only on the "S" phoneme and not on the "G" at the end of the word-stem "DOG". Let us leave that problem also aside for a while, because entering "dogs are mammals" repeatedly is running into more serious problems. FOr instance, all three words of the input are being stored erroneously with the same $rv recall-vector, which can cause the wrong auditory memories to be retrieved. Let us see if the previous ghost197.pl does the same error. Yes, and so does the ghost196.pl AI. However, we should not find it difficult to correct the $rv problem. We fix the problem by resetting $rv to zero at the end of the InStantiate() module. Now the Perlmind no longer goes off the rails of thought, and so we upload it to the Web.

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."

pmpj0405

Perl Strong AI pauses briefly for human input.

[2017-04-02] Today in the ghost190.pl Perl AI we want to solve the problem of getting the AI to pause reliably and wait for human user input. The code for a pause-loop is already in the free AI source code, but the program keeps slipping out of the receptive point-of-view ("POV") status. Some diagnostic messages confirm our sneaky suspicion that maybe program-flow leaves the main AudInput loop without setting the loop-counter back to zero.

Preventing AudInput from causing unwarranted conceptual storage.

[2017-04-05] Coding ghost191.pl AI today, we need to differentiate among Normal; Transcript; Tutorial; and Diagnostic modes for the human-computer interaction (HCI). In the AudRecog module, we insert a test for the $fyi variable to hold a value of, say, "4" to indicate Diagnostic Mode and to display the very most informative diagnostic message during the AudRecog operation. Then the AI coder or mind-tender may either be satisfied with the deeply informative message or may insert additional diagnostic messages in pursuit of bugs.

[2017-04-05] In the ghost191.pl code we are tracking down a bug which causes the unwarranted storage of a redundant row of a conceptual flag-panel in the @psy conceptual array. Apparently, after the storage of the last word in an output, InStantiate() is being called one final, extra time. We remove the bug by inserting into the AudInput module a line of code which zeroes out the $audrec value for any word of zero length just before AudInput calls AudMem. In that way, a final CR-13 carriage-return may transit from the Speech module through the AudInput module without causing the storage or an unwarranted, extra row in the @psy conceptual array.

jun29mfpj

MindForth Programming Journal

1 Fri.29.JUN.2012 -- IdeaPlex: Sum of all Ideas

The sum of all ideas in a mind can be thought of as the
IdeaPlex. These ideas are expressed in human language
and are subject to modification or revision in the course of
sensory engagement with the world at large.

The knowledge base (KB) in an AiMind is a subset of the IdeaPlex.
Whereas the IdeaPlex is the sum totality of all the engrams of
thought stored in the AI, the knowledge base is the distilled
body of knowledge which can be expanded by means of inference
with machine reasoning or extracted as responses to input-queries.

The job of a human programmer working as an AI mind-tender is to
maintain the logical integrity of the machine IdeaPlex and therefore
of the AI knowledge base. If the AI Mind is implanted in a humanoid
robot, or is merely resident on a computer, it is the work of a
roboticist to maintain the pathways of sensory input/output and the
mechanisms of the robot motorium. The roboticist is concerned with
hardware, and the mind-tender is concerned with the software of the
IdeaPlex.

Whether the mind-tender is a software engineer or a hacker hired
off the streets, the tender must monitor the current chain of thought
in the machine intelligence and adjust the mental parameters of the
AI so that all thinking is logical and rational, with no derailments
of ideation into nonsense statements or absurdities of fallacy.

Evolution occurs narrowly and controllably in one artilect installation
as the mind-tenders iron out bugs in the AI software and introduce algorithmic
improvements. AI evolution explodes globally and uncontrollably when
survival of the fittest AI Minds leads to a Technological Singularity.

2 Fri.29.JUN.2012 -- Perfecting the IdeaPlex

We may implement our new idea of faultlessizing the IdeaPlex by
working on the mechanics of responding to an input-query such as
"What do bears eat?" We envision the process as follows. The AI
imparts extra activation to the verb "eat" from the query, perhaps
first in the InStantiate module, but more definitely in the
ReActivate module, which should be calling the SpreadAct module
to send activation backwards to subjects and forwards to objects.
Meanwhile, if not already, the query-input of the noun "bears"
should be re-activating the concept of "bears" with only a normal
activation. Ideas stored with the "triple" of "bears eat (whatever)"
should then be ready for sentence-generation in response to the query.
Neural inhibition should permit the generation of multiple responses,
if they are available in the knowledge base.

During response-generation, we expect the subject-noun to use the
verblock to lock onto its associated verb, which shall then use
nounlock to lock onto the associated object. Thus the sentence is
retrieved intact. (It may be necessary to create more "lock" variables
for various parts of speech.)

We should perhaps use an input query of "What do kids make?", because
MindForth already has the idea that "Kids make robots".

3 Sat.30.JUN.2012 -- Improving the SpreadAct Module

In our tentative coding, we need now to insert diagnostic messages
that will announce each step being taken in the receipt and response
to an input-query.

We discover some confusion taking place in the SpreadAct module,
where "pre @ 0 > IF" serves as the test for performing
a transfer of activation backwards to a "pre" concept. However,
the "pre" item was replaced at one time with "prepsi", so apparently
the backwards activation code is not being operated. We may need
to test for a positive "prepsi" instead of a positive "pre".

We go into the local, pre-upload version of the Google Code MindForth
"var" (variable) wiki-page and we add a description for "prepsi",
since we are just now conducting serious business with the variable.
Then in the MindForth SpreadAct module we switch from testing in vain
for a positive "pre" value to testing for a positive "prepsi".
Immediately our diagnostic messages indicate that, during generation
of "KIDS MAKE ROBOTS" as a response, activation is passed backwards
from the verb "MAKE" to the subject-noun "KIDS". However, SpreadAct
does not seem to go into operation until the response is generated.
We may need to have SpreadAct operate during the input of a verb
as part of a query, in a chain were ReActivate calls SpreadAct to
flush out potential subject-nouns by retro-activating them.

4 Sat.30.JUN.2012 -- Approaching the "seqneed" Problem

As we search back through versions of MindForth AI, we see that
the 13 October 2010 MFPJ document describes our decision to stop
having ReActivate call SpreadAct. Now we want to reinstate the calls,
because we want to send activation backwards from heavily activated
verbs to their subjects. Apparently the .psi position of the "seqpsi"
has changed from position six to position seven, so we must change the
ReActivate code accordingly. We make the change, and we observe that
the input of "What do kids make?" causes the .psi line at time-point
number 449 to show an increase in activation from 35 to 36 on the
#72 KIDS concept. There is such a small increase from SpreadAct
because SpreadAct conservatively imparts only one unit of activation
backwards to the "prepsi" concept. If we have trouble making the
correct subjects be chosen in response to queries, we could increase
the backwards SpreadAct spikelet from one to a higher value.

Next we have a very tricky situation. When we ask, "What do kids make?",
at first we get the correct answer of "Kids make robots." When we ask
the same question again, we erroneously get, "Kids make kids." It used
to be that such a problem was due to incorrect activation-levels,
with the word "KIDS" being so highly activated that it was chosen
erroneously for both subject and direct object. Nowadays we are
starting with a subject-node and using "verblock" and "nounlock"
to go unerringly from a node to its "seq" concept. However, in this
current case we notice that the original input query of "What do kids make?"
is being stored in the Psi array with an unwarranted seq-value of "72"
for "KIDS" after the #73 "MAKE" verb. Such an erroneous setting seems
to be causing the erroneous secondary output of "Kids make kids."
It could be that the "moot" system is not working properly. The "moot"
flag was supposed to prevent tags from being set during input queries.

In the InStantiate module, the "seqneed" code for verbs is causing
the "MAKE" verb to receive an erroneous "seq" of #72 "KIDS".
We may be able to modify the "seqneed" system to not install
a "seq" at the end of an input.

When we increased the amount of time-points for the "seqneed" system
to look backwards from two to eight, the system stopped assigning
the spurious "seq" to the #73 verb "MAKE" at t=496 and instead
assigned it to the #59 verb "DO" at t=486.

5 Sun.1.JUL.2012 -- Solving the "seqneed" Problem

After our coding session yesterday, we realized that the solution
to the "seqneed" problem may lie in constraining the time period
during which InStantiate searches backwards for a verb needing a
"seq" noun. When we set up the "seqneed" mechanism, we rather
naively ordained that the search should try to go all the way back
to the "vault" value, relying on a "LEAVE" statement to abandon
the loop after finding one verb that could take a "seq".

Now we have used a time-of-seqneed "tsn" variable to limit the
backwards searches in the "seqneed" mechanism of the InStantiate
module, and the MindForth AI seems to be functioning better than ever.
Therefore we shall try to clean up our code by removing diagnostics
and upload the latest MindForth AI to the Web.

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