Brain Storms - 10
I often get asked why I
suggest that there is something special about CODIL and the
easiest way to explain it is to discuss the use of models to
represent real world information. My scientific training was in
the field of chemistry – with a particular interest in the the
theoretical prediction of chemical properties. As a chemist I was
very used to having a range of modelling techniques to chose between.
None of the models did
everything – and different types of model served different
purposes. If you had a problem and found the model you were using was
inadequate it was quite natural to look to see if a different model
was available – or whether you could find a better way of
representing the problem.
Instead of thinking about
chemical compounds let us think of the problem of modelling the
processing of information and what the options are. Of course
computers allow us to build a great variety of information processing
models – but all reduce to the same model at the “atomic” level.
Normally this is described as an array of numbers (the data) plus a subset of
which are interpreted as a program, which uses numbers to address the
array. However there is one essential component is usually overlooked
in theoretical discussions by which needs to be considered in the
general case. This is the intelligent human designer who constructs
the program. In many cases the resulting working model may also need
to interact with other humans – who provide or use data operated on
by the program. This post is concerned with information models that include human involvement.
So let us consider a vast
application which seems almost impossible to implement and consider
it in the light of the extended model which includes human designers
and human users operating in a dynamic real world context. As I live
in England the obvious area to chose is the attempt to provide a
single integrated system to handle patients, their records and their
treatments in the National Health Service.
For a perfect system
– which could cope with every eventuality one would need to know
all the possible types of information generating events that
could take place, such a doctor prescribing a drug, a
patient undergoing an operation, an epidemic among medical staff, the
report of a new resistant bacterium, the introduction of a
fundamentally different type of diagnostic equipment, the decision
not to spend money of preventative treatment due to shortage of
funds, a major release of radioactivity affecting thousands of
people, a government decision to change the way services are
managed, etc., etc., etc.
Of course we will never have a perfect system as we don't have
infinitely intelligent human designers with total knowledge of all
possibilities – but if we did we would find some types of events
occurring a million times or more a day, while there might be a
million freakish but theoretically possible events which individually
might only occur once in a million years. We are faced with making
resource controlled compromises in what matters is whether the number
of times a type of event occurs is sufficiently high to justify the
costs of the human designer identifying the event and specifying how
it is to be handled. These costs will need to include the training
costs of the users of the system, and reflect their ability to work
with it. Once you have a working system there will be events which
occur that were not catered for and possibly not anticipated. In some
cases it may be easiest to simply ignore the unexpected, but in other
cases action may be needed which have to be undertaken outside the
system – as the whole “black box” design of stored program
computers means that there is no way there can be useful interaction
between the user and the system once the task moves outside the
predefine boundaries.
So back to the original
topic of models. Is there an alternative information processing
model which reduces the need for prior knowledge and pre-definitions
(reducing the costs of gathering and recording such information)? Is
there also a model which allows the system and its human user to work
together symbiotically when faced with a situation neither had
anticipated?
As far as I can see
no-one ever set out to do the relevant blue sky research in the early
days of computing. Immediately after the war it was clear that there
was a very large market for programmable electronic calculating
machines. There was a mad rush among researchers and manufacturers
to be among the first to exploit the new technology – and anyone
who stopped to "waste" time consuming basic research would be left out in
the rat race for prestige and money in the new invention. A continual
stream of faster processors and larger memories made it easier to
write bigger and bigger programs without stopping to ask if bigger
automatically meant better. By the 1960s Xerox Parc was asking how to help the human user and they took is as self-evident that the
stored program computer architecture was the place to start – and to be fair they did a good job in trying to hide some of its inadequacies.
But if you stop to think
about it there must be a fundamentally different model because nature
got there first. A human baby must start of with no advanced
knowledge of the world yet it can bootstrap itself up to become a
significant information processing machine.
This is where my work on
CODIL comes in. Before I joined Shell Mex & BP in 1965 I had been
concerned with the problems of handling very complex information
manually and using it to provide a manual management information
service. I was well aware that situations could arise that no-one had
anticipated and that sometimes these “exceptions” were of vital
importance to the future of the company. My first experiences with
the massive SMBP computer operations mad me realise that most of the
problems were due to communication failures between the management
and the computer. This meant that when I was asked to look at their
complex sales contracts system my design priorities were to provide
good two-way communication between management
and the computer, coupled with dynamic flexibility in dealing with
sales contracts in an ever changing market place. The very idea that
anyone would try and pre-define all the possible types of sales
contract never occurred to me, and I was unaware that such a
pre-definition was what everyone in the industry was expecting me to
do. Pre-definition not only defines what you can do – it also puts
rigid limits on what you can't do – and I believed that giving
management the maximum flexibility to act quickly and decisively was
of paramount importance. (More information on what I proposed.)
I then moved to English
Electric Leo Marconi to look at what top of the range computer users
would want to buy in a few years times – and after a few months
drafted a note suggesting a rethink about the computer processor
architecture needed for complex real world taks involving human
interaction. The idea was backed by Pinkerton, Caminer and Aris and
the CODIL project is born. Papers describing the project are listed
elsewhere, but the important differences (looking at the
project in retrospect related to the question:
Which came first,
the program or the data?
- Conventional programming involves a top down approach where one starts with a global definition ot the task in hand- putting "the program" first. CODIL is a bottom up approach starting from the individual transactions and uses a very simple algorithm to make deductions from the information it has (in conventional terms generating micro programs on the fly). In effect if puts the "data" first although it is better simply to drop the distinction. To someone used to conventional programming it sounds impossible – but it demonstrably works!
- Conventional programming works with numbers – and data is, at the lowest level – addressed by number. CODIL works with set names – and all addressing is done associatively by set name, rather than by location.
- The conventional computer architecture is a black box while CODIL provides a white box approach which allows it to communicate with users in the appropriate application terminology at the (conceptually) hardware level
Unfortunately the work
was axed without proper assessment when ICL closed the English
Electric Leo Marconi Research Labs in 1970 but continued, with inadequate funding
or support for some years. By 1980 it was taken to the point where it could be used
to support interactive classes of up to 125 students, and support a number of other applications. In 1985 a well reviewed demonstration version was produced on a BBC
microcomputer (the key code was only a few hundred bytes long because
the underlying idea is so simple) to show that it could be
implemented on a single chip if only money was available. While a
paper describing this stage of research appeared in the ComputerJournal in 1990 the project had already closed
down due to lack of funding and health related reasons - which are also the reason why the product was not actively marketed.
Recently interest in the
research has been revived (but so far with no funding or even a
proper home) and it seems that the model could run on a network of
neurons and might well be a first short at how the human brain
bootstraps itself up and processes complex information processing
tasks. (See earlier Brain Storms)
What
happens next really depends on you ....
If you think the approach is fundamentally wrong please read the reviews to see what a large number of independent people were prepared to say about the system in public - and then add you reactions as a comment. The software is still available if you have access to a BBC computer.
Earlier Brain Storms
- Introduction
- The Black Hole in Brain Research
- Evolutionary Factors starting on the African Plains
- Requirements of a target Model
- Some Factors in choosing a Model
- CODIL and Natural Language
- Getting rid of those pesky numbers
- Was Douglas Adams right about the Dolphins
- The Evolution of Intelligence - From Neural Nets to Language
No comments:
Post a Comment