An Oral and Pictorial History
of Large Scale Scientific Computing
As It Occurred at the
Lawrence Livermore National Laboratory
by George A. Michael, the curator of this project
I retired from the Lawrence Livermore National Laboratory (LLNL) at the end
of 1991, having started there on April 16, 1953. Since 1995, I have been
working, part time, on a project aimed at recording the memories of some of
those who were involved with the beginnings of computing at the Lab, and
with saving materials that might be worthy of a museum setting. One reason
for embarking on the project is that hardly any of this original work was
published in technical journals; the excuses often depended on some sort of
security considerations. In this introduction, I try to provide a sense of what it
was like in the early days, as a backdrop for some of the things that were
done. I do not intend these to be considered complete or definitive. They are
the personal perceptions of the interviewees. It is likely that I missed some
people who should have been interviewed. It is also likely that errors of
interpretation may have crept in. I accept the blame for that, and note that way
has been provided for adding new interviews, and making corrections, or other
I think it is important also to note specifically that this project is not sanctioned
or sponsored by the Laboratory. "Tolerated" might be more accurate. In any
event, if it's necessary to assign blame, the Lab is innocent. I hope I have
preserved the technical details and also showcased the spontaneity and
creativity of those who were doing the work. Clearly, it will be the judgement of
the readers as to how successful I was.
Before continuing with this introduction, I want to acknowledge all the persons
whose assistance was absolutely vital in producing this collection of
Acknowledgments and Disclaimers
This project has been more difficult than expected for reasons that seem clear
now, but weren't initially. I started the audio recording of the memories of
some of the early computational activities with the intention of providing the
tapes as grist for some real historical analysis by some real historians. Initially,
I had some Lab support, through the courtesy of Chris Hendrickson, my
immediate supervisor, who thought that the interviews should be typed and
published as Laboratory reports. During these first efforts, my colleagues-in-crime
were Catherine Williams who did the typing and served as an editor and
Jerry Owens who further proposed that the interviews be made available at a
"Virtual Museum" Internet site. This is the plan we have followed. But, after
Chris retired, the funding quickly dried up and, for the last several years, the
entire project has had to rely only on volunteer help. It was in this period that I
finally began to understand the difference between what I thought of
Computation, and what Laboratory policy was. I'll return to this point later.
These volunteers, friends and colleagues, are vital to the completion of the
project. Initially, I started with the excellent assistance of Catherine Williams
who not only produced the first transcriptions, but also edited the first dozen or
so of the interviews. A medical condition forced her to retire and we lost her
services thereby. Some time later, SharonLee Danielson, a former secretary
and administrative assistant who has since retired, volunteered to take on the
chore of typing. Additionally she has organized the files and other records so
that, thanks to her, we can tell at a glance how things are progressing.
Sam Coleman, also a retiree, designed the file organization and is converting
the edited typescripts into documents capable of being viewed over the
Internet. This includes pictures, and other reference material. Tom DeBoni, now at
LBNL/NERSC and formerly at Livermore, has managed the chore of actually posting the
material at a web site. Once the interviews are posted, there is a more or less
continuing edit phase in which changes and corrections of all sorts are considered.
James (JED) Donnelley, also formerly at Livermore and now at NERSC, has led this effort.
We are grateful to Horst Simon, the director of NERSC for hosting our collection of
interviews. The Laboratory archivists, Beverly Bull and Steve Wofford, have been
indispensable informal sources for some of the hard-to-find items that relate to
this project, and also inspirational supporters of this effort.
I have one additional remark: my memory is not so good that everyone who
should have been remembered was. The same is true for the reported events
and chronology. All dates and sequences are subject to corrections that may
appear from time to time. For all mistakes I recommend the best procedure is,
"Don't blame Michael." You could be kind and forgive him, but much better
would be to correct him.
The Structure of this Oral History
This project contains interviews of some of those who were involved with the
formation and development of the Computation Department at the Lawrence
Livermore National Laboratory during the years 1950 to 1975. For the sake of
continuity, some events go beyond 1975.
Many consider these years the golden years within computing, and certainly
as it evolved at the Laboratory. Generally there were hardly any rules or other
useless administrative stuff. People were free to work with the minimum of
During this time, outsiders throughout the world recognized computer usage at
the Laboratory as innovative and pioneering in applying large computers to a
huge range of problems. The emphasis to be noted is on largeness. In the
early days, when software was bundled and freely distributed, the programs
we got were often rather inadequate; the things simply didn't fit well with the
large programs we were developing. There were limits on array sizes and
tables; even program sizes. Such programs lacked a certain kind of toughness
and flexibility, or imposed limits of one sort or another that made them simply
unusable. So, of necessity, we came to depend on software developed at the
Laboratory. Our programs weren't necessarily better than the versions we
could get from outside sources, but they were more robust and they did allow
the users much more flexibility in their applications program development.
Notwithstanding, we enjoyed and benefited from a great camaraderie with
colleagues throughout the country, and especially with those in the Bay Area.
Let me note in passing that the attitude within Lab management was that the
only thing of importance was Nuclear Research (read Weapons Design).
Everything about computing, no matter how important it was to computing,
was hardly worth recognizing in its own right. Nothing was allowed to detract
from the urgency of nuclear design, at least as perceived by the AEC
headquarters in Washington. This singleness of purpose produced the finest
weapons research laboratory in the world even while there arose certain
strains between the weapons designers and the creators of the tools they
used. For many in the orgy of computational discovery, this didn't matter.
Weapon design was, after all, the reason we were hired. Even though it may
have been necessary, we weren't hired to specialize in creative methods for
using computers. Notwithstanding it was fun doing these things. If the
managers chose to regard the computers as nothing more than fast slide
rules, that was their problem. We were having fun.
In any event, we seemed to be given enough money to get things done, and
challenges such as they were, didn't daunt the staff. Being inexperienced,
many never noticed how hard some things were to get done, except that most
projects were perennially late. Many cynics (realists) argued that the Lab was
a spoiled rich brat. "Anybody else with that much money would have done as
well, or better." As far as I'm concerned, the right response to this is,
"While you may be correct, history doesn't record its alternatives."
I can say with a great amount of certainty that we had three, possibly four,
crucial stimuli. From observation, most other research centers lack one or
more of these. We had the money, we had good people,
we had real applications and, finally, we had a management smart
enough to not interfere as long as the programmatic work was getting done.
Moreover, most of the work was hardly impeded by pauses for writing and
In fact, that was one of the major problems. Not much was reported or
published. Since publishing did little for nuclear design, it wasn't important; no
brownie points were available for publishing or for such things as teaching
classes about programming.
I don't wish to imply that everything was perfect, and I certainly don't wish to
suggest that everything written was good stuff. A great deal of the output of
computation programmers was comfortably pedestrian. As valuable as it was
for nuclear design, I have not tried to capture any of those results in these
memoirs. First and foremost, I want the interviews to convey some of the
ambience of those days, and highlight some really neat things characterized
by good vision, clever implementation, or things that really served user needs.
Finally, I don't intend to imply that we always enjoyed unanimity amongst the
staff. There was a lot of arguing. There were big egos and bigger tempers.
There were big arguments about direction, false starts, missed goals, and late
delivery dates. The path was hardly ever smooth or well marked, nor was
consensus the usual situation. But when things worked out, there was an
unmistakable sense of accomplishment and pleasure.
For the group doing computation, two other things contributed to the
stimulating atmosphere of cooperation and free inquiry. First, the excitement
of discovering new things or better ways of doing things for the first time; it is
well known that there is a great pleasure doing things that others say can't be
done. The second factor, especially for the more junior staff members, was
meeting and interacting with senior scientists who routinely visited the
Laboratory. Generally, we knew about such persons by reading about their
work while we were students; persons such as George Gamow and John Von
Neumann. For such reasons, working at the Lab was the best intellectual high
many of us ever experienced. It was fun!
As far as I'm concerned, this oral history is not a history. Rather it is a
collection of war stories, some uncoordinated sequences of events as seen by
individuals. I have tried to ensure that names and dates are correct and
appear in the correct context throughout the interviews, but otherwise the
stories belong to those being interviewed. Eventually, I will try to provide a
"cast of characters". I wouldn't be surprised if a careful reader uncovers some
inconsistencies between narratives. No big effort was made to catch such
things. I will, of course, be grateful for any alternate versions readers may
wish to provide. Within reason, these will be fully published, with attributions.
Before continuing, and just this once, I would like to mention some gratuitous
thoughts about the Lab's administration, because I still feel stymied by what
seems to be management blindness both at the Lab and at DOE
Headquarters. My comments might also be interpreted as my attempt to
understand what went on and, specifically, no one else should be blamed for
I've already alluded to the management bias toward nuclear design. The
reader must not consider this wrong. The lab was founded to do nuclear
design. Practically all early senior managers thought of computers as slide
rules or adding machines. It was mostly through use that alternate visions of
computational potential became obvious.
At the beginning, and time after time thereafter, I felt many key decisions
made about the Computation Department activities were plainly wrong, or at
least lacked a vision of the potential benefits. Even more to the point, while
many of the computational achievements truly helped weapons design and
research, they were never suitably acknowledged. For example, there is no
doubt that Time Sharing was of singular importance in exploring the nooks
and crannies of nuclear design, but the designers after initially fighting it,
never acknowledged its value except of course, by using it.
It is generally true that the Lawrence Radiation Laboratory was founded
largely because of the activities of Edward Teller and, without question, the
lab was not also intended to be a research facility for computation. Indeed, the
oft-stated goal was to advance thermonuclear weapons research, deemed to
be absolutely necessary because the Russians had produced their first
nuclear device some five years earlier than our pundits had predicted. So, as
has been reported elsewhere, Dr. Teller was unhappy with the lack of
progress at Los Alamos in developing the so-called Super. Part of the problem
was that no one knew how to design such a device and some of the AEC felt it
shouldn't be tried at the expense of not improving the designs of the ordinary
fission weapons. Finally, a promising way was proposed by Teller, based on a
seminal suggestion of S. Ulam, a mathematician at Los Alamos. Even then,
Teller felt that progress was too slow. A second laboratory was deemed
necessary, and a new contract between the Atomic Energy Commission and
the University of California was signed that led to the formation of what is now
called the Lawrence Livermore National Laboratory (LLNL).
Among the many consulting scientists that advocated computing support as a
necessary part of weapons design, was John Von Neumann, who aided the
original staff in acquiring its first computer, the UNIVAC 1 in 1952. But note
well, it was computer support, not research. The general attitude was to
tolerate some computer research because it was needed for nuclear design
support. Exploring this new computational space was supposed to go on at
So, computing was a tool for the senior physicists and, definitely not, in any
scholarly way, a basis for a new kind of scientific development. From the
beginning, computer research was tolerated, and indulged only to the extent
that it advanced the major programmatic goals of the weapons projects.
Senior scientists at the Lab were allowed six hours a week to pursue their own
research interests. This benefit was not extended to the programmers. Initially,
programming, or coding, as it was then known, was not even considered a
profession. It was mostly through the efforts of Sid Fernbach, the first director
of computation, that the U.S. Department of Labor was prevailed upon to
recognize a new professional classification. To be paid as professionals,
computer programmers were not just coders or computists; they were
reclassified as "Mathematical Programmers / Computer Scientists."
The problem was that much more than mathematical algorithms was needed
to usefully exploit computers, including the development of discrete
mathematics, operating systems, program libraries, storage devices, output
procedures including visualization, performance analysis, and so on. Much of
the stuff either didn't exist, and what was available from other places was
inadequate. The de facto solution of this problem was to allow the staff to
produce what was needed. Then, the new problem that arose was how to stop
the staff from continuing with this fun research after they had satisfied the
designers' immediate needs.
In any event, the Computation Department started to live a life of its own
because it was producing other stuff needed by the designers, even when
they didn't know that such things were useful. For example, the physicists
initially wrote their "design codes" in octal because there wasn't any
alternative, and the initial programs were very simple. As the design programs
grew in size and complexity, other methods were needed. Even so, when
assemblers were made available, the designers were slow to use them.
Similarly, when compilers arrived on the scene, the designers were again slow
to use them. The same was true for timesharing, mass storage, graphics, and
Ö, but you get the idea; computational progress was rapid, but adoption was
slow. The designers were not unreasonable. Their job was to do nuclear
design, not "waste a lot of time" improving the tools, especially when most of
the stuff wasn't user-friendly. This is understandable and, initially, the
weapons divisions could justify their results, making it easy to ignore what
some of the programmers were doing.
As the Laboratory aged, the willingness to allow the computists such free rein
began to dissipate. Even though the needs did not go away, the weapons
divisions more and more advocated purchasing the things they needed rather
than having to wait a long time while the Computations staff produced it
because, they said, it was cheaper. It may have indeed been cheaper, but it
didn't necessarily always work properly, so really talented people were being
turned into baby sitters for other persons' work. Not good.
In many instances, the weapons divisions were right, but one consequence
was that innovation began to disappear from computation. Today it is largely
gone, even though the budgets have not shrunk. Even during the golden
years, the weapons divisions, controlling as they did at least 85% of the
computation budget, discouraged the very developments that made the early
Laboratory a computational showplace throughout the world. Another,
perhaps unintended, consequence was that not much scholarly publishing
was done. So few outside the laboratory knew about the development of the
Television Monitor Display system, the timesharing systems, the File Storage
and Management systems, and many other things that are discussed in these
memoirs. Face it, Livermore was primarily devoted to excellent nuclear
weapons design; computational developments had to take a back seat.
It makes no sense for this project to try, now, to do such publishing. However,
the events, as seen by those who were there, form a collection of authentic
war stories worthy of being aired. These are what I set out to collect, from
persons who functioned in one or more of the following categories:
General Computing Systems (Software and Hardware);
General Administrative activities;
I/O, especially Networking, Storage and Graphics.
As you will see, a list of computer acquisitions makes a good skeleton on
which other things can be hung. Here is a short chronology, accurate to the
best of my knowledge, of large computer acquisitions between 1950 and
1978, that should help place the interviews in a useful context. Small
computer and peripheral procurements are briefly considered later in this
introduction. It's a good thing to keep in mind that all the computers listed
below were selected largely because it was claimed they were the fastest
things then available, and that's what the designers kept demanding: faster
and faster computers. In the listing that follows, I've interspersed some
gratuitous comments. This makes the introduction overly long, but may
highlight the reasons for choosing these particular computers.
July - Sept. 1952 The Lab is founded and the first computer ordered
April, 1953 a UNIVAC 1 is delivered
The UNIVAC was a serial computer using decimal numbers. It was more
than a computer. It was a (complete) system that addressed the needs of
input and output, storage, and arithmetic. It had a 1,000-word memory
and each word held twelve decimal digits. Being a serial computer meant
the UNIVAC performed all its internal operations, including arithmetic on
one digit at a time. It had built-in circuitry to check periodically, the entire
contents of its memory and all its registers for errors. If errors were
detected, the machine halted so that corrections could be made.
June 1954 the first of two IBM 701s arrives
The IBM 701 was a parallel computer using the binary number system.
Except for the UNIVAC and the LARC, all other computers at the Lab
used the binary number system. The 701 had a 4,096-word memory,
each word being 36-bits; equivalent to almost 12 decimal digits. The
parallel feature means the machine did most of its internal operations
including arithmetical on whole words. This helped the machine to be
much faster than the UNIVAC. The 701 used Williams CRT tubes as the
memory organ. This made the machine very unreliable. It freely made
mistakes, but never reported them. This was fundamentally different from
the UNIVAC. However, all the computers in this list used a parallel
organization, and all benefited from improved components, so errors
became less of an issue as time went on.
April 1955 The first of four IBM 704s arrives
The main virtue of the 704 was a larger and improved memory based on
ferrite cores, and hardware support for floating point arithmetic. It was
faster than the 701 and vastly more reliable. The 704 introduced the use
of Index Registers to facilitate addressing. One of the major accessories
was a CRT system that allowed direct viewing and/or recording of data
on 35mm filmstrips.
Sept.1958 The first of four IBM 709s arrives
The 709 was quite similar to the 704, but with a much improved method for
doing input/output operations. It also accommodated larger memories. A
CRT system similar to that on the 704 was tried, but it was both too
cumbersome, and slow. All subsequent graphics work was carried out on
specially designed units that could be, if desired, attached to a main
April 1960 The first of four IBM 7090s arrives
The 7090 was IBM's first 7000 series machine to use transistors. This
allowed a large increase in speed The machines supported a memory of
32,768 words (32K). As with all of these IBM computers, each word was
36-bits in length.
June 1960 The UNIVAC LARC arrives
The LARC (Livermore Automatic Research Calculator) was a decimal
machine and the first designed to use transistors, although it was not the
first transistorized.computer delivered to the lab. More importantly, it
introduced at least two architectural innovations that have persisted in
other large computers. One was the separation of input/output controls
from the main CPU and the other was the introduction of Register Files
for rapid context switching. The big speed increase resulting from the use
of transistors while real, was overshadowed by the earlier arrival of the
7090 which provided most of the expected increase in speed. The LARC
also introduced an Electronic Page Recorder (EPR) that permitted
recording text and graphs onto 35mm film, but the attempt to process the
film automatically was not successful. The LARC, although very late, met
or exceeded all its design goals. It ran practically error free, and it was
the last computer to be based on the decimal number system.
Sept. 1960 The first of five IBM 7094s arrives
The 7094 was the culmination of the IBM 7000 series. It used the
memories designed originally for the IBM 7030, and was almost twice as
fast as the 7090. The similarity of the architectures in the 7000 series
made migration through successive models relatively easy.
March 1961 The IBM 7030 (STRETCH) arrives
The 7030 was IBM's response to the LARC project. It was, perhaps, overly
elaborate, and like the LARC, very late in delivery. Again the expected
speed increases were overshadowed by the earlier introductions of
transistorized computers - 7090, LARC, 7094, and so on. The 7030
provided the largest memory for any machine then in use at the
Laboratory. It used 72 bit words of which the last 8 bits were for ECC
(Error Correction and Control.)
Feb. 1962 The CDC 1604 arrives
The 1604 was one of the first computers designed by Seymour Cray. It
used a 48-bit word, and was acquired to study architecture different from
the IBM designs then in use at the Laboratory and to explore variations in
numerical precision. Additionally many programmers considered the I/O
procedures of the CDC computers easier to use.
May 1962 The first of two CDC 3600s arrives
The 3600 was also acquired as part of a plan to make an orderly transition
to the CDC 6600. Memory size on these CDC machines was 32k. The
CDC computer words used 48 bits while the IBM 7000 series used 36
bits. This obviously allowed more numerical precision. Studies had now
begun to determine how much precision was actually needed in the big
design programs. The batch operating system used on these machines
was considered easier to use than that on the IBM machines.
April 1964 The first of four CDC 6600s arrives
The 6600 was considered the first Supercomputer. It was the fastest
computer in existence, and provided the largest memory. It fully exploited
the flexibility of separate computation and input/output processors. Its
arithmetic provided for the largest numerical precision. A separate set of
ten peripheral processing units (PPUs) managed all I/O operations. The
memory contained 128,000 sixty-bit words giving the 6600 the largest
memory operating at a cycle time of one microsecond; about the fastest
memory then available. Actually, at this speed, there were some of
memory errors, but the machine was sufficiently fast so one could
introduce suitable strategies to catch the errors, rerun all or part of the
calculation and still end up running faster on this machine than on any
March 1969 The first of five CDC 7600s arrives
Seymour produced an interim computer called the 6800, but it never
satisfied his goals, so it never left his computer lab. He then designed
and delivered the 7600, which was his third Supercomputer design. He
preserved some of the architecture of the 6600 and introduced some
radical new things. The I/O control was reintegrated into the CPU, and
more radically, the memory was divided into two parts. The fastest was
called the Small Core Array and consisted of 65,000 words each with 60
bits. The larger memory held 500,000 words that were accessed as
super words (SWORDS) 480 bits at a time, which then could be treated
as eight 60-bit words. This Large Core Array was slower than the SCM,
but it did give access to super words (SWORD). Granted that memory
technology was somewhat primitive, this memory bifurcation was an idea
used to control costs, but programmers found it difficult to manage. Even
so, the 7600 was considered about 5 times as fast as its predecessor,
the 6600. (The first 7600, serial number 1, remained in production
for twenty years. It was retired in 1989 despite screams from the users who
loved it. Thus ended an era not likely to be repeated at LLNL.)
July 1976 The first of two CDC STAR 100s arrives
The STAR 100 was the first vector machine in design, but because of its
other complexities, was not the first to enter the marketplace. Vector
computing was then rather new, and difficult in adaptation. A major
problem on the STAR was the disparity in speeds between vector and
scalar computations. The STAR provided the largest memories in use at
the Lab: one or two million words. They were used as time sharing servers,
but it was very hard to do that and efficiency suffered. They were late in
delivery. It was difficult to produce efficient programs, and generally failed
to make an impression on the marketplace. One of the designers at the
Lab remarked that his team had spent seven years to gain mastery of the
STAR, and that was seven years of not improving the physics, and he
was never going to do that again.
May 1978 The first of four CRAY 1s arrives
The Laboratory did not get serial 1 of the CRAY 1, and it was at least two
years after the STAR adventures before a new computer was allocated
to the Lab. The word size for the CRAY was 64 bits, and up to 2 million
words of memory was allowed. As with all Cray designs, there really
wasn't any upward compatibility in the order codes of the machines, but
all of them rewarded the programmer with increased speed for careful
programming. Upward compatibility was not a goal of Seymour Cray's
designs; speed was . It is worth noting here that until the Cray 1 era and
even for some time thereafter, the IEEE standard for doing computer
arithmetic had not achieved general acceptance, and therefore each
conversion from one machine to another had to take this into account.
Keep in mind that, in the earliest interval 1950 to 1960, the computer milieu
was being born. As we learned later, lots of original work was simultaneously
being developed at other places like Manchester University in Manchester,
England, at MIT, in Cambridge, MA, and the Moore School of Engineering at
the University of Pennsylvania in Philadelphia, PA, to name just a few.
However, the results did not get generally circulated. For one thing, there was
hardly anyone able to receive such news . There was no computing fraternity,
and no large collection of books about computing. Getting started meant each
place developed a lot of the ad hoc stuff needed for using the early machines.
In the beginning there was a lot of emphasis on speed, like fast ways to
extract square roots. Or compute the distance between two points without
taking a square root. Or devise a way to start loading a new program without
destroying most of the previous memory contents; really basic things having
just two factors in common; everything seemed NEW and very necessary. No
matter how often they were discovered, it was always a thrill for the inventor.
Both beauty and further ideas awaited the adventurer/programmer. It was a
time when cleverness was a lot of fun.
Let me turn now briefly to a few questions relating to small computers. In 1952,
Sid Fernbach was lured back from a postdoctoral year at Stanford by Edward
Teller. He took over the mechanics of acquiring the UNIVAC 1, and
subsequently, he was named to head a Computer section as a part of the
Theoretical Physics Department. For our purposes here, a small computer
then was characterized by three factors:
They utilized relatively slower components for arithmetic and logic,
They had, initially, relatively small memories,
They were deliciously cheaper.
In any event, all computer procurement was assigned to Sid. It was
understood by everyone that computers were to be used in weapons design.
Small computers didn't do weapons design; they could other things for small
groups or individuals. This attitude persisted long after they started to become
common. But small or otherwise, they were the responsibility of Sid. Since
they clearly couldn't be used in nuclear weapons design, Sid set up a group to
oversee their procurement, and most of these machines ended up as
controllers of one sort or another, for example, as controllers for laboratory
instruments. A principal effect was that Sid personally gave them little
attention other than to ensure that the Small Computer group was staffed with
competent and acceptable people who assisted other Lab staff in procuring
these small machines.
In retrospect, this may have been a strategic error. In a short time, the
combined expense of small computer procurement exceeded that for large
computers and, of course, given that the budget was relatively static, what the
small purchasers got was taken in part from the budget for large computers.
Clearly, this caused some stresses to develop. The other contributor to this
stress was that the small machines became incredibly more powerful and
capacious. Presently one can pay around $3,000 for a machine that is faster
than the machines we used in the 1970s costing almost $10 million dollars.
And, moreover, these "small" machines have at least 25 times as much
When once this was pointed out to Sid, someone remarked,
"Le Coût en ôte Le Goût.," or something like that.
Recapitulating, in this introduction, I have tried to point out that we are not
really recording history; we are telling war stories from which someday may
emerge a real history. These stories record the personal memories of many at
the Lawrence Livermore National Laboratory who developed computing in the
early years. Additionally, I have tried to discuss the attitudes of some of the
players and the machines they used, with due regard for the
As the reader will note, the interviews cover both hardware and software as it
was evolving from 1950 to 1978. I have chosen 1978 because I believe that,
with the playing out of the STAR adventure, the Computation experience at
the Lab went into a kind of eclipse. If, now twenty-five years later, it is
emerging, that will be a wonderful story for others to tell.
I invite you to enjoy our efforts, always remembering that we actually look
forward to your comments and corrections. Just don't make the knives too
 Cray's commitment to speed had a troubling consequence in the first 6600.
Whenever a floating-point calculation gave zero result, to save a cycle, the register
was not cleared completely; the exponent was left with a legal value and the
fraction had zeros. So, a test for zero always failed. This has awkward
consequences for programs that depended on testing for zero in order to terminate
a loop, or to branch to some auxiliary code. The simple solution was to fully clear
the result register. The reason Cray didn't do that was that it would add one cycle to
the time. Eventually, he was persuaded to do that. The effect was dramatic;
programs were sped up enormously. Seymour noted it cost an extra cycle that
could have been avoided had we been willing to program around what he thought
of as an idiosyncrasy. Everyone had a good laugh at this. Other than that "feature",
the 6600 was a very highly regarded machine by all our users.
 Seymour's taste for speed caused him to do certain things to floating point
arithmetic that sacrificed at least one significant digit in the results. For example,
he rounded the dividend before performing the division. Needless to say this was
anathema to the mathematical purists in the user community. Those who were not
so pure either ignored this or found ways around such problems.
 It is true that the Association for Computing Machinery (ACM) was active in the
sponsoring of specialist meetings at which such specialist knowledge could be
shared. It is also true that many of the users hardly ever attended such meetings.