Re: [boost] Numeric constants

Subject: Re: [boost] Numeric constants
From: Brandon Kohn (blkohn_at_[hidden])
Date: 2009-01-31 09:56:04

> 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