Re: [boost] Math constants for naive and gurus? - which constants do you want?

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-10-19 09:14:46

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).

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.

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, they 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.

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.

It seems that there is good potential for providing a simple, single interface to regular end users: just use boost::math::double_constants::pi.  The only options would be replacing "double" with the precision desired, and the use of using declarations or directives to avoid the need for qualifiers.

The only other part of the interface would be for advanced programmers writing generic code, where the template part of the interface would be described.

> So far only a few sample values, but more can be added,
> if we can agree what they are, and what they are called!
> (Views please!).

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.

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.

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.