From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-05-17 12:13:38
1 Since the cost of including C macros version is so small,
I feel it is work including it. Many who use C++ also
use C. C++ version(s) are most important, of course.
2 Experiments show that precision gains are from zero,
usually a least significant bit or two, but for functions
like sqrt, sin, atan, and most of all pow, up the about 32 bits.
I feel this is worth having with the convenience of NOT defining
and entering constants. And portability is very likely to be better.
Dr Paul A Bristow, hetp Chromatography
LA8 8AB UK
+44 1539 561830
> -----Original Message-----
> From: Ed Brey [mailto:brey_at_[hidden]]
> Sent: Monday, May 14, 2001 7:35 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math Constants Library formal review results
> From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
> > If the macros are being used on an implementation-level, that is fine
> > with me. I doubt that "C" people will download boost, though, because
> > it is announced as a "collection of C++ libraries". Thus, we may miss
> > this user group entirely.
> I tend to agree. It would seem to me that a generated C header file,
> while useful, should really be submitted to some organization besides
> boost. However, others have argued for inclusion in boost. I'd like to
> hear the rational from those people as to why having a consilidated
> C/C++ math library outweighs the cleanliness of having the library
> content match its housing organization. The argument I'd be interested
> in seeing refuted is this: We could include other languages besides C
> and C++. Clearly, no one thinks that would be the right approach. So
> then, why C, just because it's a closer relative?
> > Derived constants are required for optimal precision, because (e.g.)
> > pi/3 potentially has less than "double" precision when evaluated.
> I still don't have a good handle on home much precision is gained by
> writing out the literal versus having the compiler compute it at
> compile-time? That gain needs to be traded off against the cluttering
> of the interface. And then even if there is a gain, what is its value
> if you only get it for the derived constants that happen to be built in
> to the library? This reminds me of the problem with using tailored
> (hand-crafted binary) constants. Somewhere along the way, the user is
> likely to need a constants that isn't provided, and if he really needs
> that kind of precision, he's going to have to writing in precalculated
> values anyway. At that point, he's only about as well off as if he
> entered all the constants himself in the first place.
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk