🚀 go-pugleaf

In article <dG4db.598668$uu5.97984@sccrnsc04>,
"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:

 > An article by W. Kahan titled "How Java's Floating-Point Hurts Everyone
 > Everywhere" (and which describes much more than Java)  includes a
discussion
 > about the results of floating point multiply.

Where might one find this article?  Online?

 > According to his description, until 1963 IBM Fortran compilers would
 > generate double precision results for floating point multiply of two
single
 > precision numbers, at least when it was being summed into a double
precision
 > variable.  He then explains that IBM changed this in IBSYS 13,
anticipating
 > S/360.

They didn't change the way the 7090 and 7094 computed the result, which was
that the LSB of the 36x36 multiply was physically in a register --
available.  If the programmer had specified that the result of
single*single was to be placed in a double, then it could be, with no
further work.  Obviously, single=single*single didn't produce a double
result.

 > As far as I can tell, the Fortran-66 standard requires a single
precision
 > product when multiplying single precision numbers, though I don't know
how
 > much impact IBM had on Fortran-66.

I'd appreciate an exact quote on that.  I used to know X3.9-1966 awfully
well, and I don't recall that the Honeywell gear that I used after the 7094
and 360 and CDC 3300 had a standards violation in that regard.  My copy is
filed away, though.

 > The reason why this comment is surprising to me is that S/360 (along
with
 > S/370 and ESA/390) do not have a single precision multipy instruction
with a
 > single precision product.  The product is always double precision.  I
have
 > checked the code generated by both the G and H compilers, and both,
after
 > generating the multiply instruction generate at least two more
instructions
 > to truncate the product to single precision.

I wonder why they bother.  If the result is to be stored, the extra
precision goes away.  If it's to continue in a single-precision
computation, it doesn't help much -- only the first bit of the LSBs has any
effect on the next multiplication, and rounding introduces a possible error
of the same magnitude.

 > As far as I know, Fortran still requires floating point multiply to
generate
 > a result with no more precision than the arguments that went into it.
 > W.Kahan describes well the advantage of summing a double precision
product
 > of single precision arguments, yet the Fortran standard doesn't seem to
 > follow it.  (Someone with a more recent standard can comment on this.)

Honeywell had what are called overlength registers, as Tim Prince has
mentioned.  A 36-bit float was actually an 8-bit exponent and a 28-bit
fraction.  On loading these into registers, they went into an 8-bit
E-register, and a 36-bit (machine word-length) register.  A following
multiplication, for example, produced a normalized result by updating the
Exponent register, with overlength arithmetic product in the full-length
register.  That overlength product or other intermediate result was
maintained so long as the computation did not send a result to storage, but
a floating-store rounded the value properly and put it back into a 36-bit
(8+28 bit) float.  It was a terrific system and produced very good, very
acceptable to programmers, results.  I'm frankly skeptical that this
violated X3.9-1966.

 > I would, in the end, like to thank W.Kahan for his unceasing drive to
 > improve the results of floating point hardware and software, and hope
for
 > only constructive discussion of this problem.

That cite, so the rest of us could look at the article to which you're
referring, would be real nice.

I had to respond to government (US national government) queries about the
Honeywell overlength registers on a regular basis, and I used to include
with my replies to specific questions a copy of a paper by W. D. Maurer
(I'm pretty sure that's the one), from Communications of the ACM.  His
paper was on the results of floating point arithmetic operations on many
platforms, with the overlength issue a minor mention near the end of the
paper.  I don't have a precise cite but the paper came out in roughly 1972.
 It may just have been my magic personality or my renowned writing skills,
but I like to think that we pretty well settled all the concerns they had
about Honeywell's somewhat unusual arithmetic arrangement.  We were never
disqualified from a bid, and I don't recall any case in which we were
either marked-down or questioned further, once the potential customer had a
chance to review our specific comments and the paper from CACM.

      Edward Rice