Xref: news2.mv.net comp.lang.c:55052 comp.lang.c++:70687 comp.os.msdos.djgpp:779 comp.std.c:4686 gnu.g++.help:4501 gnu.gcc.help:5701 From: tanmoy AT qcd DOT lanl DOT gov (Tanmoy Bhattacharya) Newsgroups: comp.lang.c,comp.lang.c++,gnu.gcc.help,gnu.g++.help,comp.os.msdos.djgpp,comp.std.c Subject: Re: float != float and floats as return types Date: 03 Feb 1996 17:56:44 GMT Organization: Los Alamos National Laboratory Lines: 99 Message-ID: References: <4ej9lb$mpc AT fu-berlin DOT de> <4elnjj$er4 AT server2 DOT rz DOT uni-leipzig DOT de> <4eqc7l$ugh AT godzilla DOT zeta DOT org DOT au> <4eqtu3$ddo AT der DOT twinsun DOT com> <4ettr4$al5 AT der DOT twinsun DOT com> NNTP-Posting-Host: qcd.lanl.gov In-reply-to: eggert@twinsun.com's message of 2 Feb 1996 12:57:08 -0800 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Note that I have added comp.std.c to the list of newsgroups. In article <4ettr4$al5 AT der DOT twinsun DOT com> eggert AT twinsun DOT com (Paul Eggert) writes: tanmoy AT qcd DOT lanl DOT gov (Tanmoy Bhattacharya) writes: > I do not agree with this interpretation, as the footnote (technically, > not part of the standard) clarifies: an assignment and cast both must > truncate the result to the required precision. Sorry, that footnote doesn't clarify matters. All the footnote says is that the required conversions must be performed. In the example we're talking about, there's no conversion to be performed, since both sides of the assignment have `float' type. There are two issues to be considered when interpreting the standard. In comp.std.c, the only concern is what the standard says and whether this is reasonable and consistent. In other discussions, including discussions of concrete implementations, I would guess what is important is also what the committee was trying to say, even if they did muddle up the issue. In this particular instance, the footnote would be completely redundant if the committee did not want the extra precision to be truncated. (At least, I cannot see any reason to put in the footnote otherwise.) Furthermore, even if there is a conversion, I don't see where the standard requires that excess precision be discarded. All the standard requires is that the result be ``represented exactly''; it doesn't say what it means by this, and an implementation that keeps excess precision is certainly representing _its_ result exactly. The standard explicitly licenses excess precision, and never explicitly (or implicitly, as far as I can see) requires excess precision to be discarded. Also please see ANSI C 3.3.4, which says ``A cast that specifies no conversion has no effect on the type or value of the expression''; this means that an implementation with extra precision is not allowed to discard it because of a cast of float to float. It is natural to assume that assignment of float to float can behave similarly to a cast. As you explicitly state, this is a conversion from float to float, so no conversion ought to take place according to the section quoted. This, I believe, needs to be corrected: I guess the possibility of extra precision was not thought of in this section. On the other hand, a conversion from double to float explicitly says (6.2.1.4) that the result is representable as a float exactly ... and quantities with extra precision is not. Hence, (float)(1.0/3.0) must be a value representable in a float (and I guess, representable is according to the guidelines in ), and, practically, it makes little sense to have (float)(x/y) have more precision if x and y are floats than if they were double or long double! Furthermore, in an expression like (a=b*c)+d, the semantics is explicitly specified in the standard. (b*c) may be evaluated in extended precision, the result stored into a, the new stored value of a is then to be added to d. As one is assuming that the stored value of a cannot hold the extra precision, the quantity added to d must be the truncated value. Hence, b*c+d can be different from (a=b*c)+d. It would not be practically useful to have (a=b*c)+d truncate whereas (float)(b*c) + d not truncate. I think, that unless the committee speaks otherwise, one can assume that cast and assignments indeed are intended to truncate. I realize that the standard is muddled in this area -- for example, the Rationale contradicts it, and I've been told that the C Standard committee may amend 3.3.4 because of the problem with floating point casts (surely an implementation should be allowed to discard excess precision whenever it wants to). That being the case, I think it wise for users not to rely on the fine points here, and my advice to the GCC implementers is to hold off on changing GCC's behavior until the C Standard committee acts. I, on the other hand, think that the current standard ought to be interpreted to mean that truncation is needed. Claiming that it is not needed is relying on the fine points. That is purely a personal opinion. The counter opinion that not truncating should be permitted on grounds of efficiency, I believe is a red herring. The C standard has already been written such that many useful optimizations cannot usually be performed by the compiler on floating expressions: a compiler is not free to rewrite a+b+c as a+(b+c) anyway (if a conforming program can detect the change, that is). For numerical work, one needs a flag which specifies standard-violating optimizations: or user coding of the exact transformations needed: with common subexpression recognition. Not truncating in the standard conforming mode is therefore neither useful nor necesary. Cheers Tanmoy -- tanmoy AT qcd DOT lanl DOT gov(128.165.23.46) DECNET: BETA::"tanmoy AT lanl DOT gov"(1.218=1242) Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544 Others see , or. -- fax: 1 (505) 665 3003 voice: 1 (505) 665 4733 [ Home: 1 (505) 662 5596 ]