[...]When I worked in Copenhagen at the Niels Bohr Institute and later at
When I started at CERN in 1981, the principal computer
system was an IBM 360. We used WYLBUR for the editing
environment, with exec files for simple things and batch
processing with JCL for the more serious work.
It was clumsy, but I didn't know any better at the time.
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
On Sun, 13 Sep 2026 14:56:20 -0700, Lars Poulsen wrote:
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
Prof William ?Mr IEEE-754? Kahan?s foreword to the ?Standard Apple Numerics Manual? had this to say about some of those machines:
For instance, a very Important Bunch of Machines launched in 1964
were found to have two anomalies in their double-precision
arithmetic (though not in single): First, multiplying a number /Z/
by 1.0 would lop off /Z/'s last digit. Second, the difference
between two nearly equal numbers, whose digits mostly canceled,
could be computed wrong by a factor almost as big as 16 instead of
being computed exactly as is normal. The anomalies introduced a
kind of noise in the feedback loops by which some programs had
compensated for their own rounding errors, so those programs lost
their high accuracies. These anomalies were not "bugs"; they were
"features" designed into the arithmetic by designers who thought
nobody would care. Customers did care; the arithmetic was
redesigned and repairs were retrofitted in 1967.
Not all Capriciously Designed Computer arithmetics have been
repaired. One family of computers has enjoyed notoriety for two
decades by allowing programs to generate tiny "partially
underflowed" numbers. When one of these creatures turns up as the
value of /T/ in an otherwise innocuous statement like
if T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
it causes the computer to stop execution and emit a message
alleging "Division by Zero". The machine's schizophrenic attitude
toward zero comes about because the test for T = 0.0 is carried
out by the adder, which examines at least 13 of /T/'s leading
digits, whereas the divider and multiplier examine only 12 to
recognize zero. Doing so saved less than a dollar's worth of
transistors and maybe a picosecond of time, but at the cost of
some disagreement about whether a very tiny number /T/ is zero or
not. Fortunately, the divider agrees with the multiplier about
whether /T/ is zero, so programmers could prevent spurious
divisions by zero by slightly altering the foregoing statement as
follows:
if 1.0 * T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
Unfortunately, the Same Computer designer responsible for "partial
underflow" designed another machine that can generate "partially
underflowed" numbers /T/ for which this statement malfunctions. On
that machine, /Q/ would be computed unexceptionably except that
the product 1.0 * T causes the machine to stop and emit a message
alleging "Overflow". How should a programmer rewrite that
innocuous statement so that it will work correctly on both
machines? We should be thankful that such a task is not
encountered every day.
On Sun, 13 Sep 2026 14:56:20 -0700, Lars Poulsen wrote:
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
Prof William ?Mr IEEE-754? Kahan?s foreword to the ?Standard Apple Numerics Manual? had this to say about some of those machines:
For instance, a very Important Bunch of Machines launched in 1964
were found to have two anomalies in their double-precision
arithmetic (though not in single): First, multiplying a number /Z/
by 1.0 would lop off /Z/'s last digit. Second, the difference
between two nearly equal numbers, whose digits mostly canceled,
could be computed wrong by a factor almost as big as 16 instead of
being computed exactly as is normal. The anomalies introduced a
kind of noise in the feedback loops by which some programs had
compensated for their own rounding errors, so those programs lost
their high accuracies. These anomalies were not "bugs"; they were
"features" designed into the arithmetic by designers who thought
nobody would care. Customers did care; the arithmetic was
redesigned and repairs were retrofitted in 1967.
Not all Capriciously Designed Computer arithmetics have been
repaired. One family of computers has enjoyed notoriety for two
decades by allowing programs to generate tiny "partially
underflowed" numbers. When one of these creatures turns up as the
value of /T/ in an otherwise innocuous statement like
if T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
On 9/14/2026 21:10, Lawrence D?Oliveiro wrote:
On Sun, 13 Sep 2026 14:56:20 -0700, Lars Poulsen wrote:
When I worked in Copenhagen at the Niels Bohr Institute and later at
RECKU (the larger academic datacenter at University of Copenhagen)
in the early 1990s, the experimental physicists traveling the
circuit between SUNY Stony Brook, CERN and Copenhagen with their
suitcases full of dusty decks of FORTRAN IV cards, hated the IBM
360-s with a vengeance due to their lack of precision when computing
wave functions. They liked the 36-bit IBM709x and UNIVAC 36-bit
systems much better, but they REALLY loved the CDC 6600s at CERN
(and later Aarhus) because of the 60-bit floating point format.
Prof William ?Mr IEEE-754? Kahan?s foreword to the ?Standard Apple
Numerics
Manual? had this to say about some of those machines:
ÿÿÿÿ For instance, a very Important Bunch of Machines launched in 1964
ÿÿÿÿ were found to have two anomalies in their double-precision
ÿÿÿÿ arithmetic (though not in single): First, multiplying a number /Z/
ÿÿÿÿ by 1.0 would lop off /Z/'s last digit. Second, the difference
ÿÿÿÿ between two nearly equal numbers, whose digits mostly canceled,
ÿÿÿÿ could be computed wrong by a factor almost as big as 16 instead of
ÿÿÿÿ being computed exactly as is normal. The anomalies introduced a
ÿÿÿÿ kind of noise in the feedback loops by which some programs had
ÿÿÿÿ compensated for their own rounding errors, so those programs lost
ÿÿÿÿ their high accuracies. These anomalies were not "bugs"; they were
ÿÿÿÿ "features" designed into the arithmetic by designers who thought
ÿÿÿÿ nobody would care. Customers did care; the arithmetic was
ÿÿÿÿ redesigned and repairs were retrofitted in 1967.
ÿÿÿÿ Not all Capriciously Designed Computer arithmetics have been
ÿÿÿÿ repaired. One family of computers has enjoyed notoriety for two
ÿÿÿÿ decades by allowing programs to generate tiny "partially
ÿÿÿÿ underflowed" numbers. When one of these creatures turns up as the
ÿÿÿÿ value of /T/ in an otherwise innocuous statement like
ÿÿÿÿ if T = 0.0 then Q := 0.0 else Q := 702345.6 / (T + 0.00189 / T);
ÿÿÿÿ it causes the computer to stop execution and emit a message
ÿÿÿÿ alleging "Division by Zero". The machine's schizophrenic attitude
ÿÿÿÿ toward zero comes about because the test for T = 0.0 is carried
ÿÿÿÿ out by the adder, which examines at least 13 of /T/'s leading
ÿÿÿÿ digits, whereas the divider and multiplier examine only 12 to
ÿÿÿÿ recognize zero. Doing so saved less than a dollar's worth of
ÿÿÿÿ transistors and maybe a picosecond of time, but at the cost of
ÿÿÿÿ some disagreement about whether a very tiny number /T/ is zero or
ÿÿÿÿ not. Fortunately, the divider agrees with the multiplier about
ÿÿÿÿ whether /T/ is zero, so programmers could prevent spurious
ÿÿÿÿ divisions by zero by slightly altering the foregoing statement as
ÿÿÿÿ follows:
ÿÿÿÿ if 1.0 * T = 0.0 then Q := 0.0 else Q := 702345.6 / (T +
0.00189 / T);
ÿÿÿÿ Unfortunately, the Same Computer designer responsible for "partial
ÿÿÿÿ underflow" designed another machine that can generate "partially
ÿÿÿÿ underflowed" numbers /T/ for which this statement malfunctions. On
ÿÿÿÿ that machine, /Q/ would be computed unexceptionably except that
ÿÿÿÿ the product 1.0 * T causes the machine to stop and emit a message
ÿÿÿÿ alleging "Overflow". How should a programmer rewrite that
ÿÿÿÿ innocuous statement so that it will work correctly on both
ÿÿÿÿ machines? We should be thankful that such a task is not
ÿÿÿÿ encountered every day.
Holy shit!! And modern compilers might optimize away the workaround.
Who was the designer? I asked "CoPilot" "Which computer designer
invented partial underflow" and with slight variations in the wording of
the prompt it suggested first Johann Joss, then Charles Babbage and
finally John von Neumann.
I assume the correct answer is either Gene Amdahl (or someone on his
team) or Seymour Cray (or someone on his team) ???
Prof William ?Mr IEEE-754? Kahan?s foreword to the ?Standard Apple
Numerics Manual? had this to say about some of those machines:
On 9/14/2026 21:10, Lawrence D?Oliveiro wrote:
Unfortunately, the Same Computer designer responsible for "partial
underflow" designed another machine that can generate "partially
underflowed" numbers ...
Who was the designer? I asked "CoPilot" "Which computer designer
invented partial underflow" and with slight variations in the
wording of the prompt it suggested first Johann Joss, then Charles
Babbage and finally John von Neumann.
I assume the correct answer is either Gene Amdahl (or someone on his
team) or Seymour Cray (or someone on his team) ???
This stuff is why I hate floating point.
Later IBM introduced a "commercial" subroutine library for the 1130
with nice stuff like decimal arithmetic, but we didn't have that
yet, so we used floating point, which allowed double precision. If
you've ever tried to do payroll calculations in floating point, my
only piece of advice is DON'T. I did learn a lot about the
nitty-gritties fo FP rounding.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 8 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 246:37:31 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 85,582 |