From 941516601231451301 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7b33df5790e7ad92 X-Google-Attributes: gidf78e5,public From: jcoffin@taeus.com (Jerry Coffin) Subject: Re: complex design flaw (#1) Date: 1999/03/18 Message-ID: #1/1 X-Deja-AN: 455941052 Approved: Fergus Henderson References: <01be6e30$aeae59e0$7d9cd4c7@danielp.interlog.com> X-Original-Date: Tue, 16 Mar 1999 21:54:40 -0700 X-Complaints-To: news@news.unimelb.edu.au X-Trace: izvestia.its.unimelb.edu.au 921719609 14288 128.250.29.17 (18 Mar 1999 01:13:29 GMT) Organization: TAEUS X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANvBTGeEDnX0m9pzZAQHavwGAh50Sze6llKzrynb9fhzARPqRmUzwmlvs AjYTqqg4YNetKOKrZvuLvud31+uP3woe =qd9b NNTP-Posting-Date: 18 Mar 1999 01:13:29 GMT Newsgroups: comp.std.c++ In article , gdosreis@korrigan.inria.fr says... [ ... ] > | The reverse is NOT necessarily true -- in particular, any number in > | which the mantissa is zero has a value of zero, even if the exponent > | has non-zero bits. > > Again according to IEEE-754 that statement is untrue. For example if > the mantissa bits are zero and the exponent is max_exponent+1, then > you get what is called +/-Infinity according to the sign bit. If the > exponent is non-zero then you get 1.0*pow(2, exponent) beacuse of the > hidden bit. I was trying to be brief and presenting only a worst-case scenario. IEEE 754 doesn't guarantee that numbers will be normalized so there will BE a hidden bit. At least in the hardware of which I'm aware, double-extended is typically NOT implemented with a hidden bit. > | However, all of this is merely common practice: the C++ standard > | doesn't mandate that you use IEEE floating point (or anything > | particularly close to it), and there are still quite a few machines in > | the world that don't but may have C++ implementations anyway. I > > I agree. But it's a painful task to do *reliable* scientific numerical > computations on those machines. I'm not saying that IEEE-754 is the > best floating point model. I can hardly imagine a competitive > commercial numerical library that chooses to ignore IEEE floating > point. I agree -- however, I'm not sure that was that thrust of his question. If his primary interest was in reliable scientific numerical computation, he'd probably be better off asking in a different newsgroup. If his interest was in what the C++ standard guarantees WRT portability, this was the right place to ask, and I believe the answer I gave was basically correct. > | haven't tried to figure out for sure, but I believe you could do a > | perfectly legal implementation of C++ using something like BCD, and > | (for example) use the value zero in a nibble to represent "Negative", > | "NaN" or something similar. > > Based on IEEE-854? You could base it on IEEE 854 (or 954 IIRC), or you could implementing C++ on some ancient design that predates 854 or even 754, but 20 years or more... > | In the end, setting all bits of a floating point number to zero has > | only one effect according to the standard: undefined results. > > Except when you know that your C++ implementation adheres to > IEEE-754. Which you virtually never do -- even on hardware that implements quite a bit of IEEE 754 (which most modern hardware does) what you get out of it when it's running code generated by your C or C++ compiler may or may not (but usually will) differ at least slightly from what it would when set to run exactly by IEEE rules. In particular, quite a bit of hardware doesn't support denormals directly, and many compilers don't support them by default either. In the end, it's probably fairly safe on the range of hardware that we usually see software being ported from/to -- I, at least, see a lot of software being ported from *NIX to Windows NT, and the assertions in questions are pretty safe with most compilers in both these cases. I don't see a lot of software being ported between, say, either of these platforms and ancient mainframes that often have considerably...um... different (to use the kindest word I can think of) implementations of floating point. OTOH, even within this limited domain, you can run into problems in a hurry. For example, switching something from double to long double is a fairly innocuous change in a portable program -- about the worst it should ever do is slow things down considerably. OTOH, if you're relying on the constraints he gave, your program could suddenly quit working instead. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]