
Boost : 
From: Paul A. Bristow (boost_at_[hidden])
Date: 20010911 13:14:02
I have a specific example for your consideration and suggestions
on how this might be 'interfaced'.
Attached is a tranlsation of ACM TOMS 715.f ANORM into C++.
It does the normal distribution function.
(NOT yet Boostified before anyone comments!)
(prob.cpp is the function, prob.h just declares it, test.cpp
and its results in a .txt file (also pasted into the prob.cpp
at the end)
(It might be improved but it works).
Perhaps you would like to comment on how your interface proposals
might impact on this example. Perhaps this si simple example,
but many are similarly simple.
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 machinedependent constants. Let
C
C XMIN = the smallest positive floatingpoint number.
C
C Then the following machinedependent 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) * (11/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)].
C
C Approximate values for some important machines are:
C
C XMIN EPS XLOW XUPPR
C
C CDC 7600 (S.P.) 3.13E294 7.11E15 36.641 8.072
C CRAY1 (S.P.) 4.58E246 7.11E157 106.521 26.816
C IEEE (IBM/XT,
C SUN, etc.) (S.P.) 1.18E38 5.96E8 12.949 5.768
C IEEE (IBM/XT,
C SUN, etc.) (D.P.) 2.23D308 1.11D16 37.519 8.572 IEEE
Floating point
C IBM 195 (D.P.) 5.40D79 1.39D17 18.781 8.811
C VAX DFormat (D.P.) 2.94D39 1.39D17 13.055 8.811
C VAX GFormat (D.P.) 5.56D309 1.11D16 37.556 8.572
I see no reason why an exception should be raised if the argument falls
outside the values, as the value 0 or 1 should be returned.
Cody says:
C Error returns
C The program returns ANORM = 0 for ARG .LE. XLOW.
but I don't see (as a mad scientist and not a mad mathematican)
why this is an error or needs flagging, except that the result
might be denormalised (see the final line of the procedure which ensures
that it isn't).
(Is this right thing to do?)
Comments from anyone, but especially Eric please.
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: Monday, September 10, 2001 2:22 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Math Functions
>
>
> > So I am as yet unconvinced at the importance of the the 'interface'
> > beyond defining things as, for example,
> >
> > double function(double);
> >
> > The algorithms are the hard bit, I believe.
>
> Obviously, algorithms are important and a whole field of study in
> their own right. Let's not argue about which is more important. I
> beleive there already exist a number of algorithms, libraries, and
> numerical packages, but I often find it difficult to combine them in
> the ways necessary for my science.
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk