From 263989273671361734 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!proxad.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: pfefferd@hotmail.co.il.nospam ("Daniel Pfeffer") Newsgroups: comp.std.c++ Subject: Re: Pi, Euler Number, and perhaps other 'natural' constants? Date: Thu, 29 Jul 2004 04:49:23 GMT Organization: INTERNET-ZAHAV Lines: 78 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <5cydnSisJNo4yJncRVn-sQ@speakeasy.net> <1090949817.234275@cswreg.cos.agilent.com> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1091076566 26009 158.152.254.254 (29 Jul 2004 04:49:26 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 29 Jul 2004 04:49:26 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Priority: 3 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.6 required=5.2 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60-mulga_r1 X-MSMail-Priority: Normal X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i6T4nNMN029135; Thu, 29 Jul 2004 14:49:23 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Wed, 28 Jul 2004 13:07:04 +0000 (UTC) X-Spam-Level: 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.1437 X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1481 ""Eric Backus"" wrote in message news:1090949817.234275@cswreg.cos.agilent.com... > ""Daniel Pfeffer"" wrote in message > news:ce5ais$f50$1@news.inter.net.il... > > "Steven T. Hatton" wrote in message > > news:5cydnSisJNo4yJncRVn-sQ@speakeasy.net... > > > Is there a reason Pi is missing from C++? > > > > While I cannot speak for the Standards committee, a few reasons occur to > me: > > > > Given > > pi - the mathematical infinitely precise value > > PI - the limited machine representation > > ulp - unit in last position - the smallest difference between adjacent > > floating point numbers > > > > 1. Should PI be provided for every supported floating-point format? > > 2. To what precision should PI be provided? > > 3. How should PI be rounded? note that std::atan(pi-ulp) is a large > positive > > number, while std::atan(pi+ulp) would be a (different) large negative > > number. The second choice may cause problems if atan(pi) is assumed to be > > positive. > > 1. Clearly, PI should be provided for every supported floating-point > format--there are only three formats after all. But assuming you provide a > long double PI, you can always just use "(double) PI" and "(float) PI" to > get the other two. > > 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. > 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] The problem here is that the mathematical atan() function has a pole at (n+0.5)*pi, where n is any integer. 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. Issues with rounding of std::atan((n+0.5)*PI) for n <> 0 would exist even were PI allowed to be the closest representable value to pi. The only problem is that significant divergence will occur when n is smaller. Note that this problem exists only with atan(), and not with any other standard transcendental functions - the others have no poles. Daniel Pfeffer --- [ 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 ]