Opinions on IEEE arithmetic - from Journal of C Translation

[David Hough]

Extracted from the complete results with permission of Rex Jaeschke,
who can tell you how to subscribe to get all the results of all the polls:

Date: Fri, 19 Jan 90 18:38:58 EST
From: aussie!rexauunet.UU.NET (Rex Jaeschke)
Subject: Results of Electronic Poll #3

This article will appear in Volume 1, number 4, March 1990. This is a 
'near-final' draft so a few slight changes may yet occur.

---------------------------------------------------------------------


			Electronic Survey Number 3

			Compiled by Rex Jaeschke

		Copyright 1990, Rex Jaeschke. All rights reserved.

%---------------------------------------------------------------

{Introduction}

Occasionally, I'll be conducting polls via electronic mail and
publishing the results.  (Those polled will also receive an e-mail
report on the results.)

The following questions were posed to 50 different people, with 19 of
them responding.  Since some vendors support more than one
implementation, the totals in some categories may exceed the number
of respondents.  Also, some respondents did not answer all questions,
or deemed them `not applicable.' I have attempted to eliminate
redundancy in the answers by grouping like responses.  Some of the
more interesting or different comments have been retained.

{Importance of POSIX and IEEE fp Standards}

{Is POSIX conformance an issue for you? What about IEEE
floating-point standards support?}

++ 13 -- POSIX conformance is important

++ 4 -- POSIX conformance is not important

++ 12 -- IEEE floating-point conformance is important

++ 4 -- IEEE floating-point conformance is not important

++ Comments:

++ IEEE 1003.1 conformance will become more important in the future. 
Our applications rely much more heavily on SVID than on POSIX.  I
think the other 1003 so-called standards are completely berserk.

++ Our applications neither need nor want IEEE floating point
features.  As an experienced numerical software developer, I disagree
with the whole philosophy behind IEEE 754.

++ Isn't life hard enough for us ANSI compiler writers without having
to worry about other standards too?

++ POSIX is vital because of the FIPS, and corresponding standards in
the European market.

++ Floating-point speed has been more important than IEEE support,
though this is starting to change.

++ POSIX conformance is just as important as ANSI C conformance.  Our
math libraries go out of their way for accuracy in supporting IEEE fp
standards.

{Shortcomings of ANSI C}

{What do you see as the biggest shortcoming of the ANSI C Standard,
as a language standard or in some missing functionality (in the
library or preprocessor, for example)?}

{{ To keep it an "extract", I've eliminated any identification of where
one commenter ends and another begins in the following - dgh  }}

The use of a global state in library functions, particularly errno
in the math library, causes a variety of problems.

Lack of adequate array support, particularly for matrix parameter
variable dimensions, unduly burdens numerical applications.

Note: We do not need standardized access to special hardware features
such as multithreading, vector processors, etc.  I think rigid
standards in such areas are harmful to the evolution of computing as
a whole.  Certainly these are not essential for the production of
portable applications.

The second biggest problem would be the lack of support for
multiprocessors, vector processors, and the like.  Very much
understandable though, given the lack of common practice.

And, of course, the issue NCEG is tackling: making C a replacement
for FORTRAN in the scientific world.

Second: Waffles too much around the edges on the functions.

Also, the automatic coercion on function call is dangerous.  For
example, if you have

	extern int abs(int);

then abs(-5.4) very unexpectedly yields 5 or 6.

As a compiler writer: The grouping rules (which say they are like
other languages but aren't like FORTRAN) and the lack of something
like noalias makes optimization with pointers almost impossible.

It would be nice if there were a way to handle the great
optimization needs that the ``noalias wars'' made so evident, but I'm
hoping for a clear direction to come from future implementations. 

Too many machine- or implementation-dependent features and poor
floating point support.

The standard never solved C's aliasing problems.  Ultimately this
limits the effectiveness of global optimizers since they have to make
very pessimistic assumptions about the effects of pointer
indirections.  This in turn forces the use of non-standard extensions
to support vectorization and just to improve global optimizations. 
Something like the proposed noalias extension (but better thought
out) would have been useful.

{Representation of long double}

{Do you or will you implement long double with a different
representation than double? If so, will that make three different
floating-point representations or are float and double mapped the
same?}

++ 5 -- float, double, long double all different

++ 10 -- float and double different, long double maps to double

++ 1 -- float and double the same, long double different

++ 0 -- float, double, long double all the same