From 2963134681439434608 X-Google-Thread: f78e5,eb811809d4f61b12 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: kanze.james@neuf.fr (James Kanze) Newsgroups: comp.std.c++ Subject: Re: Using extended precision in floating point Date: Sun, 21 May 2006 14:16:56 GMT Organization: Aioe.org NNTP Server Lines: 227 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1147882581.972497.100340@u72g2000cwu.googlegroups.com> <1148006110.687041.224370@j73g2000cwa.googlegroups.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1148221023 17500 158.152.254.254 (21 May 2006 14:17:03 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 21 May 2006 14:17:03 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Thunderbird 1.5.0.2 (X11/20060420) X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id k4LEH0tF010458 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id k4LEGu6X010423; Mon, 22 May 2006 00:16:56 +1000 (EST) X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news2.google.com comp.std.c++:2075 Greg Herlihy wrote: > 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. >> =A75/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 =A75.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. I think that it is possible to interpret the standard this way. I'm pretty sure that this isn't the intent, or the most reasonable interpretation. > And to do so, we simply have to assume for a > moment the other possibility - that the optimization is > somehow prohibited by the Standard. We don't have to assume anything. We just have to read 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." If you want to do rigorous numeric calculations, you do need to enforce the precision at some points, to exactly that which you want (or at least to something defined). Otherwise, the results are not reproducible. > 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. I'd say the situation is that the standard is trying to satisfy both camps. If you want the exact precision, you can assign or cast to the correct type, and if you can accept greater precision, you get that by default. Most of the time, I suspect that the greater precision is an advantage, but if you are trying to prouve the mathematical stability of a convergence, I'm not sure. The point is, of course, if you're doing that sort of thing, you'd better know numerics enough to know when you need the deterministic results, and insert the assignments or the casts to enforce them. In the case of g++, as we see, it is impossible to get deterministic results. (Actually it's not -- there's an option to do so that I hadn't seen.) Without a possibililty to get deterministic results, I don't think that you could use the compiler (or the language, if this were what the standard actually says) for any serious numerical work. (There was a lot of discussion about this when C was being standardized. In particular, in K&R C, the compiler was allowed to rearrange expressions according to mathematical identities. This was banned by the C standard, because it made the language unusable for any serious floating point work.) > 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 th= e > language to countenance. It will never happen. It would help if 1) you read up on numeric processing, and 2) you actually read the standard. It's not a question of "too accurate", but of "deterministic results". It's very hard to reason about anything if the results of a given expression are not always the same. >> I would have normally interpreted this to mean that if I write >> something like "(a +=3D 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 =3D 0.0 ; >> for ( size_t i =3D 0 ; i < size ; ++ i ) { >> total +=3D 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. My contention is that it doesn't. At least not well enough -- the intent, and the most reasonable reading, is that this optimization is illegal. And while it doesn't cause problems here, without some way of suppressing it, it becomes seriously difficult to do certain types of numeric processing. > 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. As it happens, total is also a variable which is being assigned to. The footnote to =A75/10 (not normative, but very indicative of intent) states clearly that "the cast and assignment operators must still perform their specific conversions as described in 5.4, 5.2.9 and 5.17." =A75.17 says that 1) "The result of the assignment operation is the value stored in the left operand after the assignment has taken place", and 2) "If the left operand is not of class type, the expression is implicitly converted (clause 4) to the type of the left operand." And in =A74.8, we find that "If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values." No liberty of extended precision anywhere there. > 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. Except that I, the programmer, told it to. Using the means the standard provided for me to do so. > 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. That's in direct contractition with =A75.17. > 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 this case. Because that's what I asked for. If I had wanted the extended precision, presumably, I would have asked for long double. Extended precision is legal within an expression, unless I explicitly tell the compiler not to use it, by means of a cast. (C99 goes much further in this regard, and provides a pragma to forbit the extended precision. Due to demand from the numerics community.) > 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 member= s > - I don't think any (rational) person would ever sincerely believe tha= t > the Standard really sets out to permit extended precision floating > calculations only to the extent that the values of any results compute= d > - are not to be affected. It obviously affects the results. Which is why many numeric experts condenm it, and why C99 felt it necessary to provide a global means of suppressing it. The problem here is that I've actually used the means provided by the C++ standard to suppress it, and the compiler didn't. And that, regretfully, part of the text which makes it 100% clear that it should be suppressed is in a footnote, and not normative. --=20 James Kanze kanze.james@neuf.fr Conseils en informatique orient=E9e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France +33 (0)1 30 23 00 34 --- [ 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 ]