
Boost : 
From: Paul A. Bristow (boost_at_[hidden])
Date: 20011014 15:35:14
Original Message
From: Paul A. Bristow [mailto:pbristow_at_[hidden]]
Sent: Friday, October 12, 2001 4:28 PM
To: boost_at_[hidden]
Subject: RE: [boost] Math constants for naive and gurus?
Prompted by Eric Ford's madMacroist implementation of
Michael Kenniston's highly ingenious proposal,
I have returned from holidays and other work and tried it out.
I am still concerned that it all fails the KISS principle,
(so I still propose to produce files containing long double values as well
 I still believe that the main use will be to cut and paste!)
but I have to admit that Michael's scheme seems to meet the twin
requirements of mere (mad?) scientists being able to write area = pi * r *
r;
and yet provide a templated function pi()
for potential optimisation by (mad?) mathematicians.
I have not used Eric's macros because the .hpp files will of course
be generated using Victor Shoup's extended precision system NTL,
and I will make the program actually write the C++ code as
well as the values. (and because MACROs obscure the principles behind).
(I have also not shown any physical (variable?) constants because I feel
these
should be kept separate, but Eric has shown how to do it.
Physical constants do raise namespaces questions:
If we have a namespace math, then physical constants don't belong there.
Perhaps they belong in a units /SI namespace?)
An example of my understanding of this proposal are attached.
constants.hpp contains a few constants and test_constants.cpp does a demo.
It would be useful to know if this works on other systems than MSVC6SP5?
I am also giving some thoughts to subdivision of constants into perhaps
three .hpp files as suggested:
#include "boost/math/constants.hpp" // common  see below.
#include "boost/math/constants2.hpp" // less common
#include "boost/math/constants3.hpp" // obscure
Any views on better file names?
For the 1st file I propose:
const long double sqrt2 = 1.4142135623730950488016887242096980785697L;
// sqrt 2
const long double cube_root2 =
1.2599210498948731647672106072782283505703L; // cubert 2
const long double fourth_root2 =
1.1892071150027210667174999705604759152930L; // 4 rt 2
const long double ln2 = 0.6931471805599453094172321214581765680755L;
// ln 2
const long double ln10 =
2.3025850929940456840179914546843642076011L; // ln 10
const long double one_div_ln2 =
1.4426950408889634073599246810018921374266L; // 1 / ln 2
const long double one_div_ln10 =
0.4342944819032518276511289189166050822944L; // 1 / ln 10
const long double pi =
3.1415926535897932384626433832795028841972L; // pi
const long double two_pi
const long double degree =
0.0174532925199432957692369076848861271344L; // pi/180 degree
const long double one_div_pi =
0.3183098861837906715377675267450287240689L; // 1/pi
const long double pi_sqr =
9.8696044010893586188344909998761511353137L; // pi^2
const long double sqrt_pi =
1.7724538509055160272981674833411451827975L; // sqrt(pi) == gamma(1/2)
const long double one_div_sqrt_two_pi = (0.39894228040143267794;
const long double ln_pi =
1.1447298858494001741434273513530587116473L; // ln pi
const long double e =
2.7182818284590452353602874713526624977572L; // e
const long double one_div_e =
0.3678794411714423215955237701614608674458L; // 1/e
const long double e_sqr =
7.3890560989306502272304274605750078131803L; // e^2
const long double euler =
0.5772156649015328606065120900824024310422L; // euler
const long double phi =
1.6180339887498948482045868343656381177203L; // phi
const long double sin_one =
0.8414709848078965066525023216302989996226L; // sin(1)
const long double cos_one =
0.5403023058681397174009366074429766037323L; // cos(1)
const long double ln_phi =
0.4812118250596034474977589134243684231352L; // ln phi
const long double one_div_ln_phi =
2.0780869212350275376013226061177957677422L; // 1/ln(phi)
const long double one_div_sqrt_two_pi = 0.39894228040143267794L;
const int zer = 0;
const int one = 1;
const int two = 2;
const int ten = 10;
Other values considered essential?
Values considered too obscure?
Do the names meet Boost 'guidelines'? (Not my preference but there you
go...)
I will consider the (many) other values when there is agreement about these.
Paul
Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB UK
+44 1539 561830
Mobile +44 7714 33 02 04
mailto:pbristow_at_[hidden]
> Original Message
> From: Michael Kenniston [mailto:Msk_at_[hidden]]
> Sent: Thursday, July 19, 2001 2:17 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Math constants? [was: Static data vs. inline
> functions]
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk