None

[Jim Thomas]

RE>None                                                  9/13/95      10:58 AM

David,

Let me take the opportunity of your recent posting, highlighting the need for
a standard IEEE-arithmetic programming environment, to offer status on the C
committees' efforts in this direction.

The PostScript version of  "Floating-Point C Extensions"

ftp://ftp.dmk.com/DMK/sc22wg14/c9x/floating-point/TR/fpce.ps.gz

is from the final draft of the ANSI C committee's Technical Report on
Numerical C Extensions.  The official paper version of the TR is due out later
this year.  

FPCE does specify an IEEE-arithmetic programming environment.  It actually
gives two levels of specification, one for all implementations and one for
IEEE implementations:   the general level includes all the interface, and
specification for floating-point predictability;  the second level gives the
IEEE binding to this interface and some tighter implementation requirements
for IEEE systems.  This approach not only provides utility for all systems,
but also helps with portability between IEEE and non-IEEE systems.  

Currently the C committee is considering FPCE for inclusion in C9X.  The TR
has been recast as four papers, which constitute a detailed C revision
proposal:

1. Floating-point arithmetic-C9X edits
2. Floating-point <fp.h>
3. Floating-point environment <fenv.h>
4. Annex X: IEEE standard floating-point arithmetic

Papers 1-3 include FPCE's general specification.  Paper 1 addresses the
language part of the standard.  Papers 2 and 3 are new clauses for the
libraries part of the standard.  

Paper 4 includes FPCE's specification for IEEE systems, currently proposed as
"informative".  The assumption is that this annex to C9X, though
non-normative, would effectively establish the long awaited standard IEEE
programming environment.  (Reasonable?)

The TR's specification for (a) widest-need expression evaluation and (b) wide
parameters, function returns, and local variable is not being proposed for
C9X, primarily because of lack of prior art.  With the proposal in papers 1-4,
an implementation could offer them as extensions.  

People interested in IEEE support might also want to see the "Complex C
Extension" chapter of the TR:

ftp://ftp.dmk.com/DMK/sc22wg14/c9x/complex/cce/complex.ps.gz

which defines extensions for complex arithmetic that are consistent with IEEE
real arithmetic. For C9X, the C committees are considering this proposal, and
a competing proposal without IEEE consistency: 

 ftp://ftp.dmk.com/DMK/sc22wg14/c9x/complex/noimag/complex-simplified.ps.gz

The key to IEEE consistency is imaginary types, which offer additional
benefits of storage/algorithm efficiency and better modeling for complex
analysis.

-Jim

--------------------------------------
Date: 9/11/95 4:25 PM
To: Jim Thomas
From: dmgaresearch.att.com
to- (validgh!numeric-interestaEng.Sun.COM)
from- David M. Gay (dmgaresearch.att.com)
re- IEEE arithmetic

Lately there has been much noise -- and little signal -- about IEEE
arithmetic in this newsgroup.  Although many systems can claim to
offer hardware IEEE arithmetic, all too often programmers of these
systems do not see proper support for that arithmetic, and thus are
not really computing in an IEEE-arithmetic environment.

Readers who have been following this newsgroup for a while will recall
the Numeric C Extensions Group (NCEG), which labored mightily to
propose extensions to C and its standard libraries that would give
programmers a genuine IEEE-arithmetic programming environment.  NCEG
became a subcommittee of X3J11 (the C standards committee) and
produced a report, whose current draft appears to be

	ftp://ftp.dmk.com/DMK/sc22wg14/c9x/floating-point/TR/fpce.ps.gz

The Forward to this draft well describes the sorry situation that
prompted many of the recent postings.  In part, the Forward says

	...  The IEEE standards do not include language bindings -- a
	cost of delivering the basic standard in a timely fashion.  ...
	Expediencies of programming language implementation and
	optimization can deny the features offered by modern hardware.
	In the meantime, particular companies have defined their own
	IEEE language extensions and libraries...; not surprisingly,
	lack of portability has impeded programming for these
	interfaces.

------------------ RFC822 Header Follows ------------------
Received: by taligent.com with SMTP;11 Sep 1995 16:24:23 -0800
Received: from taligent.com by mailserv.taligent.com (AIX 3.2/UCB 5.64/4.03)
          id AA45399; Mon, 11 Sep 1995 16:25:02 -0700
Received: from relay3.UU.NET by taligent.com with SMTP (5.67/23-Oct-1991-eef)
	id AA14742; Mon, 11 Sep 95 16:24:30 -0700
	for 
Received: from uucp2.UU.NET by relay3.UU.NET with SMTP 
	id QQzgue17039; Mon, 11 Sep 1995 19:14:17 -0400
Received: from validgh.UUCP by uucp2.UU.NET with UUCP/RMAIL
        ; Mon, 11 Sep 1995 19:14:18 -0400
Received: from sun.UUCP by validgh.com (4.1/SMI-4.1)
	id AA01044; Mon, 11 Sep 95 15:27:01 PDT
Received: from snail.Sun.COM by sun.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13828; Mon, 11 Sep 95 15:01:47 PDT
Received: from Eng.Sun.COM (engmail1) by snail.Sun.COM (4.1/SMI-4.1)
	id AA01768; Mon, 11 Sep 95 15:01:44 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM
(5.x/SMI-5.3)
	id AA21231; Mon, 11 Sep 1995 15:01:37 -0700
Received: from research.att.com by mercury.Sun.COM (Sun.COM)
	id PAA03509; Mon, 11 Sep 1995 15:01:26 -0700
From: dmgaresearch.att.com
Message-Id: <199509112201.PAA03509amercury.Sun.COM>
Date: Mon, 11 Sep 95 17:40 EDT
To: engmail1!validgh!numeric-interestasun.Eng.Sun.COM