Re: [boost] Math constants - Some suggested constants

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-11-07 12:27:22

Ed Brey wrote:
> 
> From: "Kevin Lynch" <krlynch_at_[hidden]>
> >
> 

> Currently C++ requires compilers to perform compile-time evaluation of certain operations. 
> For example, the following are legal C++ statements:
> int a[3 / 2];
> int a[int(3./2.)];
> 
> Given that a compiler must support such evaluation at compile-time anyway, it is 
> reasonable to expect that a compiler will generate code that reflects compile-time 
> computation if such expressions are used in a calculation.  
[examples snipped]

I had completely forgotten about that, and if the standard could require
compile time optimizations for compile-time constant functions calls, or
even just included language that such optimizations were blessed, if not
required, I'd be a really happy camper.  I'd be even happier if the
standard required such compile-time optimizations to produce results
with precision comparable to return type (i.e. sqrt(2.) would be compile
time evaluated to the precision of a double).  I guess that the current
standard doesn't forbid such an optimization, but I don't know of any
generally available compiler that does such an optimization; language in
the standard advocating such optimization would pretty much eliminate
the need for many of the constants that have been discussed here, and
which are currently (unfortunately) necessary.

> > You stated that you'd like
> > to see the library, if possible, maintain a "function call interface" to
> > those things that look like function calls, and provide only those
> > "constants" that are most "natural as constants".  The problem I see is
> > that this isn't as clear a distinction as you might like:  pi = cos(-1),
> > e = exp(1), i = sqrt(-1), (ok, pi may not pass your "naturalness"
> > criterion, but exp(1) certainly should) etc.  
> 
> There definately is room for prespective here.  I don't have a strong enough mathematical
> background to know if there is a "true" perspective.  Personally, I see pi as fundimental, 
> and cos(-1) == pi as a concidence, and e as fundimental, and exp(1) as a shortcut for 
> pow(e,1).  However, I can't provide any evidence as to why this perspective is better than 
> another one; it's just based on what I've been exposed to going through school.

I certainly agree that there probably isn't a "true" perspective, just
that if there is going to be a classification, one has to be careful as
to how it is formally defined; I didn't mean to suggest that just
because pi and e can be derived from a function call interface that they
SHOULD be... in the sense that you described (exposure at school) and
from a convenience perspective, they almost certainly SHOULD be in a
"constants library", even if the library can provide them with arbitrary
precision by way of function call.  They are just too convenient to be
left out.

> > Consider that many of
> > the functions that are "missing" will likely be in the TR, since it will
> > likely suck in the C99 library (cbrt, tgamma, erf, etc. will all be
> > coming in....).
> 
> Please help me understand what's going on in C99 here.   Are you saying that it will be 
> providing _functions_, like cbrt(double), eft(double), etc.  If so, then this is great: 
> these functions will be available for C++ for generic operation.  And if a need is shown, 
> some precomupted results can be made available too (e.g. cbrt_2).  What I don't want to 
> see is the inclusion of cbrt_2 without a cbrt function.  And of course, I'd prefer even 
> more not have cbrt_2 at all, but only if its exclusion is practical.

C99 added the following very useful functions (among a large number of
additions which are nice, but less useful, IMHO) to math.h:

Inverse hyperbolics:  acosh, asinh, atanh, 
Base 2 functions:  exp2, log2
exponential functions for small arguments: expm1, log1p, 
cube root:  cbrt, 
hypotenuse: hypot, 
error functions:  erf, erfc, 
gamma functions:  lgamma (log gamma), tgamma (I don't understand the t
and ignore it  :-)

There are others I'd love to see that still aren't there, but at least
these are in C now, and will likely come into C++ with teh TR.

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------