I don't think too many people will argue that S/360 floating point was
"good," particularly single precision floating point. I think IBM tried
to get some numeric range at the expense of precision in 32 bit
hexadecimal floating point. I think the "4-bit ****ft is faster than the
1-bit ****ft" argument IBM laid on us in the 60s was entirely specious.
After all, IBM had been doing 1-bit ****fts for a good 10 years on the
704 / 709 / 7040 / 7044 / 7090 / 7094 before S/360 came along. Back
when I understood this kind of math better (and S/360 was introduced) I
tried to figure out these issues, and that was the conclusion I reached
then. Hardware was too expensive in those days for the IEEE trick of
have a smaller range limit for 32 bit than for 64 bit floating point.
In any event, I wrote up this program -
FL CSECT
USING *,15
LE 0,DATA4
DE 0,E4
STE 0,RES4
LD 0,DATA8
DD 0,D4
STD 0,RES8
DC H'0'
DATA4 DC E'.9'
E4 DC E'4'
RES4 DC E'0'
DATA8 DC D'.9'
D4 DC D'4'
RES8 DC D'0'
END FL
When I ran the program, I got these results -
l (data4 res4 e4 data8 res8 d4)
DATA4 +.89999998 E+ 0
RES4 +.22499996 E+ 0
E4 +.4 E+ 1
DATA8 +.89999999999999999 E+ 0
RES8 +.22499999999999999 E+ 0
D4 +.4 E+ 1
l (data4 res4 e4 data8 res8 d4) x
DATA4 40E66666
RES4 40399999
E4 41400000
DATA8
+0 40E66666 66666666
RES8
+0 40399999 99999999
D4
+0 41400000 00000000
Now, it seems clear some precision was lost up front, on the conversion
of E'.9' to hex. Of course, any reasonable rounding conversion will
give me .9E0, but TSO TEST isn't always the greatest. The double
precision conversion seemed to do better.
When you convert the hex numbers to binary, you can see you have maybe
lost 1 bit of precision, since the low order bit of the input was 0, not
1. The same is true of the 8 byte numbers.
Glen - this business of normalizing the exponent by ****fting the
fraction does not apply with floating multiplication and division in a
big way. It only applies with addition and subtraction. This is where
S/360 single precision floating point really broke down.
Another goof IBM made with S/360 hexadecimal floating point is they did
not do rounding. Clearly, RES4 would be 4039999A if IBM had done
rounding.
glen herrmannsfeldt wrote:
> robin wrote:
>
> (snip)
>
>> The precision of S/390 is 21 bits or 53 bits.
>> You don't lose this precision on division by 4.
>
> The precision is between 21 and 24 for short, and between
> 56 and 53 for long. The algorithms for the most libraries
> were designed not to lose precision unnecessarily.
>
> 0.9 has 24 bits of precision in short float. Divide it by
> four and it loses two bits. Multiply or divide the result by four
> and you don't gain them back again, though the bits are again
> available. That is precision loss.
>
> -- glen
>
|
