home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
- From: tmb@arolla.idiap.ch (Thomas M. Breuel)
- Newsgroups: comp.lang.c++
- Subject: Re: Power Operator vs NANs
- Message-ID: <TMB.92Jul22122639@arolla.idiap.ch>
- Date: 22 Jul 92 16:26:39 GMT
- References: <1992Jul15.123527.3771@bnr.co.uk> <850@nazgul.UUCP>
- <TMB.92Jul21152204@arolla.idiap.ch>
- <1992Jul21.204639.2327@u.washington.edu>
- Sender: news@ai.mit.edu
- Reply-To: tmb@idiap.ch
- Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
- Perceptive)
- Lines: 109
- 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.
-
-