RE: [boost] Re: Math Functions & Build system

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-10-08 13:27:56

Glad to see so much Math Function work going on while I was on holiday!

I agree that Xmin and EPS only require std limits.

I believe that XLOW and XUPPR and many other similar values
are needed for some algorithms, but a large number of systems
are IEEE FP compliant and so that suitable values are known.

We can use std::numeric_limits is_iec559 to test if these
should be used, othewise we could leave users to provide their own
values.

I believe some values may be compiler calculated using other 
std::numeric_limits like min and max expoment and radix etc).

So the fairly complex solutions discussed may not be needed.

Paul

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
Mobile [phone]
mailto:pbristow_at_[hidden]
 

> -----Original Message-----
> From: Eric Ford [mailto:eford_at_[hidden]]
> Sent: Saturday, September 29, 2001 10:00 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Math Functions & Build system
> 
> 
> > 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
> 
> 
> 
> 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/