RE: [boost] Math constants - Some suggested constants

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-11-08 05:21:43

Sadly, in order to get the precision offered by the constants
I have proposed, compiler writer are going to have to use
some similar high precision floating-point software .
(Even Intel IA-64 is not going to have the hardware to do it yet).

High precision floating-point software is quite widely available,
but making compilers use it sounds a major task,
and would have a sigificantly reduce compile speed, 
so it is unlikely to be a priority.

(Nor should we be making this a priority for compiler writers -
 we have yet to get any compiler to meet the standard!)

Meanwhile, I suggest we get our feet back on the ground.
The proposed constants will never become wrong,
though they may become unfashionable when
compilers can do the optimisations you suggest.

But many people need accurate constants NOW.

Paul

> -----Original Message-----
> From: krlynch_at_[hidden] [mailto:krlynch_at_[hidden]]On Behalf Of
> Kevin Lynch
> Sent: Wednesday, November 07, 2001 5:27 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math constants - Some suggested constants
> 
> 
> 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
> ------------------------------------------------------------------
> -------------
> 
> Info: http://www.boost.org  Unsubscribe: 
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/