From -1523395324250289291 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!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: kuyper@wizard.net (James Kuyper) Newsgroups: comp.std.c++ Subject: Re: Pi, Euler Number, and perhaps other 'natural' constants? Date: Sun, 1 Aug 2004 22:01:39 GMT Organization: http://groups.google.com Lines: 44 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <8b42afac.0408010207.722b94bd@posting.google.com> References: <5cydnSisJNo4yJncRVn-sQ@speakeasy.net> <1090949817.234275@cswreg.cos.agilent.com> NNTP-Posting-Host: news.news.demon.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.demon.co.uk 1091397707 4825 158.152.254.254 (1 Aug 2004 22:01:47 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 1 Aug 2004 22:01:47 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) 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.7 required=5.2 tests=AWL,BAYES_00 autolearn=ham version=2.60-mulga_r1 X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i71M1dwJ020797; Mon, 2 Aug 2004 08:01:39 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Sun, 1 Aug 2004 10:07:49 +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-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1513 pfefferd@hotmail.co.il.nospam ("Daniel Pfeffer") wrote in message news:... .. > 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. Hopefully, that change would also be accompanied by incorporating C99's hexadecimal floating point literals. That way, at least on machines where FLT_RADIX is a power of 2, it will be possible to specify a floating point literal that has an exact representation, and is therefore unaffected by rounding direction. > 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 That isn't a good reason for rejecting the value as "wrong". Any value you choose to represent PI will necessarily give problems of that kind for certain angles. Choosing the most accurate representation of PI possible for a given floating point format is always the choice that, overall, minimizes such inaccuracies; no choice available to us can prevent them. > 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. It's inappropriate to try to match the mathematical definition in that fashion. The best anyone should hope for in this context is to have that gurantee apply for the range (-PI,PI), not [-PI,PI]. If they're expecting something else, they don't understand the problems of computer floating point representations well enough to get good results anyway. --- [ 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 ]