
Boost : 
From: Kevin Lynch (krlynch_at_[hidden])
Date: 20011107 12:27:22
Ed Brey wrote:
>
> From: "Kevin Lynch" <krlynch_at_[hidden]>
> >
>
> Currently C++ requires compilers to perform compiletime 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 compiletime anyway, it is
> reasonable to expect that a compiler will generate code that reflects compiletime
> 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 compiletime 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 compiletime 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: (617) 3536065 Physics Department Fax: (617) 3536062 Boston University office: PRB565 590 Commonwealth Ave. email: krlynch_at_[hidden] Boston, MA 02215 USA http://physics.bu.edu/~krlynch 
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk