Path: 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> Sender: news@cwi.nl Organization: CWI, Amsterdam Lines: 42 In article 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