From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Power Operator vs NANs
Date: 22 Jul 92 16:26:39 GMT
	<TMB.92Jul21152204@arolla.idiap.ch>
	<1992Jul21.204639.2327@u.washington.edu>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: rons@hardy.u.washington.edu's message of 21 Jul 92 20:46:39 GMT

In article <1992Jul21.204639.2327@u.washington.edu> rons@hardy.u.washington.edu (Ronald Schoenberg) writes:

   >I would want neither. The behavior of operator== on NaN's should be
   >left undefined. If you care to know whether operator== is operating on
   >a NaN, you should simply test beforehand:
   >
   >	if(isnan(x)||isnan(y)) { ... }
   >	else if(x==y) { ... }
   >
   >Sadly, this is a losing battle. NCEG seems to be determined to go down
   >this route of adding lots of IEEE specific, complicated, useless
   >operators, and the C++ language is likely to follow suite.

   I'm not sure I understand - why is better to leave the effect of NaN's
   on operator == undefined?

Programs that assume special behavior of NaN's when given as arguments
to operator== are unportable, since they rely on a machine-specific
feature (a particular implementation of IEEE floating point).  So far,
the C standard has been designed such that most (all?) unportable
programs have been "in error", and conforming implementations could
legally detect and report such errors. Writing a machine-specific
feature into the language standard would prohibit implementations from
detecting some unportable programs.

More concretely, defining the behavior of operator== on NaN's would
lead to people quietly relying on it and would be even another source
of undectable unportable assumptions in the C language. On the other
hand, if the behavior isn't defined, programmers will at least be
compelled by the language standard to test for NaN's explicitly.

   Why do you see NCEG as losing battle?

Please read carefully what I said. It is a "losing battle" trying to
stem the tide of IEEE-specific floating point operators. My statement
said nothing about NCEG as a whole.

   What do you really have against adding features that would benefit
   people like me who are doing numerics programming?

I do lots of numerical programming myself; otherwise, I wouldn't care
what happens to numerical extensions of C/C++.

   Your note seems to assume that I would know why "it's not time to
   leave behind non-IEEE floating point.  What exactly do non-numerics
   programmers have to lose with IEEE floating point?

There are lots of machines that do not support IEEE floating point.
I have to use such machines. Furthermore, I don't mind using such
machines: they tend to give me more crunch for less money, and they
solve most of my numerical problems efficiently and correctly.

In addition to hardware diversity, another reason not to come to rely
on IEEE-specific features is that most of the IEEE floating point
features are likely to be difficult or impossible to provide for
software-defined real number types.

   Maybe Walter Bright could tell us what the reaction is to Zortech
   C++.  Is there a deluge of criticism from non-numerics programmers?
   Or maybe they aren't even aware of (and don't care about) the NCEG
   extensions.

As I was saying, I have nothing against standardizing IEEE-specific
operations in header files. Since I write lots of numerical programs
myself, I consider such standards very useful.

What I dislike is assigning a special status to IEEE floating point in
C/C++ by providing special syntax and semantics for its features.
There are three main problems with that:

 * it will disadvantage non-IEEE implementations

 * it will likely lead to undetectable IEEE dependencies in programs
   (if you only rely on the special properties of NaN's with the C
   comparison operators, I have no way to determine whether you wrote
   your program with IEEE floating point in mind or not)

 * it cannot be implemented as a library or as macros, meaning
   that users of old compilers are out in the cold

The specific proposal that NCEG is considering (and, sadly, likely to
adopt) has the additional disadvantage that the meaning of something
like "x !<> y" is much less clear to the casual user of IEEE features
than an equivalent, explicit expression in terms of "isnan(x)".

IEEE-specific features can be provided through standardized header
files. This has no cost in terms of performance (the IEEE primitives
can still be inlined and optimized by the compiler), it requires the
user to declare that his program is dependent on IEEE floating point
if he wants to use IEEE features, and it can be implemented as a
library or header file for old compilers using nothing more than
macros and functions. Furthermore, for porting IEEE code to non-IEEE
machines, it allows me to redefine easily the meaning of the IEEE
primitives used by some algorithm.

C/C++ has made very few concessions to hardware-specific properties.
Word sizes are not fixed. The properties of "operator%" are not
defined. The character set is not defined. Machine specific properties
have always been defined through include files, for all of the reasons
that I have outlined above. I see no good reason to break with this
tradition to accomodate IEEE floating point.

					Thomas.

PS: In fact, even FORTRAN-77 and FORTRAN-90 do not seem to have any
IEEE-specific features. From what I understand, even FORTRAN-90 is
rather conservative with its numerical inquiry functions, and likely
so for good reasons.

Newsgroups: comp.lang.c++,comp.std.c++