From Robert.Corbett@Eng.Sun.COM Thu May 8 05:31:48 1997 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id FAA16072 for ; Thu, 8 May 1997 05:31:46 +0200 Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA07248 for ; Wed, 7 May 1997 20:43:18 -0700 Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA14036; Wed, 7 May 1997 20:31:12 -0700 Received: from lupa.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA12811; Wed, 7 May 1997 20:31:10 -0700 Received: by lupa.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA13545; Wed, 7 May 1997 20:31:21 -0700 Date: Wed, 7 May 1997 20:31:21 -0700 From: Robert.Corbett@Eng.Sun.COM (Robert Corbett) Message-Id: <199705080331.UAA13545@lupa.eng.sun.com> To: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1375) Floating-point arithmetic X-Sun-Charset: US-ASCII ----- Begin Included Message ----- From Mailer-Daemon@engmail2 Wed May 7 18:54:16 1997 Date: Wed, 7 May 1997 18:54:15 -0700 From: Mailer-Daemon@engmail2 (Mail Delivery Subsystem) Subject: Returned mail: User unknown To: Content-Length: 3426 X-Lines: 78 The original message was received at Wed, 7 May 1997 18:54:12 -0700 from kindra.Eng.Sun.COM [129.146.77.35] ----- The following addresses had delivery problems ----- (unrecoverable error) ----- Transcript of session follows ----- ... while talking to sunuk.uk: >>> RCPT To: <<< 553 ... Never heard of host dkuug in domain UK.Sun.COM 550 ... User unknown ----- Original message follows ----- Return-Path: Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA07400; Wed, 7 May 1997 18:54:12 -0700 Received: from lupa.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA08056; Wed, 7 May 1997 18:54:11 -0700 Received: by lupa.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA13541; Wed, 7 May 1997 18:54:21 -0700 Date: Wed, 7 May 1997 18:54:21 -0700 From: corbett@kindra (Robert Corbett) Message-Id: <199705080154.SAA13541@lupa.eng.sun.com> To: malcolm@nag.co.uk Subject: Re: (SC22WG5.1375) Floating-point arithmetic Cc: sc22wg5@dkuug.uk X-Sun-Charset: US-ASCII content-length: 2307 > Robert Corbett said: > > IEC 559 includes direct rounding modes specifically to > > make the implementation of interval arithmetic easier. > > I do not doubt Robert's greater familiarity with the authors of IEEE 754, > however: > > IEEE 754 has no rationale for directed roundings (section 4.2). > OTOH, it does have rationale for rounding precision (section 4.3) [this is > not to do with interval arithmetic though] The IEEE floating-point standard, like many other standards, does not include a rationale. The IEEE floating-point group published papers in IEEE Micro and in IEEE computer while the standard was under development. Those papers provided the rationale for decisions made in the IEEE floating-point standard. Early drafts of the standard had even more support for interval arithmetic than the approved standard. For example, projective infinity was included to support division by intervals that included zero. When the standard got into trouble because it was perceived to be too complex, those additional features were axed. > Moreover, directed roundings are rather useful in REAL->INTEGER conversion, > when "round-to-nearest" is often not what is required. (CEILING, FLOOR and > INT provide the directed rounding versions of this operation). Most CPUs that support IEEE floating-point conversions in hardware provide special instructions to do floating-point to integer conversions. Those instruction chop regardless of the rounding mode. The problem is that changing the rounding mode is typically expensive. When Motorola dropped their instruction for doing such conversions on the 68040, people writing software for the 68000 family were very upset. > > Be careful what you ask for. If you don't want interval > > arithmetic, you probably do not want most of what IEC 559 > > requires either. > > I do not agree at all. Almost none of IEEE 754 has anything to do with > interval arithmetic. Almost all of IEEE 754 has general applicability. I am still waiting for the first compiler that generates code to signal the inexact condition for each use of an inexact floating-point constant and that determines the value of such a constant based on the rounding mode as required by the standard (see Section 5.6, paragraph 7). I look forward to the day when the Fortran standard includes such requirements. Sincerely, Bob Corbett