Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mmintl.UUCP
Path: utzoo!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: net.arch
Subject: Re: IBM 360 float architecture problems
Message-ID: <503@mmintl.UUCP>
Date: Thu, 18-Jul-85 14:38:10 EDT
Article-I.D.: mmintl.503
Posted: Thu Jul 18 14:38:10 1985
Date-Received: Sat, 20-Jul-85 17:35:31 EDT
References: <36900010@ima.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 17
Summary: Its the worst case that counts


In article <36900010@ima.UUCP> johnl@ima.UUCP writes:
>Assuming that leading 
>digits are uniformly distributed from 0 to F, on the average there will be one
>leading zero bit.  But since we use hex rather than binary exponents, we can 
>make the exponent one bit smaller than if we had a binary exponent and the 
>fraction one bit bigger, and you don't lose any precision, get better
>exponent range, and it's faster since you need fewer normalization steps to
>normalize hex rather than binary numbers.  
>
>It turns out that leading digits are geometrically distributed so that on the 
>average there are two leading zeros rather than one, so you lose one bit that 
>way.

Actually, it's worse than that.  The proper measure of the precision is not
the average precision, but the worst precision -- the precision is what you
can count on in your results.  Thus you lose two bits, not one.