Eighth Annual Microprocessor Workshop on Microprocessor Applications, Leed, 1985, pages 1-11
A Microcomputer Package for demonstrating Information Processing Concepts
by
C. F. Reynolds
Department of Computer Science Brunel University Uxbridge, Middlesex
Introduction
One of the problems of the typical school microcomputer is that the most accessible language is BASIC. Unfortunately this language is not suitable for demonstrating modern information processing concepts. This paper describes a package, called MicroCODIL, which has been developed for the BBC Microcomputer. This is based on the main frame CODIL system which has been used for a range of teaching and "knowledge base" applications. The flexibility of the approach is demonstrated through two applications. The first involves a-level Chemistry while the second shows how invoicing can be done on an individual contract basis.
CODIL and MicroCODIL
The main frame version of the software (Reynolds 1971a. 1971b, 1974, 1978a, 1981, 1984a, 1984d) now runs on a Honeywell Multics computer (and other systems). The object code and the normally allocated workspace total about 250K bytes and it would obviously have been impractical to transfer it into the 25K bytes of available space on a BBC microcomputer without modification. In addition the BBC system would need to work with between l00K and 800K bytes of disc storage. On the other hand the main frame system is seriously limited by the need to support a sequential "teletype" interface.
In these circumstances it was decided to carry out a complete redesign process. The logical information structures and the ability to handle "messy" data have been transferred and even extended with the incorporation of automatic probability processing and a backtracking capability. The control structure has been improved by discarding features that were only in the main frame version to maintain compatibility with earlier versions of the software. However the biggest changes involve the user's view of the system and, by using windows, colour, and other techniques, significant improvements have been made. The emphasis in the initial version of MicroCODIL has been on demonstrating various ways in which information can be processed.
Package description
The package has been designed to work best on a BBC Model B microcomputer with discs and either a colour monitor or domestic: television set. An introductory guide is provided which describes each facility in the context of modern information processing. Because of the size of the help file and the number of demonstration knowledge bases included, the current trials system works best with 80 track discs, although single applications can be run from a single 40 track disc. With certain restrictions - particularly on the use of help and indexed files - it should be possible to run teaching applications without discs, although a disc of some kind is virtually essential for developing such an application.
The "front-end" program, CODIL, introduces MicrclCODIL, loads a small assembly code module, and calls a second program which displays a menu, loads the selected knowledge base, and the appropriate version of the MicroCODIL interpreter. Pressing the <:ESCAPE:> key loads the "UTILITY" menu - giving access to file handling and other facilities. These include the option of adding routines which provide spelling checking, probability processing, and the incorporation of music into the knowledge bases.
The User Interface
The most important aspect of any system is its user interface. Conceptually MicroCODIL is well suited to make the most of windows. Hardware constraints - in the form of limited memory and the 40 by 25 characters of a screen full of teletext characters - restrict what can be done. For this reason the screen is divided into three window areas plus some control information. The main window consists of 15 lines and may be dynamically selected by the user. The alternatives are described in detail below. Below this there is a three line message window which is used by the software to display error messages, etc.
At the bottom of the screen three lines provide a scrolling input buffer. This normally displays the last two lines input, and echoes the line currently being typed in. An unusual feature is the use of colour to indicate the interpretation the system places on the input. For instance items names are echoed in light blue, qualifiers in dark blue, and the item value in white. This has been described in detail elsewhere (Reynolds, 1984c). The input window can also be used to report normal processing, when it scrolls the items being processed as if they had been typed in from the keyboard. The rate at which this is done is controlled by the REPORT command, the value of which gives the step "delay". By setting a long delay time the system can be single stepped under user control, while a zero value suppresses the reporting and allows the system to run at maximum speed.
The Main Windows
The user may dynamically select nine windows to view through the main fifteen line area of the screen. Each will be briefly described in turn. Selection is by pressing the number keys as the task in hand runs. Alternatively the user may call the windows by name while in direct input mode.
The main system work area is called the "Facts" and the contents are displayed in the Facts window. The Facts are the computer equivalent. of human "short tenn memory". The number of items in the area is strictly limited to fifteen as much as anything so as to avoid swamping the user with information. To supplement this a "FiIe" Window is used to show the statements currently being read from files as "data". In addition there is a "Global" window which contains any permanently declared variables.
Information processing involves the scanning of a tree of logical conditions and commands. The "Trace" window provides an instantaneous answer to the question "How did I get here" and, if used as the task runs, dynamically shows the decisions and actions being: carried out by the system. Limited monitoring of the information being written to file is also provided in another window..
The "Display" window is used to format te:x for display purposes and limited tabulation and similar facilities are provided. The window is often used to hold the initial instructions to the user and so, when the window is not empty, this is the first one seen by the MicroCODIL user an entering a Knowledge Base.
In addition there are three "scrolling" windows which may be called either by name, or by pressing a numeric key. They revert to the Facts window when the user has finished with them. The "names" window gives a list of the item names known to the system, using colour coding to highlight file and system names. (An extended version of this, which shows all the properties associated with each name, is available via the UTILITY program.) The "list" window is used to list a file in the window. The "help" window uses an indexed help file to give textual descriptions of MicroCODIL, its system words and symbols, and various notes for guidance.
CODIL & MicroCODIL Applications
CODIL has been used to handle a wide variety of information including biological field data (Reynolds, 1971c), medical reccords (Neal, 1977; Ohiorenoya, 1984; Reynolds, 1978b) ~ historical information (Reynolds 1979) and records about science in schools (Johnson, 1982). It has also been used in undergraduate teaching (Reynolds, 1981, 1984b). CODIL has also been used to implement a fully interactive paper which allows the reader to run the software the paper is describing (Reynolds, 1983)
MicroCODIL has been tested on a number of applications although, at the time of writing it has not been used operationally. Following the success of the interactive "Teach Yourself CODIL" lessons (Reynolds, 1976) the MicroCODIL help files have been set up on a two level basis. The use of the help files to provide interactive lessons on the non-procedural use of a French-English dictionary are described elsewhere (Reynolds, 1984a)
In addition to the French-English dictionary a number of other school teaching examples, covering simple set theory, information retrieval, and the random generation of English text, have been converted from the main frame system. A demonstration historical knowledge base has been set up, combining information from census returns, parish registers, trade directorie, wills, etc.. This is based on information in the main frame CODIL files which currently contain over 3 million bytes of information on nearly 6000 individuals. However two knowledge bases "Invoices"11 and "Solids" are of particular interest and are described below.
The "Solids" Knowledge Base
The "Solids" Knowledge Base contains informati n taken from a O-levE'1 text book, (Lewis, 1980) and describes the properties of a dozen materials which were selected to show a variety of properties. While the Knowledge Base could be used to help teach O-level chemistry the files have been set up to show how poorly structured information crops up in commonplace situations, and to demonstrate how MicroCODIL can handle it. To help the user who is new to MicroCODIL a simple SEARCH routine has been included in the Knowledge Base. Various topics are discussed in turn.
Variability of Structure: On the main file, SOLIDS, the properties of Lead are given as:
1 CHEMICALNAME = Lead,2 USE = roofing,3 COLOUR = grey,4 HARDNESS = 1,5 MELTINGPOINT = 327
while the properties of Diamond are given as:
Copper Sulphate is described as:
Notice that the descriptions of each material are similar in structure but are not identical. Some item names occur in all three statements, but, for example, no MELTINGPOINT is given for Copper Sulphate because it does not melt. A particular item name may occur more than once in a given statement and Diamond has three quoted USEs while Lead has only one. The HARDNESS of Copper Sulphate is given as a range. Such variety of structure reflects the variations to be expected in many real world situations which have not been "restricted" by the requirements of statisticians, accountants or conventional computer systems. Obviously the approach can be used for such well structured data, and if this is done MicroCODIL can be used as a Relational Data Base (Omrani, 1979; Reynolds 1978c, 1984d)
Set Matching: Conventional programming languages compare items by directly comparing item values. MicroCODIL makes comparisons at the set level and each item is treated as a partition of the set identified by the item name. This can be seen by a number of examples. For instance a search for
USE = grinding
matches Carborundum (which only has one USE) and Diamond (whose three USEs are given above). A search for
HARDNESS = 3.5
matches Copper Sulphate, with a HARDNESS between 3 and 4. It should be noted that the query refers to a precise value while the data being searched represents the range. MicroCODIL will al so handle the converse "conventional" query where the query specifies the range and the data gives the precise value. The whole or null set can also be searched for. A search for MELTINGPOINT will find Diamond, Lead, and others, while a search for MELTINGPOINT <>,the null set, finds Copper sulphate and Washing soda.
Naming items: In order to allow users to give items meaningful names MicroCODIL item names can be up to 16 alphabetic characters long. However abbreviations may be defined by, for instance:
MP (SYNONYM) = MELTINGPOINT.
The (ISA) definition is more powerful and because
CHEMICALNAME (ISA) NAME.
it is possible to ask questions about CHEMICALNAME = LEAD and NAME = LEAD when the statement only contains the former item. Materials with the same CHEMICALNAME and NAME can be identified by using the expression evauation
CHEMICALNAME := NAME.
By convention all item names which do not have a (SYNONYM) or (ISA) defined default to (ISA) - FACTS.
Automatic Indexing: MicroCODIL files may be logically "indexed" on the leading item of a statement and the larger ASCI files on the disc: may be physically indexed as well. The effect of using a (KEY) is to provide a "window" onto the file. Whenever the file is accessed the system checks to see if a value for the key currently exists. If it does only the appropriate subset of the file is retrieved. For instance the file SOLIDS is indexed by NAME using:
SOLIDS (KEY) = NAME.
and listing the file when the Facts contain the item NAME = Sulphur results in the following statement being listed:
Files as Conditions: Any MicroCODIL item may be used as a search term, including files. For instance the file CONDUCTOR contains the three items:
1 NAME - Aluminium.1 NAME - Copper.1 NAME = Lead.
and if the Facts contain any of these items then CONDUCTOR? is true. In the same way the file GENTLEHEATING contains, the information
1 GENTLEHEAT = burns,2 NAME = Sulphur.1 GENTLEHEAT = crackles,2 NAME =Copper sulphate.2 NAME = Washing soda.
and if the Facts contain any appropriate pair of items the condition GENTLEHEATING? will be true. The process will be simplified if the file has GENTLEHEAT as its KEY.
String Matching The MicroCODIL system provides a mechanism for comparing values at several levels. If both values to be compared can be interpreted as a number (BBC Basic format) numeric comparison is carried out. If not the default is to compare the values as character strings from left to right ignoring case. Two qualifiers can be used. (START) checks the first characters only, while (STRING) searches the value looking for a match. For example a search for
NAME (STRING) = Sulph
will match with Sulphur and Copper sulphate.
It is possible to add new facilities into MicroCODIL using the EXPAND program. These include (MAXIMUM), (MINIMUM), (MEAN) and (SUM) which examine multiple items and returns an appropriate value. In addition (SPELL) provides a matching function for similar character strings. If this facility is used searches for Coper or Sulpher will match up correctly.
Fuzzy Matching: A combination of exact matching plus string matching extended over the members of a set provides a powerful tool but still does not cater for every situation. The user will, quite rightly, want to ask for information on:
MELTINGPOINT = low
This can be arranged by using a file such as MELTS:
1 MELTINGPOINT = high,2 MELTINGPOINT > 1500.1 MELTINGPOINT = medium,2 MELTINGPOINT > 200,3 MELTINGPOINT <= 1500.1 MELTINGPOINT = low,2 MELTINGPOINT <= 200 .
This file is indexed by MELTINGPOINT and is also linked to MELTINGPOINT with the definition
MELTINGPOINT (CONDITION) = MELTS.
It is not appropriate to discuss the full implications of the (CONDITION) qualifier in this paper". Suffice it to say that if a conditional test involving MELTINGPOINT is false the test is repeated using the file MELTS indexed by the desired value. This means that a search for MELTINGPOINT = low produces Candlewax, Moth-balls and Sulphur. The approach may be extended to involve any MicroCODIL facilities, and may be used recursively with care. For instance a search for:
HAMMER = Breaks
produces a list of answers because the file HAMMERING includes:
1 HAMMER = breaks2 NAME = Moth-balls.2 HAMMER = crumbles.2 HAMMER = powders.2 HAMMER = shatters.1 HAMMER - crumbles,2 NAME = Candlewax.1 HAMMER = powders,2 NAME - Sulphur.2 NAME = Washing Soda.1 HAMMER = shatters,2 NAME = Copper sulphate.2 NAME = Salt.
Probability Processing Another form of uncertainty that can occur in real information relates to probability. Items of information in MicroCODIL may have probabilities associated with them and these are compounded in an appropriate manner if several probabilistic comparisons are carried out. However there is no opportunity to demonstrate this within the SOLIDS Knowledge Base.
The "Invoices" Knowledge Base
The SOLIDS Knowledge Base is concerned the retrieval of information.. The INVOICES Knowledge Base is concerned with the logical processing of an order to produce a price for goods sold. The key to the approach relates to the nature of a sales contract. Basically a sales contract is a legal "algorithm" describing conditions and actions relating to the delivery and pricing of goods. The conventional computer approach takes "standard" contracts and reduces them to tabular data plus a completely separate program, ignoring the problem of non-standard contracts. This works well in a comparatively simple marketing situation where expanding trade allows the seller to offer goods on a "take a standard contract or :leave it." basis.
MicroCODIL allows a sales contract to be represented on the computer in a way which reflects the salesman's view of the problem. For instance one of the petrol stations in this demonstration knowledge base has the contract:
1 CUSTOMERNUMBER = 54321,2 BRAND Bestrol,3 REBATE = 3.2 BRAND = Premitrol,3 REBATE = 2.2 BRAND = SuperDERV,3 REBATE = 3.2 BRAND = Slipwell,3 PACK = 25 litre drums,4 REBATE = 6.2 BRAND = Flushout,3 DELIVERYMETHOD = Collected,4 DISCOUNT = 5.
This file may be created, interrogated and updated in just the same way as the SOLIDS file described earlier. In addition the file may be used as a set of production rules. This means that the first statement can be considered as being the equivalent of the COBOL statement:
IF CUSTOMERNUMBER = 54321 AND BRAND = "Bestrol" MOVE 3 TO REBATE.
In the case of the BRANDs Slipwell and Flushout information is required on the PACK and DELIVERYMETHOD respectively, and if this information was not typed in with the order the customer would pay more than he should. To overcome this danger the item names have been given additional properties such as:
DELIVERYMETHOD (CONDITION) = QUERY.
When a contract needs a value for the DELIVERYMETHOD, and no such item has been typed in, MicroCODIL automatically prompts the user when the appropriate condition is being evaluated. Not surprisingly the prompt will take the form:
DELIVERYMETHOD = Collected?
and the user may respond with true, false or = alternative value. In the case of DELIVERYMETHOD (and most other item names) a simple PICTURE has been defined to limit the input format, and the user is shown this format as well as the prompt and the true/false instructions.
By setting up a number of files~ such as CONTRACTS, BRANDPRICES, VOLUMEALLOWANCE, PETROLDUTY, etc. it is possible to build an invoicing system where all relevant information is held in a way which is readily understandable to the salesman. Any (or every) customer- may have an individual contract at the discretion of the sales organization at the time they want it. Conceptually there is no need to get the blessing of the systems department, or to wait for weeks for a program to be amended. In addition the self-documenting nature of the system minimizes the amount of documentation required.
Conclusion
The MicroCODIL package provides a user friendly framework for setting up and running applications which demonstrate various aspects of modern information technology without the need for the student to know about procedural languages. The recursive structure makes it possible to avoid the use of the nested brackets which characterize better known languages.
References
Johnson, S, & Maher, B. (1982) "Monitoring Science Performance Using a Computerized Question Banking System" Brit. J. Educational Technology, Vol 13, 97-106.Lewis. M, & Waller, G (1980) "Thinking Chemistry", Oxford University Press.Neal, L R. (1977) "The Computer Handling of Medical Information for· Research Purposes"~ Proc. Medinfo 77~ 651-655.Ohiorenoya, M A, (1984) "A Study of the Representation, Storage and Retrieval of PoorIy Structured Medical Data", Ph.D. thesis. Brunel UniversityOmrani, D, (1979) "Some Studies of the Relational Model and the CODIL Language", Ph.D. Thesis, Brunel University.Reynolds, C.F. (1971a) "CODIL, Part1, The Importance of Flexibility", Comp. J,. Vol 14, 217-220.Reynolds, C.F. (1971b) "CODIL, Part2, The CODIL Language and its Interpreter", Comp. J., Vol 14, 327-332Reynolds, C.F. (1971) "Handling Cave Fauna Data on a Computer", Trans. Cave Res. Group, G.B., Vol 13, 160-75Reynolds, C.F. (1974) "Designing an Interactive Language for the Pragmatic User", Proc. European Computing Conference, London,991-1006.Reynolds, C.F., (1976) "Teach Yourself CODIL", Technical Note, Brunel University. (An updated version of these interactive lessons is available with the CODIL software.)Reynolds, C.F., (1978a) "A Psychological Approach to Language Design", Proc. Workshop Computing Skills and Adaptive Systems2 LiVerpool, 77-87.Reynolds, C.F., Sutton, G, & Shackel, M. (1978b) "Using CODIL to Handle Poorly Structured Information", Proc. Medical Information, Europe, 465-474Reynolds, C.F., & Omrani, D., (1978c) "Formalism and Flexibility", Proc. Int. Conf. Cata Base Management Systems, 127-138Reynolds,. C.F., (1979), "The Gibbs Family of Aylesbury", Brunel UniversityReynolds, C.F., (1981) "CODIL as an Information Processing Language for University Use", IUCC Bulletin, Vol 3, 56-59.Reynolds, C.F., (1983) "A Software Package for Electronic Journals". Proc. 7th Int. Online Information Meeting, 111-118Reynolds, C.F. (1984a) "MicroCODIL as an I.T. Teaching Tool", University Computing, (in press)Reynolds, C.F., (1984a) "An Interactive Data Base System Desugned to give Terminal Confidence", Computer Human Factros. (This is an experimental electronic journal funded by the British Library.) Reprot CSTR 23, Brunel University.Reynolds, C.F. (1984c) "The Use of Colour in Language Syntax Analysis", Report CSTR 25, Brunel UniversityReynolds, C.F. (1984d) "CODIL as a Tool for Handling Poorly Structured Information", 3rd British National Conference on Databases, Leeds. Report CSTR 24. Brunel University.
No comments:
Post a Comment