Computer scientists tend to have very strong opinions about how their
discipline ought to be taught. Some stress the need for rigour, having learnt
that the only means to make a large program work is to build it very, very
carefully. These people tend to believe in MS-DOS, standards committees
and normal office hours. Then there are those who emphasise creative ‘programming
as exploring’, often at the expense of reliability or practicability. These
computer scientists tend to enjoy bands like The Grateful Dead, believe
in the power of computer networks and, despite all available evidence, that
artificial intelligence is going to change the world.

Computer science education has been dominated by the proponents of rigour,
possibly because they are more comfortable sitting on our curriculum committees.
It is because of such people that Pascal is one of the most widely used
introductory programming languages.

In the 1970s, however, Seymour Papert and his colleagues at the Massachusetts
Institute of Technology put up a strong case for introducing the use of
computers through exploratory programming. The language they developed,
Logo, was simple enough for young children to use, but powerful enough to
enable them to express some complicated ideas.

Simply Scheme’s authors are clearly members of the exploratory camp.
One of them, Brian Harvey, wrote a two-volume set on Logo which, I believe,
is the best introduction to programming for children.

In Simply Scheme, Harvey and Matthew Wright employ the same ‘Gosh, that’s
neat!’ approach in a first-year university text. The book uses a variant
of Scheme, a language similar to Logo, to introduce ideas about abstraction,
data structures and recursion. There are examples of all sizes, from three-line
utilities to two whole chapters in which a noughts-and-crosses program and
a simple spreadsheet are constructed. The English is clear, there are lots
of exercises, and the authors’ enthusiasm and sense of humour shines throughout.

All the programs in this book are written clearly and described well.
For the most part, the authors steer clear of ‘clever’ programming tricks.
They also avoid using assignment statements to overwrite the values of variables
until the last section of the book. This might seem strange to someone brought
up on Fortran or Pascal, but is quite natural in Scheme.

Despite the book’s strengths, I object to the disparaging tone Harvey
and Wright use when discussing the rigorous approach to programming, and
its proponents. It reminds me of arguments made 25 years ago that the rules
of spelling and grammar are obstacles to creativity. I believe that you
can introduce programming by using an exploratory approach in the easy-going
environment that Scheme and Logo offer. I do not believe, however, that
this requires you to say, or believe, that more rigorous tools and environments
are somehow soul-destroying.

I was also made uneasy by the way in which the authors have grafted
parts of the Logo language onto Scheme. I do not have any complaint with
the bits they chose (primarily functions to manipulate words and sentences
in a uniform way) but the joins certainly show through. Recommendations
such as ‘Stay away from punctuation and you won’t get in trouble. However,
question marks and exclamation marks are okay’ are clear enough, but are
hardly likely to diminish a student’s belief that programming is a black
art governed by arbitrary, nonsensical rules.

Overall, I enjoyed reading Simply Scheme. I would not use it myself
for teaching at university level, but might turn to it faced with a class
of 16-year-olds.

Greg Wilson is a postdoctoral researcher at the Vrije University, Amsterdam.

The use of mathematically rigorous techniques or ‘formal methods’ to
develop software was the second development. Programmers can now prove their
work is correct mathematically, rather than run a program on a computer
to see if it works and then check back for errors. The third, object-oriented
programming, is a rapidly maturing descendant of the structured programming
that swept computing in the 1970s.

While there are now many interesting books on these subjects, most are
aimed at researchers and graduate students, and are not suitable as undergraduate
texts. An exception is How to Write Parallel Programs: A First Course by
Nicholas Carriero and David Gelernter. It addresses the fundamental issues
in the design of parallel programs in an approachable manner, focusing on
the relationships between the result, agenda and specialist models (paradigms)
of parallelism.

Each paradigm is described, then mapped to an appropriate programming
method. The authors consider the suitability of each technique for various
applications, and explain how to translate between them. A lot of space
is devoted to working through real examples, which gives the reader a firm
grasp of how to use the three paradigms discussed. It is also an excellent
introduction to the language used throughout, C-Linda. Overall, this book
is a good starting point for learning about parallel computing.

Although Introduction to Parallel Computing is not yet on the shelves,
it may well be worth waiting for. The book attempts to cover all important
topics in the field, including the different types of parallel computers,
the different programming systems used on them and different ways of thinking
about parallelism. As a guide to what’s what in parallel computing this
book has no equal at present. Combined with a text focused on a single parallel
system, such as Introduction to Parallel Computing, it would make an excellent
base for any undergraduate course. The book appears in 1992.

