From 2169272812952508137 X-Google-Thread: f78e5,eb811809d4f61b12 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed-east.nntpserver.com!nntpserver.com!statler.nntpserver.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "Greg Herlihy" Newsgroups: comp.std.c++ Subject: Re: Using extended precision in floating point Date: Fri, 19 May 2006 11:48:29 CST Organization: http://groups.google.com Lines: 119 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1148006110.687041.224370@j73g2000cwa.googlegroups.com> References: <1147882581.972497.100340@u72g2000cwu.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1148006115 4180 127.0.0.1 (19 May 2006 02:35:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 19 May 2006 02:35:15 +0000 (UTC) Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@ucar.edu User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/418 (KHTML, like Gecko) Safari/417.9.3,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: j73g2000cwa.googlegroups.com; posting-host=70.231.131.123; posting-account=JdllFQ0AAAC-QghphnHMZz5q0GHnzGUJ X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-MIME-Autoconverted: from quoted-printable to 8bit by mulga.cs.mu.OZ.AU id k4J2ZTtF026934 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news2.google.com comp.std.c++:2069 kanze wrote: > As a result of a recent discussion in the French language > newsgroup, I am now unsure as to when the compiler can use > extra precision in floating point operations. > > �5/10 is clear with regards to expressions: "The values of the > floating operands and the results of floading expressions may be > represented in greater precision and range than required by the > type; the types are not changed thereby." It seems clear enough > here that in an expression like "(a + b) * c", the compiler can > do the entire expression in long double, even if all of the > variables are float -- and even if "a + b", processed as a > float, was equal to a. However, there is a footnote > (non-normative, I know) to the effect that "The cast and > assignment operators must still perform their specific > conversions as described in 5.4, 5.2.9 and 5.17." And �5.7/1 > says quite clearly that "The result of the assignment operation > is the value stored in the left operant after the assignment has > taken place;" I think we can conclude that the gcc's floating point optimization is both legal and one unambiguously allowed by the Standard. And to do so, we simply have to assume for a moment the other possibility - that the optimization is somehow prohibited by the Standard. But if the optimization were not in fact allowed, then the C++ Standard would be placed in the slightly ridiculous position of allowing floating point computations to be conducted with a greater degree of accuracy than the size of the types inherently support - while simultaneously ensuring that the results obtained are not "too accurate." Now how likely is it that the Standard expressly seeks to prohibit computations in C++ that are "too accurate"? Assuming that we believe that the C++ Standards committee is composed of (predominately) rational individuals - who meet and partake in (largely) rational discussions - and who reach decisions on a (more-often-than-not) rational basis - then it is simply inconceivable that such a group would ever decide that a particular computation in C++ was "too accurate" for a program's own good and had to be made less so. Otherwise we should well expect that the Committee will also decide that C++ is "too useful" or "solves too many real-world problems" or the that the language is currently "too easy to learn" or - worse yet - that "the C++ computer language is superior to every other computer language by an intolerably wide margin". So until the Committee takes on those more pressing issues, I think it is safe to say that we will never have a chance to read the minutes of the meeting at which the C++ Committee deemed a set of computations as simply "too accurate" for the language to countenance. It will never happen. > I would have normally interpreted this to mean that if I write > something like "(a += b) * c", the value multiplied by c must be > the actual value of the float, and not the extended precision > value which the compiler was allowed to use when there was no > assignment. Even more so, I would have interpreted this to mean > that in a bit of code like: > > float total = 0.0 ; > for ( size_t i = 0 ; i < size ; ++ i ) { > total += array[ i ] ; > } > > where array is float*, the compiler must ensure that the results > are exactly the same as those that it would have obtained by > storing the value to total each time in the loop, and rereading > the stored value in the expression. Moreover it is not necessary to decide that gcc's optimization is legal solely on our faith in the collective lucidity of the C++ Standards committee (and in fact some individuals may be understandably hesitant to place such a wager in the first place). Fortunately, the text of the Standard itself provides all of the information needed to reach the same conclusion. The first observation to make is that the variable "total" in the above loop is a floating point operand - and remains a floating operand for each iteration of the loop. Therefore its value representation may exceed the precision inherently supported by a float. The second observation to make is that - despite its extended precision - total remains a float type ("the types are not changed thereby"). And since the righthand side of the expression is also a float type, the entire operation is a strict float-to-float compound assignment, so no conversion ever takes place. In other words, the footnote cited has no relevance in this situation. And viewing this loop in practical terms, there is no reason at all why the compiler would have to discard total's extended precision upon each iteration of the loop. The extended precision would have to be discarded only if total were not an operand - for example, if total were passed as a parameter to a function call. So only in those cases in which the size of the float's represented value becomes a factor - such as for I/O operations or for storage - would the compiler be forced to discard any extended precision. To do so at any other time would simply impair computational accuracy - and while an implementation is free to follow such a course - the Standard for its part could no motivation (other than to prevent overly accurate computations) for requiring such behavior. In fact, were the compiler to discard total's extended precision upon each iteration of the loop, then its extended precision would be rendered useless - the final tally would be unchanged from the precision supported by a float inherently. In other words, instead of limiting the degree of additional accuracy for a floating point calculation, the Standard would be nullifying it altogether in this case. And no matter how dim one's view of the C++ Standard or the degree to which one may question the motives of its committee's members - I don't think any (rational) person would ever sincerely believe that the Standard really sets out to permit extended precision floating calculations only to the extent that the values of any results computed - are not to be affected. Greg --- [ 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://www.comeaucomputing.com/csc/faq.html ]