Mail Archives: djgpp/1996/02/04/11:05:12
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 <float.h>), 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 <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003 voice: 1 (505) 665 4733 [ Home: 1 (505) 662 5596 ]
- Raw text -