Paul A Bristow wrote:

>
> "Alberto Barbati" <AlbertoBarbati@libero.it> 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.

Supporting `const float pi = std::pi()' Would seem a reasonable first step.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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                       ]

"Alberto Barbati" <AlbertoBarbati@libero.it> 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                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:mrvNc.3129$AY5.1919@newssvr21.news.prodigy.com...
> Daniel Pfeffer wrote:
> > "Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
> > news:5cydnSisJNo4yJncRVn-sQ@speakeasy.net...
>
> > For serious numerical work, the required machine representation
> > of PI must be determined for each floating-point
> > implementation.
>
>     That's a bit much.  It's not like the value of "pi" is a
> matter of either opinion or measurement.

The _mathematical_ value of pi is known to a very high accuracy. The
_machine_ representation of PI depends on the size of the mantissa, the
rounding mode, etc. Even in a single environment, the value of PI can change
because of a difference in the rounding mode of the environment (e.g. round
towards negative infinity will always give a result that differs from round
round towards positive infinity).

These rounding mode differences are not unimportant. For example, correct
interval arithmetic relies on the presence of both of the above rounding
modes.

I am aware that the FP rounding mode is defined in std::numeric_limits<>,
and that it is currently constant for each FP type. However, if the C99
<fenv.h> mechanisms are incorporated into C++0x, this will have to change.


>     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.

See above. The actual value may change (by 1 ulp), depending on the
environment's current rounding mode.


>     I'd provide "pi" and "e", but stop there.  For one thing,
> the trig functions themselves need those constants, so
> they're already in the library somewhere.

Agreed.


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                       ]

""Eric Backus"" <eric_backus@alum.mit.edu> wrote in message
news:1090949817.234275@cswreg.cos.agilent.com...
> ""Daniel Pfeffer"" <pfefferd@hotmail.co.il.nospam> wrote in message
> news:ce5ais$f50$1@news.inter.net.il...
> > "Steven T. Hatton" <hattons@globalsymmetry.com> 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 <fenv.h> 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                       ]

Alberto Barbati wrote:
> 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. That's because
> there is a FPU instruction ...

    This is an argument for 80-bit floating point support in C++.
What's the thinking on that?  Most FPUs in the world today
have support for it.

    John Nagle

---
[ 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                       ]

John Nagle wrote:
> Alberto Barbati wrote:
>
>> 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. That's because
>> there is a FPU instruction ...
>
>
>    This is an argument for 80-bit floating point support in C++.
> What's the thinking on that?  Most FPUs in the world today
> have support for it.
>

C++ already "supports" 80-bit FP in the sense that he size of the
floating point type is implementation-defined. See 3.9.1/8.

Therefore if you don't have 80-bit support, it's a problem of your
implementation, not of the language.

Alberto

PS: if you refer to ix86, I agree that it's a pity that the one of the
most popular C++ implementations on that platform provide both double
and long double as 64-bit types, while the FPU supports 80-bits.

---
[ 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                       ]

""Daniel Pfeffer"" <pfefferd@hotmail.co.il.nospam> wrote in message
news:ce88dn$bvl$1@news.inter.net.il...
> ""Eric Backus"" <eric_backus@alum.mit.edu> 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 <fenv.h> 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                       ]

Eric Backus wrote:


> Actually, we're talking about the range [-PI/2,PI/2], right?  So even i=
f 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.

Or unless you also have a PI_DIVIDED_BY_2 constant ?

But then you might have PI_DIVIDED_BY_2 !=3D PI/2, and I'm not sure this=20
is a move in the right direction.

--=20
Lo=EFc

---
[ 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                       ]

pfefferd@hotmail.co.il.nospam ("Daniel Pfeffer") wrote in message news:<ce86oh$biu$1@news.inter.net.il>...
..
> The _mathematical_ value of pi is known to a very high accuracy. The
> _machine_ representation of PI depends on the size of the mantissa, the
> rounding mode, etc. Even in a single environment, the value of PI can change
> because of a difference in the rounding mode of the environment (e.g. round
> towards negative infinity will always give a result that differs from round
> round towards positive infinity).
>
> These rounding mode differences are not unimportant. For example, correct
> interval arithmetic relies on the presence of both of the above rounding
> modes.
>
> I am aware that the FP rounding mode is defined in std::numeric_limits<>,
> and that it is currently constant for each FP type. However, if the C99
> <fenv.h> mechanisms are incorporated into C++0x, this will have to change.

If C99's hexadecimal constants  are also incorporated, it will be
possible to define PI in a way that doesn't get rounded, at least for
machines where FLT_RADIX is a power of 2.

>>    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.
>
>
>
> See above. The actual value may change (by 1 ulp), depending on the
> environment's current rounding mode.

Not if stored as a hex float, at least if FLT_RADIX is a power of 2.

---
[ 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                       ]

pfefferd@hotmail.co.il.nospam ("Daniel Pfeffer") wrote in message news:<ce88dn$bvl$1@news.inter.net.il>...
..
> Not necessarily. What happens when the C99 <fenv.h> 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                       ]

The need for an optmisable method of presentation was a major issue in the
Boost groups attempts, but it was not possible to find a fully portable
solution and we are waiting for typeof and better compilers to solve this.

To ensure that the constant is stored correctly, it is necessary to provide
an exactlyrepresentable decimal digit string (which is twice the number of
binary bits in the significand).  This overcomes the need to have fp hex
values (and a language change).

In my view, very many constants would be useful and aid program portability.




Paul


"Alberto Barbati" <AlbertoBarbati@libero.it> 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. That's because
> there is a FPU instruction (namely FLDPI) that loads the value of pi in
> an FPU register. Calling FLDPI has a few advantages over a "regular" FLD
> load instruction, mostly the fact that there the value need not be read
> from memory and that the value is loaded at full internal precision
> (ix86 FPU registers internally have more precision than a double).
>
> 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).
>
> Just my opinion,
>
> Alberto
>
> ---
> [ 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                       ]
>

---
[ 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                       ]

I was a bit surprised that the Standard does not specify that the constant
Pi be part of an implementation. It seems like an obvious feature to want
in a programming language. The Euler Number would also be nice, but not
nearly as desirable as Pi.  Sure there are questions of how to handle the
difference between a float and a double Pi, but I'm (almost) sure that
isn't a big obstacle.

I've found ways to jump though hoops to get Pi defined by using
transcendental functions provided in the Standard Library, but that seems a
bit convoluted to me.  Is there a reason Pi is missing from C++?
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ 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                       ]

"Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
news:5cydnSisJNo4yJncRVn-sQ@speakeasy.net...
> I was a bit surprised that the Standard does not specify that the constant
> Pi be part of an implementation. It seems like an obvious feature to want
> in a programming language. The Euler Number would also be nice, but not
> nearly as desirable as Pi.  Sure there are questions of how to handle the
> difference between a float and a double Pi, but I'm (almost) sure that
> isn't a big obstacle.
>
> I've found ways to jump though hoops to get Pi defined by using
> transcendental functions provided in the Standard Library, but that seems
a
> bit convoluted to me.  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.

All in all, I believe that it is better to let each application determine
the answers to these questions. For serious numerical work, the required
machine representation of PI must be determined for each floating-point
implementation. For most engineering and many scientific uses, calculation
of PI to 12 digits (or less, in many cases) would be more than sufficient.
For the rest of us, 355/113 or even 22/7 are probably accurate enough. :-)

As you have discovered, a good way to calculate PI at close to machine
precision is to define functions as follows:

inline float PI_f() { return 4.0f*std::atan(1.0f); }
inline float PI() { return 4.0*std::atan(1.0); }
inline float PI_l() { return 4.0l*std::atan(1.0l); }


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                       ]

""Daniel Pfeffer"" <pfefferd@hotmail.co.il.nospam> wrote in message
news:ce5ais$f50$1@news.inter.net.il...
> "Steven T. Hatton" <hattons@globalsymmetry.com> 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.

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.

On some architectures, M_PI, defined in <math.h>, will give you the double
version of PI.  A few architectures also provide M_PIl, a long double
version of PI.

I suspect that the real reasons it's not standardized are:
1. The only existing practice (M_PI) uses #define, which C++ doesn't want to
standardize.
2. There are potentially very many values that could be standardized.  Where
do you stop?

These reasons do seem a little weak, but I can't think of any other
explanations

--
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                       ]

Daniel Pfeffer wrote:
> "Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
> news:5cydnSisJNo4yJncRVn-sQ@speakeasy.net...

> For serious numerical work, the required machine representation
> of PI must be determined for each floating-point
> implementation.

    That's a bit much.  It's not like the value of "pi" is a
matter of either opinion or measurement.

    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.

    I'd provide "pi" and "e", but stop there.  For one thing,
the trig functions themselves need those constants, so
they're already in the library somewhere.

    John Nagle
    Animats

---
[ 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                       ]

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. That's because
there is a FPU instruction (namely FLDPI) that loads the value of pi in
an FPU register. Calling FLDPI has a few advantages over a "regular" FLD
load instruction, mostly the fact that there the value need not be read
from memory and that the value is loaded at full internal precision
(ix86 FPU registers internally have more precision than a double).

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).

Just my opinion,

Alberto

---
[ 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                       ]

"Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message news:<5cydnSisJNo4yJncRVn-sQ@speakeasy.net>...
> I was a bit surprised that the Standard does not specify that the constant
> Pi be part of an implementation. It seems like an obvious feature to want
> in a programming language. The Euler Number would also be nice, but not
> nearly as desirable as Pi.  Sure there are questions of how to handle the
> difference between a float and a double Pi, but I'm (almost) sure that
> isn't a big obstacle.
>
> I've found ways to jump though hoops to get Pi defined by using
> transcendental functions provided in the Standard Library, but that seems a
> bit convoluted to me.  Is there a reason Pi is missing from C++?

As others have pointed out, it's got an imprecise value, etc.
However, as I remember Paul Bristow is working on adding something to boost.

Best,
John


John Torjo
Freelancer
-- john@torjo.com

Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/

Professional Logging Solution for FREE
-- http://www.torjo.com/code/logging.zip (logging           - C++)
-- http://www.torjo.com/logview/         (viewing/filtering - Win32)
-- http://www.torjo.com/logbreak/        (debugging         - Win32)
                                         (source code available)

---
[ 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                       ]

A function getpi() might be better than a double, since
some architectures have an instruction for loading the Pi
value (i.e. FLDPI on IA32).

Both a double and getpi() are not constant expressions though.
To do that, we need the preprocessor.

---
[ 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                       ]

There have been several attempts on the Boost group to provide a lot of math
constants, but the matter has not received a satisfactory conclusion yet.

The difficulty is not the values, but the problem is providing these in a
C++ tempalted format that allows extension to user defined types (especially
higher than hardware and arbitrary precision arithmetic).

Various attempts have floundered as being not portable - typeof seems to be
needed.

Paul


--
Paul A Bristow
Prizet Farmhouse, Kendal LA8 8AB   UK

"Steven T. Hatton" <hattons@globalsymmetry.com> wrote in message
news:5cydnSisJNo4yJncRVn-sQ@speakeasy.net...
> I was a bit surprised that the Standard does not specify that the constant
> Pi be part of an implementation. It seems like an obvious feature to want
> in a programming language. The Euler Number would also be nice, but not
> nearly as desirable as Pi.  Sure there are questions of how to handle the
> difference between a float and a double Pi, but I'm (almost) sure that
> isn't a big obstacle.
>
> I've found ways to jump though hoops to get Pi defined by using
> transcendental functions provided in the Standard Library, but that seems
a
> bit convoluted to me.  Is there a reason Pi is missing from C++?
> --
> STH
> http://www.kdevelop.org
> http://www.suse.com
> http://www.mozilla.org
>
> ---
> [ 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                       ]
>

---
[ 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                       ]