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
+44 1539 561830
Mobile +44 7714 33 02 04
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/