Boost logo

Boost :

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:	 (617) 353-6065
Physics Department			Fax: (617) 353-6062
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA

Boost list run by bdawes at, gregod at, cpdaniel at, john at