Edward Rietman’s Exploring Parallel Processing is also good, but is
not really a textbook. Aimed primarily at the do-it-yourself computing enthusiast,
it introduces many areas in parallel processing clearly, including cellular
automata and neural networks. It also contains numerous references to other
useful texts in every area discussed.

Readers will be less well served by Dieter W. Heermann and Anthony Burkitt’s
Parallel Algorithms in Computational Science. Its first part is a superficial
discussion of how you simulate physical systems on computers, while the
second part is yet another introduction to the computer language Occam,
illustrated by a long (but not very interesting) molecular dynamics program.
Even more disappointing is Geoffrey Fox and others’ Solving Problems On
Concurrent Processors: Volume II. While the first volume was one of the
most important and influential books on the subject in the early 1980s,
Volume II devotes only two chapters (roughly 50 pages) to parallel applications.
We can only recommend it to readers with the patience to read (and type
in) the 500 pages of program listings that make up the rest of the book.

By contrast, Gregory Andrews’s Concurrent Programming is a thorough
exploration of concurrent programming. Subtitled ‘Principles and Practice’,
the book delivers plenty of both. It introduces a wealth of different methods
such as semaphores, monitors, synchronous and asynchronous message passing,
RPC, and rendezvous. At the beginning of his book, Andrews outlines a logical
framework for programming. He uses this in his discussion of each concurrent
programming method, and so develops a methodology for the development of
concurrent programs. His book is well structured and could be used at almost
any undergraduate level. Indeed, Andrews maps out different routes through
the book for varying levels of course.

Finding an automatic way to translate conventional programs to run on
parallel computers is one of the holy grails of current research. As yet
there has not been enough progress to justify a textbook on the subject,
but Supercompilers for Parallel and Vector Computers manages to provide
a clear overview of the issues that are relevant beyond the research laboratory.
Hans Zima, its author, is a recognised authority in the field, and the techniques
he describes are increasingly used in compilers for all kinds of machines.
This text may well find its way into advanced courses on compiler construction
in the future.

The use of formal methods to develop programs and prove their correctness
has been another hot area in the past 10 years. When creating any computer
system, particularly a large one, you need to specify exactly what that
system should do before starting to program. Specifications have traditionally
been written in a mix of English and flow charts, leaving them open to ambiguity,
self-contradiction and incompleteness, but recently several formal notations
have emerged that eliminate, or at least limit, these problems.

David Lightfoot’s Formal Specification Using Z introduces one popular
notation lucidly. This book is not a critique of formal specification as
a methodology, but rather an introduction to the particular notations and
conventions of Z and the discrete mathematics that underpin it. Clarity
of layout and narrative are coupled with extensive exercises and solutions
to make this an ideal introduction to Z and its use.

The authors of An Introduction to Programming with Specifications argue
even more strongly that the day of the computer whiz kid are numbered. Their
book, which introduces the basic idea of formal specification and mathematical
proof, is a light text compared to others that cover the same material.
Formal specification, mathematical induction, recursive definitions and
iterative algorithms are a few of the many ideas it explains. A set of exercises
of varying difficulty plus answers accompanies each chapter. This book is
highly recommended for undergraduates, and for software engineers looking
for a gentle introduction to the mathematics of programming.

Mike Piff’s Discrete Mathematics: An Introduction For Software Engineers
would be good preparatory material for the previous two texts. Piff believes
that the mathematics currently taught to computer-science undergraduates
is not appropriate to their subject, and has written a book on basic discrete
mathematics, along with basic formal methods in computer science, to remedy
that situation. A full-year course would require more material than Piff
presents; it would probably be right for a term.

Until formal methods mature enough to be used in the real world, programmers
will have to rely on good craftsmanship. In the 1970s the idea of ‘structured
programming’ took hold in the programming community; in the 1980s, this
notion led to the idea of object-oriented programming, in which software
packages combining data and methods applicable to those data could be produced
in isolation, and then combined.

The Tao of Objects by Gary Entsminger and Bruce Eckel is a well-written
introduction to object-oriented programming that clearly explains the philosophy
and techniques of the field. The first chapter gently motivates you to absorb
the basic concepts of object-oriented programming, giving examples in C++
and Turbo Pascal. Subsequent chapters stress abstract data types, the extensibility
of object-orientated code and the use of polymorphism. This material is
brought together in two examples: an expert system and a neural network.
The final chapter considers the use of object-oriented techniques in design,
and propounds the advantages that these techniques have over traditional
structured design approaches.

Grady Booch’s Object Oriented Design is a larger and more detailed work,
aimed at a more sophisticated audience. The book’s 599 pages are divided
into three sections. The first discusses the complexity of software before
introducing the object model in considerable detail; the second discusses
the use of object-oriented techniques in software engineering, and includes
material on the design process and the pragmatics of software development,
while the third presents five substantial case studies, using CLOS, Ada,
Smalltalk, Object Pascal and C++. This is a solid book that should find
a place in advanced undergraduate courses.

Traditional database technology has found many useful applications in
the commercial sector. However, when applied to the field of software engineering,
traditional technology has been found to be severely lacking. Object Oriented
Databases: Applications in Software Engineering gives an overview of the
current state of research into alternatives based on object-oriented techniques.
While the subject is a bit specialised, the book does have an extensive
bibliography, and might be a good companion text for a final-year course
in databases.

While all of this has been going on, a few good new books have appeared
covering traditional subjects. Fundamentals of Software Engineering is thorough
and detailed; every student of the subject would do well to read it. The
book first discusses the nature of software and fundamental principles such
as rigour and formality, modularity, abstraction and the anticipation of
change. Only then does it move on to the design, specification and verification
of software. Subsequent chapters tackle software production and the management
of software engineering; of particular interest is a chapter on tools and
environments. All the chapters include a bibliography and exercises with
hints and sketchy solutions. A few small case studies appear as appendices.

Although there are several well-established computability textbooks,
Paul Dunne’s Computability Theory: Concepts and Applications deserves serious
consideration. Its style should not be as daunting as that of many computability
books, while it deals with the important issues in this subject. Relevant
background information is scattered throughout the text, such as discussions
of Godel’s incompleteness theorem and the status of logic in 19th-century
mathematics.

The most welcome new arrival is Problems in Programming: Experience
Through Practice by A. Vitek and others. It contains a large set of programming
problems and solutions, preceded by a concise and instructive introduction
on how to write good code. The problems range from first-year undergraduate
level to those that would challenge an experienced programmer. The solutions
are thorough and excellently explained, making it an ideal book both for
learning to write good code, and for use as a reference text. This book
should be on the shelf of anyone teaching computing at any level.

Finally, a useful new reference book for C programmers is Plauger’s
The Standard C Library. Designed for those who already know C, it provides
descriptions of the use and implementation of many C library functions.

Felicity Brough, Alasdair MacDonald and Greg Wilson are composites of
several researchers working in the Edinburgh Parallel Computing Centre.

* * *

How to Write Parallel Programs: A First Course by Nicholas Carriero
and David Gelernter, MIT Press, pp 250, £24.95

Introduction to Parallel Computing by T. G. Lewis, Hesham El-Rewini
and Inkyu Kim, Prentice-Hall, pp 250, £51.35

Exploring Parallel Processing by Edward Rietman, McGraw-Hill, pp 288,
£15.95

Parallel Algorithms in Computational Science by Dieter W. Heermann and
Anthony Burkitt, Springer Verlag, pp 186, £21.50

Solving Problems on Concurrent Processors: Volume II, by Ian G. Angus,
Geoffrey C. Fox, Jai Sam Kim and David W. Walker, Prentice-Hall, pp 350,
£20.95

Concurrent Programming: Principles and Practice by Gregory Andrews,
Addison-Wesley, pp 550, £19.95

Supercompilers for Parallel and Vector Computers by Hans Zima, Addison-Wesley,
pp 392, £26.95

Formal Specification Using Z by David Lightfoot, Macmillan, pp 192,
£13.99

An Introduction to Programming with Specifications by R. Kubiak, R.
Rudzinski and S. Sokolowski, Academic Press, pp 280, £18.50

Discrete Mathematics: An Introduction for Software Engineers by Mike
Piff, Cambridge University Press, pp 329, £30 hbk, £10.95 pbk

The Tao of Objects by Gary Entsminger and Bruce Eckel, Prentice-Hall/M&T,
pp 300, £19.95

