"John W. Kennedy" <jwkenne@[EMAIL PROTECTED]
> wrote in message
news:O%uyf.24$pp1.17@[EMAIL PROTECTED]
> robin wrote:
> > "John W. Kennedy" <jwkenne@[EMAIL PROTECTED]
> wrote in message
> > news:YCXxf.66$Fd6.27@[EMAIL PROTECTED]
> >> robin wrote:
> >>> "John W. Kennedy" <jwkenne@[EMAIL PROTECTED]
> wrote in message
> >>> news:E1Uxf.1208$l03.452@[EMAIL PROTECTED]
> >>>> hancock4@[EMAIL PROTECTED]
wrote:
> >>>>> John W. Kennedy wrote:
> >>>>>> It is very well known that the entire 360 FP feature could have
used
> >>>>>> some input from numerical analysts; it's shot full of design
defects.
> >>>>> Could you elaborate on those design defects?
> >>>>>
> >>>>> How did S/360 compare with its predecessor machines (ie 709x)
regarding
> >>>>> those defects? What differences did competitors machines--those
> >>>>> available in 1965--have compared to S/360 regarding these defects?
> >>>> To start with, the S/360 word was four bits shorter than the 704
word.
> >>>> This was, at least, a strategic error, because it meant that
/up/grading
> >>>> to a 360 meant, in this area, a /down/grading in function.
> >>> Yes and no. Double precision gave 28 extra bits.
> >> The 704 family offered double precision, too; it was not fully
> >> implemented in hardware, but the hardware assisted it, and the
FORTRAN
> >> compiler sup****ted it.
> >
> > It had to, in order to meet the standard.
>
> There was no FORTRAN standard until long afterwards.
IBM set it.
> >>> But for most work, little difference between 36 bits and 32 bits.
> >>> But that's no measure, anyhow. The appropriate measure is
> >>> the number of mantissa bits and range of exponent.
> >> They add up to the word size, one way or the other.
> >
> > Not relevant; what's im****tant is the breakdown --
> > and in particular, the number of mantissa bits.
>
> In order to make any sense of your argument, I can only assume that you
> do not know what the words "relevant" and "mantissa" mean. Kindly look
> them up.
The term "mantissa" has been used since the early days of computers
to describe part of floating-point number.
Are you having a bad day?
> >> In any case, the
> >> S/360 had significantly fewer effective fraction bits (21) in single
> >> precision than the 7094 (27).
>
> > Leaving only 7 bits for the exponent. In other words, a reduced
> > range of exponent, which the S/360 corrected.
>
> Having trouble with subtraction, are we now?
When I last looked, 27 + 1 + 7 + 1 = 36.
> >> In practice, a very, very large number of
> >> FORTRAN programs had to be altered to use double precision where
single
> >> precision had once served.
>
> > I do not recall receiving a single complaint of that category,
> > even though the machine that we upgraded from used 31
> > mantissa bits for scientific work.
>
> Then you were doing unusually undemanding work; plenty of shops had
> major problems.
Research is typically demanding.
>>>The _whole_ S/360 architecture was copied, but, whereas the 8/16/32/64
>>>two's-complement, byte-addressable data architecture has become
>>>universal, the S/360 floating-point design was never used outside of
the
>>>context of full S/360 compatibility, and the modern descendants of the
>>>S/360 now offer the vastly superior IEEE-754 as an alternative. Note,
>>>too, that floating-point has become nearly a dead issue in the S/360
>>>world; the z/OS FORTRAN compiler is decades old, and several
generations
>>>out of date.
You're overlooking, PL/I, which for which z/OS has a recent compiler.
> > The S/360 was not copied in its entirety,
>
> Problem state was.
Only the original, not the revised hardware, as I previously stated
(below).
> > and even in those
> > cases where it was not copied in its entirety, the
> > original hex floating-point design was retained
> > (without guard digit on double, with zero for underflow, etc)
>
> I'm sure IBM spent all that money upgrading all those machines without
> payment just for fun.
AFAIK, no-one else followed suite.
> > Strange, we got along well with F.P.
> > And both machines that we subsequently obtained used
> > the original hex floating point (without guard digit, etc).
> > It is clear that it was not the problem that you imagine.
>
> It is clear that it wasn't a problem for /you/.
It wasn't a problem for anyone in an extensive institution.
> (Or, alternatively, that
> it /was/ a problem, but you didn't audit your results adequately.)
My results were always "audited". So were those of others.
> > So-called "clones" retained the hex model without guard
> > digit on d.p. Strange, that.
> > How come *they* did not get "many problems"?
>
> You buy cheap imitations, you get cheap imitations.
I didn't buy anything. But I would point out that those
"cheap" systems had superior real-time performance, with
multiple resister sets and processor states for handling
interrupts.
> > And if it was as bad as you claim, how come they
> > never implemented something better?
>
> They did. In 1967,
No they didn't. I was referring to clones in which the guard digit
on d.p. was NEVER provided. [see above]
>>> the literature was awash with the subject.
>>Such as?
Still no instance?
>>> > How would you have done it better ?
Still no answer?
|
