From 7680108277477303352 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: pbristow@hetp.u-net.com ("Paul A Bristow") Newsgroups: comp.std.c++ Subject: Re: Pi, Euler Number, and perhaps other 'natural' constants? Date: Fri, 6 Aug 2004 15:22:43 GMT Organization: (Posted via) VIA Net.Works UK Ltd. Lines: 77 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <5cydnSisJNo4yJncRVn-sQ@speakeasy.net> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1091805767 8314 158.152.254.254 (6 Aug 2004 15:22:47 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 6 Aug 2004 15:22:47 +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=-4.2 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 i76FMhUd017950; Sat, 7 Aug 2004 01:22:43 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Fri, 06 Aug 2004 12:45:26 BST 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++:1563 "Alberto Barbati" wrote in message news:P1JNc.15868$1V3.392640@twister2.libero.it... > John Nagle wrote: > > Daniel Pfeffer wrote: > > > > We should have "std::pi" as a double, accurate to the last bit > > of a double, even if it has to be calculated offline and > > stored as a hex float. This is worth doing, because it's > > a huge pain to do that and it only needs to be done once. > > > > Should std::pi be a constant? As my current programming platform is > ix86-based I would prefer having a function instead. > If std::pi is defined as a constant, it may > be difficult for a compiler to generate an intrinsic call to FLDPI thus producing optimized code, > while it may be easier if std::pi() is function (at least the machinery > to replace calls to sin(), cos() etc. with intrinsics is already there). This view was strongly expressed as requirement for presentation of math constants, but it was also very strongly felt that naive users should be able to write pi and get the same effect as pi(). (This is because the ()s would seriously clutter and impede reading of complex equations - the main users of math constants). This requirement has been the stumbling block. http://lists.boost.org/MailArchives/boost/msg48217.php Is the starting point for a recent Boost review which did NOT reach a satisfactory outcome. http://www.hetp.u-net.com/public/Math_Constants_doc_3.zip http://www.hetp.u-net.com/public/Math_constants3.zip contain the submission and discussion of the surprisingly complex issues involved here. Meanwhile, you may find this collection of C Macro math constant values a convenient source for values accurate enough for up to 128-bit floating point http://hetp.u-net.com/public/Cpp/math_constants.h In my view we need ALL the constants listed (collected from various sources to avoid using the compiler to calculate - these are done with 200 decimal digits program NTL by Victor Shoup). Paul PS A few tests also revealed that the best compiler - you can guess - could generate what looked like optimum code from plain builtin floating-point types (but could not substitute some fancy hardware value - of which there are very few, pi e ..). And you need an externally accurately calculated value for pi/6, say, (only pi/2 pi/4 2 * pi etc can be exactly calculated from pi). So the case for the function is not as strong as you might imagine at first, except that it helps with user defined types, an important requirement: intervals and higher than hardware accuracy are the most obvious, but types which contain info about the 'quality' of the value are also potentially very useful. Paul A Bristow Prizet Farmhouse, Kendal LA8 8AB UK pbristow@hetp.u-net.com --- [ 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 ]