Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site masscomp.UUCP
Path: utzoo!watmath!clyde!bonnie!masscomp!carter
From: carter@masscomp.UUCP (Jeff Carter)
Newsgroups: net.arch
Subject: Re: IBM 360 float architecture problems
Message-ID: <744@masscomp.UUCP>
Date: Tue, 23-Jul-85 09:39:55 EDT
Article-I.D.: masscomp.744
Posted: Tue Jul 23 09:39:55 1985
Date-Received: Thu, 25-Jul-85 06:25:05 EDT
References: <741@masscomp.UUCP>
Reply-To: carter@masscomp.UUCP (Jeff Carter)
Organization: Masscomp - Westford, MA
Lines: 18
Keywords: Oops

My apologies to all those who noticed my error concerning
360 floating point format. That should teach me to trust my 
memory. But, I still wonder what the great advantage of chopped
arithmetic is ? That was the original subject of the article 
replied to. First the correction:: The IBM floating point format
(as with several other vendors) uses the same number of exponent
bits for all precisions. On to the other issue: One (alleged) advantage 
of chopped (as opposed to rounded) arithmetic is that you can never
overflow on a conversion of double -> single precision, given that
the number of exponent bits is the same. The only time this could 
occur is at the very edges of the dynamic range of representable
numbers. What you give up for this is one bit of precision on *all*
calculations. Is this a fair trade? I'm not entirely convinced.
If there are others who firmly believe that this is the best way to 
do it, I'm always glad to listen. 
I'm a firm believer in the IEEE representation. As Henry
Shaffer pointed out, 10^300 is sometimes a realistic number, so
it needs to be provided for.