Object Oriented Design by Grady Booch, Addison-Wesley, pp 599, £25.95

Object Oriented Databases: Applications in Software Engineering by John
G. Hughes, Prentice-Hall, pp 320, £19.95 pbk

Fundamentals of Software Engineering by Carlo Ghezzi, Mehdi Jazayeri
and Dino Mandrioli, Prentice-Hall pp 560, £17.95 pbk

Computability Theory: Concepts and Applications by Paul Dunne, Ellis
Horwood, pp 200, £14.95

Problems in Programming: Experience Through Practice by A. Vitek, I
Tvrdy, R. Reinhardt, B. Mohar, M. Martinek, T. Dolenc and V. Batagelj, Wiley,
pp 342, £14.95

The Standard C Library by P. J. Plauger, Prentice-Hall, pp 356, £29.95

Back in the early 1970s, when I was a child, my siblings and I used
to play with a toy called a PendulArt. A PendulArt was simply a flat holding
tray, suspended with string by its corners from a post so that it could
swing back and forth. A coloured felt-tip pen could be fixed into an arm
which was also attached to the post, so that as the tray swung the pen would
trace out a complicated, diminishing pattern. By moving the paper around,
and changing the pens, we created some beautiful designs.

Was this art? I think so; I don’t think something stops being art simply
because part of its creation is mechanical. We decided what colours to use,
how to swing the pendular tray, and, most importantly, which tracings to
keep and which to throw away. I think these images would still have been
art if we had used a computer to simulate the physics of the swinging tray,
and generated the final picture by printing an image from a screen.

In 1968, the British-born artist Harold Cohen started doing something
very like this. At the time, Cohen was an up-and-coming artist whose work
had been shown at the Venice Bienniale and at solo exhibitions in London,
Toronto and other cities. But Cohen was obsessed with how artists manage
to evoke meaning in their audiences. After moving to the University of California
at San Diego he stopped painting, and started programming.

His next 12 years were frustrating ones, as he tried to create a computer
program that would create art in the same way that he did. Cohen was not
interested in computer graphics per se, which is more about modelling the
physics of light than about exploiting the psychology of perception. Cohen
wanted his program, Aaron, to decide for itself what to put in its pictures
and where.

By the late 1970s Aaron was working well enough for Cohen to exhibit
it, and some of its work, at galleries in Europe and the US. Cohen was dissatisfied
with its abstract drawings, however, and after a visit to the Rand Corporation
in 1980 began to give it rules telling it how to create animals and, later,
people and forests.

The rules were simple but could produce complex images. For example,
the early rules for drawing animals included only the notions that animals
have a head and body, which can be represented as a blob-shaped curve, and
four legs and a tail.

The more complicated rules with which Aaron generated figurative scenes
reminiscent of those of Paul Cezanne were still surprisingly simple, but
the way Aaron combined those rules and put them into practice was capable
of generating arresting images.

Cohen’s (and Aaron’s) story is fascinating because of the way it illuminates
the relationship between thought, art, and computing. Unfortunately, this
book does not do the story justice. Pamela McCorduck is probably most famous
for having co-written The Fifth Generation: Artificial Intelligence and
Japan’s Computer Challenge to the World, a book that proved popular, and
influential, reading in airport waiting lounges a decade ago.

Aaron’s Code does not enthuse about artificial intelligence quite as
much as that one-given the technology’s failures during the past 10 years,
that would be imprudent. But it is a similar mishmash of technical facts
(none of which I dispute), opinions about those facts that are too often
presented as if they were facts themselves, and purple science porn.

For example, is the humble ‘if’ statement found in most programming
languages actually ‘a virtual Shiva of intellectual action, a many-handed
god pulling strings with breath-taking complexity’? If so, it’s news to
me. (If Shiva dwells in my computer, am I liable for an extra poll tax payment?)
More seriously, while I am no fan of artificial intelligence, I object to
the author summarising 30 years’ research by saying that ‘the British had
interesting but ultimately sterile theories, while the Americans . . . had
interesting (and slightly different) theories about intelligence . . .’

I think that the main reason this books fails is that McCorduck never
decides whether she is writing an art-house analysis of Cohen’s life and
work, including the work he has created indirectly, or a popular account
of an artist’s invention of a new way of making art. There is no reason
why it could not be both, but it manages to succeed at neither. In any case,
the pages devoted to a feminist reinterpretation of the story of Adam and
Eve, and to retelling the story of Moses and Aaron, add nothing.

What Cohen has done is fascinating; he has succeeded in externalising,
in the form of a computer program, a significant portion of what he knows
about how he creates art. But the occasional passing reference to virtual
reality, artificial life, chaos plus a nostalgically xenophobic mention
of the threat posed by Far Eastern software bandits, adds nothing to what
Cohen has accomplished. Having read this book, I want to know more, but
to learn what I want to know I am going to have to find a better source.

Greg Wilson works in the Parallel Computing Centre at the University
of Edinburgh.

THE FUTURE of high-performance computing can be summed up by one word:
parallelism. What was still an academic idea in the mid-1980s is now being
adopted by all the major players in the supercomputing arena to achieve
further increases in performance. Parallelism is also bringing the power
of today’s supercomputers to the average researcher’s desktop, making possible
a whole new range of computational science.

Conventional computers, from micros to mainframes, contain a single
central processor, and a single store of memory, which holds both the program
to be run and the data the program requires (Figure 1). Such a design is
called serial architecture because the processor does operations one after
another. The speed of such a computer is limited by the speed at which the
processor can execute instructions and can get instructions and data from
memory. As advances in electronics shrink the size of components, engineers
are finding it harder and more expensive to increase the speed of computers
of this kind.

One way round this is to put several processors in a row or ‘pipeline’,
to create a computer with vector architecture. Many scientific programs
perform the same operations on hundreds or thousands of data items, such
as calculating the magnitude txi2 + yi2 of tens of thousands of vectors
(xi,yi). By arranging several processors in a pipeline and giving each processor
a different job, a vector computer such as the Cray X-MP supercomputer can
achieve significant increases in speed (Figure 2).

Since the first vector computers were built in the late 1960s, scientists
have relied on them to do most of their number crunching. Vector architectures,
however, have their limits too, limits which are summed up in a rule known
as Amdahl’s law. In the 1970s, Gene Amdahl, founder of Amdahl Computer,
showed that there is only a finite amount of vectorisable arithmetic in
any program and, therefore, a limit to how much speed-up a vector architecture
can achieve. For example, x2 + 3x + 5 contains only five arithmetic operations,
so processors arranged in a pipeline could run, at most, five times faster
than a single processor.

Parallelism is a way of bringing more processors to bear on a problem.
Instead of having one processor calculate x2, another 3x, and others do
addition, why not give each processor a single x and have it calculate the
whole thing? In theory (and often in practice) the only limit to speed is
the number of processors available.

The idea of parallelism has been around as long as computers themselves.
In the early days, engineers rejected it because of the cost and unreliability
of components. When both these decreased through the 1970s, parallel computers
still failed to enter the market for two reasons: the vector machines were
well established, and there was a lack of software for parallel machines.
A great deal of energy has been gone into making vector machines that can
run ‘dusty decks’ – old Fortran programs which have so much effort invested
in them that users cannot afford to throw them away and rewrite them.

Most parallel machines are so different from conventional ones that
it is not practical to run these ‘dusty decks’, so users have been reluctant
to switch despite the promise of more and cheaper computing power.

By the end of 1988, however, it was clear that large-scale parallelism
had become the favoured way of increasing computer performance. Cray and
other manufacturers of vector computers have introduced computers containing
several pipelines which run in parallel. At the same time, new companies
such as AMT and Meiko are selling more and more of their highly parallel
computers. More processors means that scientists can tackle larger problems
in the same time, which opens up new areas of science.

There are many different types of parallel computer; the struggle in
the 1990s will be to decide which dominates. Different types of machines
are best suited to different types of problem; each requires not only different
software but also a different approach to programming.

In one corner, there are recycled vector machines like the multipipeline
Crays. These have the advantage of a large base of exisiting software and
users, but are likely to remain very expensive and subject to the limits
of Amdahl’s law.

In another corner are single-instruction/multiple-data, or SIMD, machines.
As the name implies, these computers carry out a single instruction at a
time, but on many items of data simultaneously.

