Artificial Intelligence For You (AI4U)

Fri.13.NOV.2009 -- CREATING THE FIRST mind.frt FILE

Today we shall try to create a "mind.frt" file that will run in our local copy of 32/64-bit iForth. To do so, we look at C:\Win32For\24may09A.F on the desktop computer, to see what the commented MainLoop looks like. Similarly, for the C:\dfwforth\include\ directory we compose a mind.frt file like the following.

  
: MainLoop 
 CR CR
 TYPE ." Welcome to 32/64-bit artificial intelligence. "
 77 EMIT  7 EMIT  73 EMIT  7 EMIT  78 EMIT  7 EMIT  68 
EMIT   7 EMIT
 CR CR CR
;

At the Forth prompt, we issue the command
include mind.frt
and then
MainLoop [ENTER]
The iForth window displays
Welcome to 32/64-bit artificial intelligence.
and then spells out M I N D with a beep after each letter.

We distinguish this file by saving it as
C:\NOV01Y09\iForth\11nov09QA.frt

Fri.13.NOV.2009 -- ADDING AI FUNCTIONALITY IN A LOGICAL FASHION

Since we already have a functioning AI Mind in Win32Forth, naturally we are keen and eager to build the iForth AI up to and beyond the current functionality of the Win32Forth AI. However, we have never liked to hurry or to rush our AI work. We have always liked to work in a slow, deliberate, perfectionist fashion. It might seems as if right now is a time when rapid prototyping is truly called for, because True AI is so inherently important, but the speed of our work is a function not of non-stop crisis-alarm coding, but rather of congenially and pleasantly coding quite oten because we enjoy and appreciate the challenge.

We are even thinking of making our work somewhat obscure from the often pejorative public, by putting it quietly up on the Web but by not announcing it heavily. For instance, on SCN we could have an iforth.html page linking to a mind.frt source-code page. Since we already have an aisource.html SCN page that receives plenty of visits, we could suddenly fill it with our iForth AI code, once the port is a full- fledged AI on a par with MindForth .

As we plan our next steps in the i4thai coding, we study our 75-page iForth Manual print-out and on page 41 under "Program structures" we learn that iForth has the same BEGIN AGAIN infinite loop that we have been using in Win32Forth for the MainLoop module. However, as advised in http://mind.sourceforge.net/aisteps.html we do not want to run our program without an "ESCAPE" mechanism that will get us out of the program in a graceful fashion. We must either use a different form of MainLoop, or we must include also a user-input that will stop the MainLoop.

We must also soon devise a simple display of user input and AI Mind output.

Sun.15.NOV.2009 -- TWO MODULES AND TWO ESCAPE MECHANISMS

Before we put any "mind.frt" code up on the Web, we want to code in the Escape mechanism from the otherwise infinite loop. We are eager to release some code, because there may be Netizens who will be pleased to observe how the AI Mind grows from the first simple MainLoop into the intricately thinking software. But first we add "DECIMAL" at the beginning of the mind.frt file, because we used the same declaration in Win32Forth. We run the AI, and it works fine.

Next we want to see if we can introduce a first variable, so we examine the Win32Forth code and from the old Listen module we select the "pho" variable for "phoneme", because "pho" must hold any keystroke input. After declaring "pho" and re-running the AI, FORTH> pho @ . 0 ok tells us that the AI still works. Next we declare and test "t" for "time", because we want to use a time count to Escape from the MainLoop.

Now we introduce a colon-defintion of "SensoryInput" above the "MainLoop" module, because we want the MainLoop to branch out into at least one subordinate module. We also want to use SensoryInput to show some human user input and to provide an Escape mechanism from the program.

Gradually we have built up a two-module mind.frt program with two Escape mechanisms. The SensoryInput module lets the user quit by pressing the Escape key. The MainLoop module arbitrarily executes a QUIT if the time "t" variable increments beyond twenty-five (25) as a limit. Now the code is safe enough and promising enough to put it up on the Web as an indicator of progress being made.

Tues.17.NOV.2009 -- TOWARDS CREATING THE MEMORY ARRAYS

We are eager to create the memory channel arrays, in order to see if the array code in iForth needs to differ at all from the array code in Win32Forth.

Now we have edited C:\dfwforth\include\mind.frt and we have inserted the following array code from the 24.MAY.09U.F version of MindForth.

:  CHANNEL   ( size num -< name >- )
  CREATE   ( Returns address of newly named channel. )
  OVER     ( #r #c -- #r #c #r )
  ,        ( Stores number of rows from stack to array. )
  * CELLS  ( Feeds product of columns * rows to ALLOT. )
  ALLOT    ( Reserves given quantity of cells for array. )
  DOES>    ( member; row col -- a-addr )
  DUP @    ( row col pfa #rows )
  ROT *    ( row pfa col-index )
  ROT +    ( pfa index )
  1 +      ( because first cell has the number of rows )
  CELLS +  ( from number of items to # of bytes in offset )
;

We run the mind.frt code just to see if it still runs, and it does indeed run. We do not expect to see any new functionality until we code something that uses an array to store and fetch data.

We coded in the .psi report function, but it did not work right, so we temporarily removed the "enx" code that goes into the aud{ array and displays a word in auditory memory. Then we had to alter the .psi report just to get it to find single letters stored in the Psi array. We ascertained that the Psi array is indeed working, but the .psi report does not always work right.

Fri.20.NOV.2009 -- TROUBLESHOOTING THE .psi REPORT

In our coding of 17.NOV.2009, the .psi report was displaying half garbage and half good data, before crashing more than just coming to an end. It also seemed that an error was being declared in the MainLoop, even though theoretically we were not even running the main loop. So today we will try to troubleshoot the .psi report.

Since the MainLoop was calling only SensoryInput, there may have been a software problem with the loop not really looping. Therefore we shall dummy up one more subordinate module to be called from the MainLoop. Let us try setting up a stub of the ThInk module, since we will eventually have to code that module anyway, by translating it from the Win32Forth AI. We created the following stub of the ThInk module.

: ThInk
  CR
  TYPE ." ThInk: Cogito, ergo sum. " CR
;

We also ported in the TabulaRasa code from Win32Forth, because we were worried that corrupt memory might be interfering with our program. However, apparently the main problem was that our SensoryInput stub was not storing each character of input at an incremented value of time "t", so we brought in the following snippet from the AudInput module of the Win32Forth AI, and inserted it into our SensoryInput stub, with an explanatory comment.

      pho @  0 > IF
        1 t +!  ( to accumulate a word in memory )
      THEN

Now the .psi report had a true series of memory engrams to report, and suddenly it began to work well. We had also rearranged things a little in the MainLoop module, so that our screen display during operation looked more sensible. We saved the mind.frt program as 20nov09A.frt because we suddenly had not only a stable program as a whole, but also the .prt report seemed to be working well. We always need to hang onto a good version of our AI, lest we continue coding with the misfortune of making things worse.

Some of the temporary code snippets that we inserted merely in order to test things, will have to be taken out as we continue to port the Win32Forth AI into iForth.