Expert Systems - Part 1|The Amstrad User)Expert Systems - Part 2|The Amstrad User)
★ Ce texte vous est présenté dans sa version originale ★ 
 ★ This text is presented to you in its original version ★ 
 ★ Este texto se presenta en su versión original ★ 
 ★ Dieser Text wird in seiner Originalfassung präsentiert ★ 

Paul Gerard considers a conversation with "Eliza" and provides some new listings too!

Last month, I failed to include one famous definition (just so I could say that I had written at length about AI without mentioning it) that you have probably heard of before. This originated in 1950 with an English Mathematician called A.M. Turing, and is called the 'Turing criterion". Turing postulated that if a person communicating with a computer could not tell whether there was a computer or a person at the other end of the line then the computer's output, and therefore the computer itself, was "intelligent". (Those of you to whom "computer" means something like a CPC may need reminding that this was back in the dark ages when one's VDU - if one had such a luxury - was connected to a more or less distant computer at the other end of a phone line).

This definition is not as bad as you might think at first glance, in fact it encapsulates quite a bit of what I said last month. An "intelligent" computer (or, if you like, an "intelligent" program) ought to respond more or less as an intelligent, helpful person might. Turing correctly identified the actual result, that is the output, as the criterion by which the computer's intelligence is to be judged, not a theoretical examination of the logical validity of the algorithms it used to arrive at its conclusion, nor an analysis of how closely it duplicated human thought processes.

Actually, since Turing's day menu and icon systems of program control have come so far that we might question whether a computer's ability to understand "natural language" (i.e. ordinary English, Russian or whatever) is an essential feature of computer "intelligence" or not. A menu system is almost certainly the best way to "drive" a simple program like "Structured Data"; and a complicated "Mac-style" icon system can surely be "intelligent" too - however we will assume, at least for the time being, that "natural language" input has real advantages for an intelligent program.

Now the ultimate artificial intelligence would no doubt be a generalist, and be able to converse on any subject - for practical purposes however we are more likely to be able to achieve a specialist, with a rather narrow area of expertise. This kind of thing is called an "expert system".

The crudest possible form of this would be something like "Eliza". This program (a version of which, written by me, appeared in an early TAU) follows the psychoanalytic theories of one Carl Rogers - the principle elements of which are, conveniently for our purposes, lack of value judgements and avoidance of premature, "canned" solutions. This "accepting", neutral technique can theoretically be duplicated by limiting the program to a syntactical analysis (with little or no attempt to deduce "meaning") of the user's input. If you have ever played with Eliza you will realise that she is very limited, and that you would not take very long to determine that whatever you had "at the other end of the line" was certainly not an intelligent person! To be fair, she was written very much with tongue-in-cheek, and her creator (one Joseph Weizenbaum) was quite shocked to find how seriously she was taken; but the basic trouble with Eliza (as an "intelligence" rather than a joke) is that she attacks the problem from the wrong end. Computers are good at storing and retrieving information (an essential function of "intelligence") while Eliza has no meaningful information to impart at all, only an elaborate set of "keys" which trigger pre-set responses. We will be using a rather Eliza-like (or, if you like, adventure game-like) parser to allow natural language input, so as to try to satisfy the Turing criterion, but the really intelligent part of the program will lie elsewhere, in the way we manipulate stored data.


I have to assume here that you have your copy of "Structured Data"- either built up as you followed the last series, or acquired "complete" in the last couple of months. Now as I warned you, our "expert system" is going to use a lot of the routines from the older program. The fact that we can do this so easily is, of course, one of the best features of a thoroughly structured approach to programming. As 1 said last month, if you want to follow this series in any practical way and you don't have a copy of this program (let's call it "SD" in future) then you will have to acquire one. We don't have the space to re-print each routine in its entirety here, but I will indicate line numbers, variables and the function of each routine. Locate each one of these in your copy of SD, and save it separately (by deleting the lines you don't want). If you have a CPC464 with a DDI this will have to be in the form of an ASCII file, thus:


as otherwise they will refuse to merge - a CPC664 or CPC6128 does not suffer from this "bug" and the file can be saved as a normal BASIC file, thus saving a little disc space. You will note that 1 suggest using the file extension '.LIB". This indicates that you are building up a "library" of BASIC routines that will prove useful in many of your programs. What you call each file I leave up to you, although you will find that descriptive names will save bother late on!

When all of the routines are on a disc (or discs) merge them all together and save the result as "EXPERT.BAS". It will not run in its own right just yet - have patience and this will be rectified.

These are the SD routines you will want:

(a) The "heading" routine (lines 100-190). This prints one of a number of alternative headings, all nicely centered regardless of the screen mode we are in at the time. The user defined function "FNcentre" is of course defined elsewhere, as is the array heading$(n). To print heading number three (for instance) from our list we call this routine as follows:

head=3:GOSUB 100

(b) The "input" routine (lines 200-290). For those of you who joined us since the first few articles in the last scries - this routine gets around the various quirks of the INPUT command in BASIC. In particular we can look at each character as it is typed in and decide if we want it to be part of our input. Thus we can have the computer accept only numeric input (for instance), or only "Y" and "N". Variables used by this routine which must be set up elsewhere are byteS (as you might expect, a single character string), and user.input$ (a string of 254 characters). We also need an array of strings called control$(n), which contain sets of "legal" characters for different types of input. In case this seems a lot of string space to take up, notice how all string values are changed with MID$, thus actually saving string space in the long run. The routine is "called" with a line like this:

caps=TRUE:control= 1 :length= 1 :GOSUB 200

This indicates that all input is to be converted to uppercase, that the legal characters are selected from control$(1), and that the length of the input is to be restricted to 1 character. Output from the routine is identified by LEFT$(user.input$(length)).

(c) The "clear memory" routine (lines 300-390). This is fairly self explanatory - it simply induces a "garbage collection". The call of GOSUB 700 (our general "pause" routine) ensures that the computer pauses long enough for our user to read the "please wait" message, even if the garbage collection itself only takes a fraction of a second.

(d) The "record display screen" routine (lines 400-490). This sets up a neat mode 2 screen that is nice for inputting and displaying data.

(e) The "yes/no" routine (lines 500-590). This gives the user a simple yes/no choice.

(f) The "mode change" routine (lines 600-690). As well as changing the screen mode, this routine sets a variable (modewidth) corresponding to the number of characters wide the screen is in each mode (20,40 or 80), and also sets up some standard windows.

(g) The "pause" routine (lines 700-730). This is self explanatory - although note the use of the real number indicator (!) for the variables pause! and t!. This is necessary because we have set up all variables to default as integers with DEFINT a-z in our initialisation. A case of one or two "!'"s saving hundreds of "%"'$!! (If you don't know what I am talking about try to get hold of TALI for August 1988 and read my article there, where all is made clear).

(h) The "press any key to continue" routine (line 800-890).

(i) The "menu" routine (lines 2000-2170). We will be keeping this mainly as a kind of backup for the confused user rather than the "primary driver" that it was in SD. All menu options, as well as the lengths of the menus and their starting points in the master list are all kept in master arrays set up when the program is initialised. This is why we can use this same routine for any program using menus!

Cot all those saves and merged? Now as I said, these will not run just yet, as we need to set up a main program loop, as well as the initialisation routine and one or two other odds and ends. The following pieces of code all differ, in major or minor ways, from the corresponding lines in SD, although you may find it easier to edit the SD lines rather than type the whole thing in from scratch.

You will notice that I have incorporated the "command" structure we discussed last month into this program. We may change this a bit to make it even more flexible, and we will certainly be adding and changing a fair few of the DATA lines, but apart from that THIS PROGRAM IS FINISHED. The reason it won't actually do anything yet lies in line 80.

(80 CHAIN MERGE choice$(choice),3000,DELETE 10000-)

With this line we move into the area of overlays. You may have run some CP/M programs that use this technique - every now and then the disc drive buzzes and the program pauses for a moment before continuing. What happens is that when an option has been selected, either through the command structure or from the menu, then a subprogram is loaded into memory, MERCED with the current program, and run. All our current variables remain, and we can get rid of all the initialisation lines that we will never need to use again. The advantage of the whole exercise is, of course, that we will be running a smaller program and thus have more room for data. This is essential for this particular application, as cach "function program" is likely to be rather large, and we are probably going to have a fair bit of data. Apart from those 'little" pauses while pieces of subprogram are loaded the drawbacks (dare one call them bugs?) in the whole business is that we lose all our user defined functions, and any current loop or GOSUB nesting. There is also, intriguing, an open input file which must be closed before we try to do anything with files. These quicks arc easily enough accommodated -you will notice that line 3010 is a CLOSEIN, and we have moved our functions to a separate routine (at 900) where they can easily be recovered. The last line of each subprogram will need to be GOTO 90 rather than RETURN, but this needn't worry us too much either. Generally it should prove to be an interesting way of maximising the use of our RAM -1 say "should" because I have not used this particular technique in BASIC before myself (!) and we will be "learning together"!

For an initial trial of "EXPERT.BAS", save the following very similar programlets as SETUP.BAS, TEACHER.BAS and ENQUIRE.BAS. 

These are "stubs" which will not actually do anything except tell us what they are going to be when they arc finished. They are NOT a waste of time, however, as they enable us to test the main or "control" program calling them (see the article in the March 1989 TAU).

See you next month!


★ YEAR: 1989
★ AUTHOR: Paul Gerard


» Expert  Systems    LISTINGDATE: 2013-07-20
DL: 51 fois
SIZE: 611Ko
NOTE: 6 pages/PDFlib v1.6

Je participe au site:
» Newfile(s) upload/Envoye de fichier(s)
★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

» Applications » Menu Para Disco
» Applications » Graph Plotter
» Applications » Generador de Caracteres / Character Generator
» Applications » Calculatrice de Poche (CPC Revue)
» Applications » Inlay-Print (Amstrad Computer User)
» Applications » Pagination Assistee Par Ordinateur


L'alinéa 8 de l'article L122-5 du Code de la propriété intellectuelle explique que « Lorsque l'œuvre a été divulguée, l'auteur ne peut interdire la reproduction d'une œuvre et sa représentation effectuées à des fins de conservation ou destinées à préserver les conditions de sa consultation à des fins de recherche ou détudes privées par des particuliers, dans les locaux de l'établissement et sur des terminaux dédiés par des bibliothèques accessibles au public, par des musées ou par des services d'archives, sous réserve que ceux-ci ne recherchent aucun avantage économique ou commercial ». Pas de problème donc pour nous!

CPCrulez[Content Management System] v8.7-desktop/cache
Page créée en 095 millisecondes et consultée 843 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.