One of the first such machines was the Distributed Array Processor,
or DAP, introduced by ICL in the late 1970s and now being built by a spinoff
company called AMT. The DAP is made up of a square grid of simple processing
elements (either 32 X 32 or 64 X 64 in size), each with its own local memory,
plus a single master processor. The master processor interprets program
instructions and broadcasts commands to the processing elements. These then
carry out the instructions on the values stored in their memory. If the
master processor says ‘add’, for example, then 1024 or 4096 additions are
carried out simultaneously (Figure 3).

SIMD machines such as the DAP are very good at problems containing lock-step
parallelism. For example, a computer processing a satellite photograph must
often carry out the same filtering operations on each picture element, or
pixel, in the photograph. If each processing element stores a single pixel,
and works simultaneously, an SIMD computer can filter the whole picture
in the time it would take a single processor to filter a single pixel.

SIMD machines, however, are inefficient when used for a problem that
contains many dissimilar subtasks. For this, a MIMD, or multiple-instruction/multiple
data, computer is better. Each processor in an MIMD machine has its own
program, which it executes independently of its neighbours. The processors
then communicate with one another to exchange partial results, or send commands.

There are many different ways to construct an MIMD computer. First,
the designer has to decide whether the processors will share a common memory
store, or whether each processor will have its own local memory. Shared
memory machines are often easier to program (each processor can ‘see’ the
whole state of the problem), but as they become larger, the processors have
to spend more and more time waiting for their turn to get at the memory.
This puts a practical limit on the size of shared-memory machines; very
large computers must have a distributed memory.

Another split in the MIMD world is between those who favour a fixed
arrangement of processors, or topology, and those who are in favour of letting
users change the topology of the machine to suit their own needs. In a fixed-topology
machine, the links between the processors are set when the machine is built,
and cannot be changed. The most popular such architecture is the hypercube,
so-called because the processors are connected as if they were at the corners
of a multidimensional cube.

Provided that software exists to route messages efficiently between
processors in different configurations, the difference between distributed
vs shared memory, and fixed vs reconfigurable topologies, become less important.
Such routing software has been around since the mid-1980s for machines with
fixed topologies such as the Intel iPSC and the BBN Butterfly, and is now
becoming available on reconfigurable machines such as the Meiko Computing
Surface. It frees programmers from having to rethink the problems of interprocessor
communications each time they write a program, making both computers and
their programmers more productive.

The distinction between different types of machine will blur still further
with the development of abstract interfaces which provide a standard model
of what a machine can do without specifying how the machine does it.

One advantage of MIMD computers is that they can be adapted to handle
multiple users. Programmers, for example, spend more time writing and debugging
programs than they do running them. Giving a programmer an entire supercomputer,
therefore, is wasteful, because the computer will spend a lot of its time
idle. With an MIMD computer, several users can each be allocated a small
number of processors on which to develop code, while the remainder of the
processors are reserved for running production versions of the programs.

All these ideas are now reality. During the past two years, the British
company Meiko, of Bristol, has been building a large supercomputer which
forms the backbone of the Edinburgh Concurrent Supercomputer Project at
Edinburgh University. This machine currently contains almost 500 Inmos transputer
chips, each capable of more than one million arithmetic operations per second.
More than 20 people can use the supercomputer simultaneously, with from
one to 256 processors for each user. Software written on this machine will
also run, without changes, on any of Meiko’s other Computing Surface machines.

This sort of software portability is certain to be what will determine
the shape of supercomputing in the 1990s. For a few tens of thousands of
pounds, an industrial laboratory or academic department can now buy a multiprocessor
computer containing a few tens of processors which can deliver the sort
of performance that, 10 years ago, was possible only with a multimillion
pound computer. The difference is that software developed on the lab machine
can then be run unchanged on a much larger version of the same machine.

Almost as important is that a reconfigurable MIMD computer can be enlarged
step by step. The only way to increase the performance of your PC program
is to throw away your PC, buy a more powerful computer and then rewrite
those parts of the program which are not compatible with your new computer.
If you have a computer which relies on many small, relatively cheap processors,
you can add a few more each time you have a bit of money.

Even more radical changes are on the horizon. Some researchers are looking
at the possibility of building computers in which many small elements are
each connected to hundreds of others in the same way as neurons are interconnected
in mammalian brains. Such ‘neural networks’ have already proved themselves
capable of impressive performance in fields such as image processing. These
and still more far-reaching ideas will help to provide the supercomputing
power that science and industry will need in the next century.

Greg Wilson works for the Edinburgh Concurrent Supercomputer Project
at Edinburgh University.