Is that what you were looking for?
John.
Indeed it does do the trick nicely. In what I wrote I diverged slightly from the clean path by using a rational promotion trait type. I think the main difference is that it really doesn't make sense to define PI for a plain integral type (3...) so I added type promotion to a rational into the mix. This allows me to simply ask for a value of pi given whatever type I'm currently working with and let the generative machinery crank out the details such as a promotion to rational if required. Then using something like auto or typeof I can abstract number types from these details and carry on with the work in the problem space without having to worry about whether the type returned can actually be properly represented/approximated. I guess the argument then becomes whether it's more correct to simply return the whole number approximation of a constant under the specialized type or to attempt to adapt it into a more useful type. Maybe both via a modified alternate path? Perhaps this is something worth a bit of discussion, as there is the Boost.Rational library (which is nice.. but underutilized I suspect due to a lack of a Boost arbitrary integer.) Kevin Sopp has been working on such an integral type which seems to be coming along nicely. I also have a lazy_exact type which I've been using with Boost.Rational, Kevin's integer and some extension code to the rational I have written which allows for construction from floating point types and some other useful conversions. These ingredients are one way to manage writing geometry algorithms which are fraught with precision issues when performed under floating point. They ultimately form a suboptimal solution as lazy floating point filtered types are still very slow.. but sometimes there is little alternative. So even though it's not the fastest way to go (GMP beats this paradigm every time) I think it might be useful if Boost.Math (or something similar) supported these modes of use when accessing values for constants. Cheers, Brandon