Boost logo

Boost :

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-10-22 16:07:17


> -----Original Message-----
> From: Ed Brey [mailto:edbrey_at_[hidden]]
> Sent: Friday, October 19, 2001 3:15 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math constants for naive and gurus? - which
> constants do you want?
>
>
> From: "Paul A. Bristow" <boost_at_[hidden]>
> > I have now produced a C++ program which writes constants to
> several files:
> >
> > const floats, - if you only ever want floats (eg embedded systems)
> > const doubles, - many peoples only need.
> > const long doubles, - high precision people.
> > Michael Kenniston's cunning function version, - multiple fp
> precision and
> > should meet those with compiler optimisability requirements.
> >
> > and for those who are not MACRO-phobic or using C
> > C Macros, and mathcin #undefs.
>
> The current version in the vault has several files
> (float_constants.h, double_constants.h, long_constants.h) that
> each define identical names in the global namespace. This is
> certainly not acceptable for a boost library. Now, if the
> objective is just to show that the constants can be partitioned
> into multiple headers, that is fine. However, one should never
> count on the user just including only one of multiple headers,
> since any given library may include any given header in a .hpp
> file (perhaps because a constant is needed in inlined code).

I naively envisaged that only one would be #included.
Are you suggesting instead naming them piF, pi and piL?
(This could be done quite easily - but it fixes the float size in user code,
and I wonder if this is a good idea?).

> On the question of whether simple definitions like "double const
> pi = 3.14" are needed, or if the fancier definitions like in
> function_constants.hpp will suffice, I was about to say that we
> need the simple ones. The reason is that it appears that those
> in tst.cpp lead to code bloat, since I noticed that even unused
> constants ended up in the assembly listing for a test program,
> and I doubted that the linker would always be able to remove
> them, especially if creating a dynamicly linked library on
> platforms where classes are not individually targeted for export.

I have worried about this before! I still do.
>
> What didn't make sense is why the compiler would generate code
> for unused constant classes. Fortunately is that the answer is
> due to a simple (arguable) bug in the library. The constant
> class has a superfluous constructor. If you remove the
> constructor, then the compiler generates code only for what is
> used, and optimally efficient code at that. ("The compiler" here
> is VC6.) If there was ever a poster child for not littering
> classes with do-nothing constructors, this is it.

I don't understood you here.

Removing the constructor thus doesn't compile.

    namespace float_constants
    {
// constant<pi_tag, float> const pi;
    }
    namespace double_constants
    {
// constant<pi_tag, double> const pi;
    }
    namespace long_double_constants
    {
// constant<pi_tag, long double> const pi;
    }

Please explain your 'tweak'. (And does it work on other systems?)

> Given this tweak, I can't think of a need that
> function_constants.hpp does not serve, except perhaps
> operator&(). That needs seems very minor, and not worth
> expanding the other interface. The framework would be allow
> users adding their own constants. However, this is not a
> problem, since users just define their own constants using simple
> definitions, of follow the pattern in their own namespace if they
> need generic typing. Other than no operator&(), I can't think of
> any other drawback, although I must admit I wasn't following this
> thread very closely in the past, and so if I missed something,
> I'd love to be enlightened.
>
> One very nice advantage to the approach is that it leaves the
> door open for implementation-specific optimizations like
> FP-generated pi to be seemlessly integrated at any time, if they
> are deemed beneficial.
>
> Note that one possible use I am consciously not considering is
> use in C. I don't question that a math library would be useful
> for C users, but it has different requirements and constraints
> than its C++ counterpart. Also, Boost is the wrong forum for
> publishing C libraries.

I don't rule out uses for the MACRO constants
- so I have produced them en route at no extra cost.

> It seems that there is good potential for providing a simple,
> single interface to regular end users: just use
> boost::math::double_constants::pi.

Users will not take kindly (ie won't use it!!) to having to write

area = boost::math::double_constants::pi * r * r;

but writing using boost::math::double_constants;

allows

area = pi * r * r;

> I don't really have the background to know what values are
> appropriate. My only view would be to stick to primitives,
> avoiding pi/2 syndrome, since I'm afraid the pollution vs. value
> curve will likely not have a knee.

2. * pi and p /2. are special in that there is no loss of accuracy,
3/2 * pi may lose accuracy.
I hope the cost of completeness is small enough for some like this.

> I think that having the user copy and paste values is
> unacceptable except in cases where a user needs extremely high
> precision and they are pasting a value out of a book or
> generation output for a constant not provided by Boost. All
> constants provided by Boost should be placed in a single
> ready-to-go header.

Ideally I agree with this,
but it must not cost - hence the simple float, double, log files.

> Finally, the static copyright variable needs to go. Personally,
> I would like to see the generated .hpp file placed into the
> public domain. The generator, of course, would remain copyrighted.

I am happy for it all to go into the public domain with Boost's
choice of licence terms.

Paul

>
>
>
> 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/
>
>
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk