Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site fortune.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!fortune!phipps
From: phipps@fortune.UUCP (Clay Phipps)
Newsgroups: net.micro.68k,net.arch
Subject: Nothing New Here / Re: VAX Floating Point
Message-ID: <4190@fortune.UUCP>
Date: Tue, 11-Sep-84 15:48:03 EDT
Article-I.D.: fortune.4190
Posted: Tue Sep 11 15:48:03 1984
Date-Received: Wed, 12-Sep-84 01:13:50 EDT
References: <1191@rti-sel.UUCP>
Organization: Fortune Systems, Redwood City, CA
Lines: 28

> ... the floating point on the VAX ... makes perfect sense 
> when you look at what you can do with it. 
> The 32 and 64 bit floating point formats 
> are identical in the first 32 bits.
> The 64 bit format just adds more precision bits. 
> This allows a user to reference a 64 bit floating point value 
> as if it were a 32 bit one without any conversion. 
> It also allows a user > to reference a 32 bit floating point value 
> as if it were a 64 bit floating point one without any conversion. 

Strange, this sounds like a description of the floating point formats
on the IBM 360, an architecture that preceded the VAX by a few years
(about 14 years, actually: 1964 versus 1978).
Many numerical analysis types think that the IBM 360 floating-point
is one of the worst.  Among other things, I think many people believe
that they are entitled to a few more exponent bits when they *double*
the size of each data value (from 32 to 64 bits).
The hexadecimal (i.e., 4 bits instead of 1 bit) normalization on the 360
reduces the effective precision of floating-point numbers
and is another source of irritation to numerical analysis people;
I'm not sure what the VAX does on this one.

-- Clay Phipps

-- 
            { amd  hplabs!hpda  sri-unix  ucbvax!amd }          
                                                      !fortune!phipps
   { ihnp4  cbosgd  decvax!decwrl!amd  harpo  allegra}