Re: Math Functions & Build system

From: Eric Ford (eford_at_[hidden])
Date: 2001-09-29 03:59:31

> There is no real limit on the argument provided - the
> xlow and xupper values are machine specific, but not easily
> computed.  Cody gives these examples:
> 
> C Explanation of machine-dependent constants.  Let
> C
> C   XMIN  = the smallest positive floating-point number.
> C
> C Then the following machine-dependent constants must be declared
> C   in DATA statements.  IEEE values are provided as a default.
> C
> C   EPS   = argument below which anorm(x) may be represented by
> C           0.5  and above which  x*x  will not underflow.
> C           A conservative value is the largest machine number X
> C           such that   1.0 + X = 1.0   to machine precision.
> C   XLOW  = the most negative argument for which ANORM does not
> C           vanish.  This is the negative of the solution to
> C                    W(x) * (1-1/x**2) = XMIN,
> C           where W(x) = exp(-x*x/2)/[x*sqrt(2*pi)].
> C   XUPPR = positive argument beyond which anorm = 1.0.  A
> C           conservative value is the solution to the equation
> C                    exp(-x*x/2) = EPS,
> C           i.e., XUPPR = sqrt[-2 ln(eps)].

Unfortunately,  don't think calculating all of these at compile time
is a good idea.  Constants link XMIN and EPS should be doable based on
a numeric_limits type setup.  However constants like XLOW and XUPPR
are harder to get at compile time.  I implemented a silly compile time
root finder.  Something similar could be made to work.  However, the
template recursion depth necessary was much greater than the 17
allowed by the standard.  

I haven't been paying attention to the discussions about a boost build
system for libraries requiring code not in header files.  In principle
that could generate a header file with constants such as these that
were necessary for some functions.  The only alternative I can see is
a lot of ugly #ifdef's or code that will only compile with a deplate
depth of significantly greater than 17.   Using a build system to
generate headers would be somewhat inelegant.  On the plus side, it
would introduce the least possible overhead, since the constants would
just be constants (after the first compile) and not need to be
calculated either at run time or at compile time.  However, I'm not
sure if this would be acceptable to the rest of the boost crew.  I
could understand some being very opposed to relying on machine
generated header files.  

Comments from the boost powers that be?  Is this functionality that
the boost build system could provide?  How far in the future before
such a build system is functional?  Ready to be included in the boost
distribution?  Is this something that would be tolerated?  Can someone
see another way around the problem?

Thanks,
E