Petr Kocmid wrote:
>  I feel limiting to one fp representation is problematic. Consider a 3D
>  visualisation application, doing RT world geometry transformations in floats
>  (as certain API needs) and some math computation (RT signal processing) in
>  doubles (as another API needs) at the same time. Also, customer made numeric
>  types are often needed in addition, often on platforms which do not have
>  floating point hw at all (an extreme example: Hubble scope is controled by
>  286 cpu...).

I second this. Our notion of math constants should be extensible.

>  I think a solution with no complexity for you would be to wrap all your
>  constants as statics to template class (otherwise empty, so no overhead (in
>  case of floats and doubles)), and define constant specialisations for them.
>  The class is seen by library user as a wraping namespace, not an object.

In order to keep things extensible, I favour the function approach
previously discussed. I feel that static constants are possibly limiting,
and require implementation in a separate source file (if we don't use
an unnamed namespace) to resolve ODR issues. (Functions can be inline
and thus have internal linkage). If some function specializations desire
to refer to static constants, they may do so, but this is entirely an
implementation decision.

>  Usage should be quite pleasing the eyes of even the boost purists:
>  cout << math_const<float>::pi << math_const<double>::pi;

math_const<float> ::pi() is at least as pleasing to the eye :-)

>  INSTANTIATE_PI(float);
>  INSTANTIATE_PI(fixed<int,int>);

No macros at the interface level, please.

>  In later case, if fixed<int,int> suppplies initialization from double, your
>  constants will work with fixed<int,int> too.

Conversion from and to double is a delicate issue and has been discussed
in the rational<>  context already. I'd rather not provide too much
automatics in this regard to force the library author to think about
the precision implications. This seems particularly important for math
constants, for which there is no reason to be less exact than 0.5 ulps
(units in the last place).

Jens Maurer