🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11823

Re: IEEE floating point

#11823
From: Dik T. Winter
Date: Tue, 28 May 1991 01:48
42 lines
2604 bytes
In article <MCCALPIN.91May27092950@pereland.cms.udel.edu> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes:
 > Just so no one can complain too much about "anecdotal evidence", here
 > are the results from my study:
I did believe you before you posted these results.  The remaining question
is, how much of the bad ETA-10 results is due to software, and how much is
due to hardware.  I have seen the 205 compiler at work, and the results were
mediocre at least.  Testing elementary functions I found that the 'HALF
PRECISION' (32 bits) arcsine gave better results then the 'REAL' (64 bits)
arcsine!  I presume a software problem.  On the other hand, it is provable
that the Cray can loose 5 ULPS in precision on a division.  I do not think
the ETA-10 goes beyond 1.5 ULP (and IEEE gives 0.5 ULP of course).  In general,
when giving such a table you ought to give the precision in mantissa size.
I think it is:
			number size	mantissa size
  ETA-10		32 bits		23 bits
  IBM 3081		32 bits		24 bits (6 hex digits)
  VAX/IEEE/RS6000	32 bits		24 bits

  ETA-10		64 bits		47 bits
  Cray			64 bits		48 bits
  IBM 3090		64 bits		56 bits (14 hex digits)
  VAX D			64 bits		56 bits
  IEEE/RS6000		64 bits		53 bits

  ETA-10		128 bits	95 bits (software)
  Cray			128 bits	96 bits (software)

However, due to the way arithmetic works, I generally give penalties both
to ETA-10 (Cyber 205) and Cray arithmetic.  In the case of ETA-10 (Cyber 205)
I generally say that precision is 22 bits, resp. 46 bits.  For the Cray the
penalty is 3 bits if division is heavily used, 1 bit otherwise.  For
the 128 bit precision the penalty is larger.  For both the arithmetic
failures are documented, although fairly inaccessible.

I have no idea about the bad results of the RS6000.  My only suggestion is
that there is probably some problem with the translation to and from IEEE
from and to the internal hex code used.  (Yes, contrary to most machines
the external visible representation of FP numbers does not match the
internal representation on the RS6000.)
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl
Technical Details
Message-ID: <3596@charon.cwi.nl>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!cwi.nl!dik
References: <1991May25.222551.16365@zoo.toronto.edu> <MCCALPIN.91May26100257@pereland.cms.udel.edu> <MCCALPIN.91May27092950@pereland.cms.udel.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!cwi.nl!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: IEEE floating point
Message-ID: <3596@charon.cwi.nl>
Date: 28 May 91 01:48:26 GMT
References: <1991May25.222551.16365@zoo.toronto.edu> <MCCALPIN.91May26100257@pereland.cms.udel.edu> <MCCALPIN.91May27092950@pereland.cms.udel.edu>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 42