On Fri, 3 Feb 2006 16:48:52 +0000 (UTC), Randy Hudson <ime@[EMAIL PROTECTED]
>
wrote:
> In article <ops4em4fgszgicya@[EMAIL PROTECTED]
>, Tom Linden <tom@[EMAIL PROTECTED]
>
> wrote:
>
>> On Fri, 03 Feb 2006 15:05:02 GMT, robin <robin_v@[EMAIL PROTECTED]
> wrote:
>>
>>> "John W. Kennedy" <jwkenne@[EMAIL PROTECTED]
> wrote in message
>>> news:E1Uxf.1208$l03.452@[EMAIL PROTECTED]
>>>
>>>> But the hexadecimal base further meant that the effective length of
>>>> the
>>>> fraction was essentially 21 bits (single precision) or 53 bits
(double
>>>> precision), rather than the superficial 24 or 56, and this was not
>>>> clearly understood at first.
>>>
>>> How would you have done it better?
>>>
>> Biased binary exponet and suppress the leading bit of the normalized
>> characteristic.
>
> As was pointed out earlier in the thread, that would nearly quadruple
the
> expected number of ****fts needed during normalization, slowing FP
> operations
> considerably. The idea of the 360 as a General-Purpose computer
required
> that it not be hopelessly slow at floating point operations, and that
> floating point be affordable enough that most machines would be
purchased
> with the FP option; that in turn would allow amortization of the costs
> of FP
> design and tooling over many customers, keeping the costs low and
profits
> high.
>
You may be right, it is 30 years since I designed a floating point unit,
but
I used a barrel ****fter. Why does it quadruple the number of ****fts?
|
