From -3542348555827483454 X-Google-Thread: f78e5,4ba9dcb1ae436e16 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!news.cs.univ-paris8.fr!news.zanker.org!news.clara.net!wagner.news.clara.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: eric_backus@alum.mit.edu ("Eric Backus") Newsgroups: comp.std.c++ Subject: Re: Pi, Euler Number, and perhaps other 'natural' constants? Date: Thu, 29 Jul 2004 19:58:49 GMT Organization: Agilent Technologies Lines: 67 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <1091124795.877336@cswreg.cos.agilent.com> References: <5cydnSisJNo4yJncRVn-sQ@speakeasy.net> <1090949817.234275@cswreg.cos.agilent.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: news.demon.co.uk 1091131138 1250 158.152.254.254 (29 Jul 2004 19:58:58 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 29 Jul 2004 19:58:58 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Priority: 3 X-Cache-Post-Path: cswreg.cos.agilent.com!unknown@lkseric.lks.agilent.com 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 i6TJwnmP016708; Fri, 30 Jul 2004 05:58:49 +1000 (EST) X-NNTP-Posting-Date: Thu, 29 Jul 2004 18:13:16 +0000 (UTC) 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-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60-mulga_r1 (1.212-2003-09-23-exp) on mulga.cs.mu.OZ.AU X-Spam-Status: No, hits=-3.1 required=5.2 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60-mulga_r1 X-MSMail-Priority: Normal X-Spam-Level: X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1490 ""Daniel Pfeffer"" wrote in message news:ce88dn$bvl$1@news.inter.net.il... > ""Eric Backus"" wrote in message > news:1090949817.234275@cswreg.cos.agilent.com... > > 2. Clearly, PI should be provided to the maximum precision possible for > > the format. Providing this is trivial. > > Not necessarily. What happens when the C99 mechanisms are > incorporated into C++0x? The value of PI may change by 1 ulp, whhich may be > significant in interval arithmetic and perhaps other calculations. Good point, I had not thought that through (though it's not part of the standard yet, right?). Perhaps this means that the traditional #define is the best way to handle things after all, since I believe that ensures that the correct rounding mode would get used. > > 3. Clearly, PI should be the closest representable value to the true > > mathematical pi. In other words, the maximum error magnitude should be > > ulp/2. Note that assuming std::atan(PI) > 0 is a bug, just as assuming > > std::sqrt(3)*std::sqrt(3) == 3 is a bug. Floating-point is inherently > > inaccurate, you can't get around it. > > [note my error - atan(pi/2) = infinity. atan(pi) = 0] Actually, aren't we really talking about tan(pi/2)? The atan function has no poles... > The problem here is that the mathematical atan() function has a pole at > (n+0.5)*pi, where n is any integer. Yes, I understand the issue very well. > Choosing the "wrong" value for PI can > cause a different branch of the std::atan() function to be taken, giving > wildly different solutions to the identical problem on different > environments or even in the same environment using different precisions. It > would perhaps be better for numerical stability and portability to provide > that PI be the largest representable value less than pi. This would ensure > that any arguments to std::atan() in the range [-PI,PI] would always give > results in the principal branch of the function, which is similar to the > guarantee given by the mathematical definition. Actually, we're talking about the range [-PI/2,PI/2], right? So even if you have a value of PI that is strictly less than the true pi, you can't guarantee that PI/2 is strictly less than the true pi/2, unless you can control rounding modes. I still claim this is just another example where you have to be careful about floating-point inaccuracy. It's a mistake to assume that you can represent pi exactly. It's a mistake to assume that you can represent pi/2 exactly. This is far from the only case where tiny changes in input can potentially lead to huge changes in output. -- Eric Backus --- [ 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.jamesd.demon.co.uk/csc/faq.html ]