Boost logo

Boost :

From: Eric Ford (eford_at_[hidden])
Date: 2001-10-14 22:59:13

> I am still concerned that it all fails the KISS principle,
> (so I still propose to produce files containing long double values
as well

I don't understand the connection between the concern and the plan.

> - I still believe that the main use will be to cut and paste!)
> I have not used Eric's macros because the .hpp files will of course
> be generated using Victor Shoup's extended precision system NTL,
> and I will make the program actually write the C++ code as
> well as the values. (and because MACROs obscure the principles

It's fine with me if something other than macros are used. However,
in light of the fact that it's likely users will want to add their own
constants, I would hope there was a way to make this easy for a
non-C++ guru.

> (I have also not shown any physical (variable?) constants because I
> these
> should be kept separate, but Eric has shown how to do it.

Ultimately, how to do it will depend on the unit library interface.

> Physical constants do raise namespaces questions:
> If we have a namespace math, then physical constants don't belong
> Perhaps they belong in a units /SI namespace?)

Hmm, some physical constants (e.g. conversion factors) might rightly
belong in an si or units namespace. However, I think there will be a
signficant number of constants (e.g. G or hbar) that don't belong

Maybe we should think about whether we want all the constants in one
place (namespace constants with subnamespaces?) or whether we want
every library to provide their own constants using whatever standard
form is decided upon (e.g. some in si/units, some in math, some in
graph library, some in namespaces for individual domains).

> I am also giving some thoughts to subdivision of constants into
> three .hpp files as suggested:
> #include "boost/math/constants.hpp" // common - see below.
> #include "boost/math/constants2.hpp" // less common
> #include "boost/math/constants3.hpp" // obscure
> Any views on better file names?

I think I'd prefer dividing the constants by topic. Maybe things like
numbers.hpp, algebraic.hpp, trigometric.hpp, number_theory.hpp,
physics.hpp, etc.. Also, I might suggest making a constants
subdirectory in math. I guess this may boil down to a battle between
the supporers of a big collection of constants and the supporters of a
minimal collection of constants. At this point I prefer a big

I'll try to take a look...


Boost list run by bdawes at, gregod at, cpdaniel at, john at