Re: [boost] Math constants - Some suggested constants

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-11-07 09:27:48

From: "Kevin Lynch" <krlynch_at_[hidden]>
> 
> > 1. Many constants are the return values of functions taking a certain parameter.  In a 
> > perfect world, these wouldn't be constants at all, but would simply be written sqrt(2) or
> > gamma(1/3.), or the like.  
> 
> > 2. To keep at least some uniformity, for each constant that is a function return value, 
> > the actual function should be available.  Sqrt and cos are done for us.  But gamma 
> > constants should not be added without a gamma function.
> 
> > 3. Given the above observations, only group 1 (as I've suggested) constants should be
> > considered for standardization.  The trend should be to move the language away from 
> > performance hints to compilers (e.g. inline), rather than toward it.  Intrinsicly 
> > performing high-quality compile-time sqare root should become a QoI issue for compilers 
> > that users can count on, just like what is possible today for operator*(double,double).  
> 
> I read your post with great interest, and agreed in principle with much
> of it... however  (going out of order....  :-)
> 
> There are a number of issues here that are thorny and subtle, I think,
> that need to be considered.  While I agree with you that in a perfect
> world the math functions would provide some sort of guarantees on their
> precision, such guarantees are difficult in general to obtain, since
> different algorithms generate different precision/run time tradesoffs,
> perhaps even for different ranges of the arguments (eg. algorithm A may
> be much faster near 1 than near 2 for equally good precision, while B
> may provide equal speed everywhere but be much more accurate near 1 than
> near 2).  It is often the case that you trade off substantial run time
> for moderate precision gains and I don't think that the standard should
> be mandating precision or run time guarantees in that light.  It would
> be much better, in my opinion, if the standard required that
> implementations document the precision/run time parameters of their math
> functions in some detail; many standard library implementations are hard
> to use in high performance computing because just such information is
> missing in the library documentation  (if you don't understand the
> library, and a 5% performance penalty is going to cost you two weeks of
> runtime, you're going to end up paying big bucks for specialized
> libraries that give you the information you need, and many of us can't
> afford that sort of expense)

These are good observations.  The details about how much precision to expect and/or require from a compiler goes beyond what I know enough to wade into.  It would be great to see compilers ship with arbitrary precision engines for their compile-time calculations, but I don't know whether such is practical.

What is constant versus run-time is easier to specify, however.  See below.
 
> However, if you are only talking about compile time translation of
> functions taking literal arguments, that may be a different story; it
> might not be unreasonable to expect compilers (some day) to generate
> precise values for expressions that are compile time calculable;
> sqrt(2.) is an excellent example, but what about sqrt(5./13.)?  What
> about sqrt(3./2.)?
> Since sqrt(3./2.) = sqrt(3.)/sqrt(2.), should we expect such
> simplifications?  How far should the standard go?   I like the idea in
> concept, but I don't know how far we can expect compiler writers to go
> in this direction (Even though I'd like to see them go as far as
> possible!  but then again, I'm no compiler writer  :-)  ; after all,
> providing much of this optimization would require them to implement
> computer algebra systems in their optimizers, and I don't know if
> they'll want to be doing that...

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.  To get the same expectation of intrinsic support for sqrt, all that needs to be done is to classify its output as a constant, so long as its input is a constant.  Thus, the following would also become legal:

int a[int(std::sqrt(2.))];

Once that is required, it will be reasonable to assume compile-time computation of a sqrt function taking any constant parameter.  So tricks like knowing that sqrt(3./2.) = sqrt(3.)/sqrt(2.) will not be needed.  The compiler will evaluate 3./2. and then apply sqrt to that result, analogous to how the compiler evaluates 1. / (3./2.).

> The other issue I thought of relates to your classification of
> constants:  pi versus sqrt(2.), for example.  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.  The problem only gets
> worse as we consider more constants, and I'm not sure if there might be
> a better definition of the separation.  I agree, however, that there is
> in principle little "need" to standardize those constants that are a
> simple sequence of +-/* away from other constants  (if pi/2 loses
> substantial precision, then your platform is really broken, and this
> library isn't going to help you anyway).

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.

> Finally, I disagree that only those constants which are function return
> values for which the actual function is available should be considered
> (eg. sqrt(2) would be in, but not gamma(1./3.))  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.