Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: $Revision: 1.6.2.16 $; site ima.UUCP Path: utzoo!linus!decvax!cca!ima!johnl From: johnl@ima.UUCP Newsgroups: net.arch Subject: Re: Re: IBM 360 float architecture probl Message-ID: <100000001@ima.UUCP> Date: Mon, 29-Jul-85 16:21:00 EDT Article-I.D.: ima.100000001 Posted: Mon Jul 29 16:21:00 1985 Date-Received: Tue, 20-Aug-85 00:16:14 EDT References: <4027@alice.UUCP> Lines: 18 Nf-ID: #R:alice:-402700:ima:100000001:000:887 Nf-From: ima!johnl Jul 29 16:21:00 1985 I started this argument about 360 floating point, so here's a final wart about chopping vs. rounding. The business about chopped arithmetic not overflowing when you convert to a shorter precision is a red herring. Sure, it's true, but it only affects two bit combinations out of 2^32, and that seems an awfully high price to pay for losing a bit of accuracy in each operation. Even IBM seems to have recognized this -- the only two rounding instructions they included in the instruction set are ones to convert from longer to shorter float formats. These instructions can overflow, of course. Finally, all of the 360's float formats have the same number of exponent bits, so they all have a dynamic range of 10 ^ +/- 75. I can't fault them for that as much as for the other stuff, since at the time the standard dynamic range for floats was only half that. John Levine, ima!johnl