[Insight-developers] Class vs Namespace

[Bradley Lowekamp]

Currently we have two things we would like to put into itk::Math,  
weather it be a namespace or a class. The first is the rounding  
methods and the second is the numeric constants. For the numeric  
constants consider these two different possibilities:


math.h:
class Math
{
	static const double p;
}

math.cxx:
const double p = 3.14;

Where as with a namespace, we don't need the static qualifier and I  
believe the following will not have the linking issues, and is valid c+ 
+:

math.h:
namespace Math {
	const double p = 3.14;		
};


With the namespace implementation we can always get optimizations, but  
there will be multiple addresses in different compilation files. I  
don't believe that that latter is really a negative though.


Brad


On Aug 6, 2009, at 11:21 AM, Tom Vercauteren wrote:

> Hi Brad,
>
> Moving these mathematical constants to a more visible place sounds
> good to me. However, handling floating point constants in c++ is a
> pain. For example, the following code is not standard and won't be
> usable on several systems (mac gcc 4.0 at least):
>
> class No_Good {
>  static double const d = 1.0;
> };
>
> I guess that's why boost chose to implement these constants as
> template functions:
> http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/math_toolkit/toolkit/internals1/constants.html
>
> The other option is to decouple the definition and declaration as done
> in vnl  (with some ugly macro):
>
> class Now_Better
> {
>    static double const d;
> };
>
> double const Now_Better::d = 1.0;
>
> More information can be found here:
> http://stackoverflow.com/questions/370283/why-cant-i-have-a-non-integral-static-const-member-in-a-class
>
> No matter the implementation, I would definitely vote for replacing
> the current hard-coded values by a common thing such as vnl_math::pi,
> itk::Math::pi, or  itk::Math::pi<double>().
>
> My two cents,
> Tom
>
> On Thu, Aug 6, 2009 at 16:40, Bradley  
> Lowekamp<blowekamp at mail.nih.gov> wrote:
>> Hello,
>>
>>        I was looking at:
>>
>> BasicFilters/itkBilateralImageFilter.txx:  rangeGaussianDenom =
>> m_RangeSigma*vcl_sqrt(2.0*3.1415927);
>>
>> It took me a little bit to figure out that we most likely should be  
>> using
>> vnl_math::pi, along with their "e and all that". I do wonder if these
>> constants were in itk::Math and in doxygen if it would help with  
>> increased
>> usage.
>>
>> So I began greping in the "Code" directory and came up with the  
>> following:
>>
>> grep -r 3.1415 *
>> BasicFilters/itkBilateralImageFilter.txx:  rangeGaussianDenom =
>> m_RangeSigma*vcl_sqrt(2.0*3.1415927);
>> BasicFilters/itkVectorGradientMagnitudeImageFilter.txx:  const  
>> double dpi =
>> 3.14159265358979323846;
>> Common/itkGaussianDerivativeSpatialFunction.txx:    prefixDenom *=
>> 2*vcl_pow( 2 * 3.1415927, VImageDimension / 2.0);
>> Common/itkMersenneTwisterRandomVariateGenerator.h:  double phi =  
>> 2.0 *
>> 3.14159265358979323846264338328
>> Numerics/itkCumulativeGaussianOptimizer.cxx:  m_ComputedAmplitude  
>> =  sum /
>> (m_ComputedStandardDeviation * vcl_sqrt(2*3.14159265));
>>
>> grep -r 0.707 *
>> BasicFilters/itkBSplineResampleImageFilterBase.txx:      m_G[0]  =
>>  0.707107;
>>
>> grep -r 1.414 *
>> Numerics/Statistics/itkGaussianDistribution.cxx:    dq  = 0.5e+0 *  
>> vnl_erfc(
>> dx / 1.414213562373095e+0 ) - dp;
>> Review/Statistics/itkGaussianDistribution.cxx:    dq  = 0.5e+0 *  
>> vnl_erfc(
>> dx / 1.414213562373095e+0 ) - dp;
>>
>> grep -r vnl_math:: * | wc
>>      69     571    7652
>>
>> Well I guess that is almost 90% usage of the numeric constants, so  
>> its not
>> bad at all.
>>
>> I'll work on a patch tonight, and likely commit something tomorrow  
>> if no one
>> sees a problem with this.
>>
>> Brad
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>