[Insight-developers] Math function consistency

Hans Johnson hans-johnson at uiowa.edu
Wed Jun 1 00:53:51 EDT 2005


ITK Developers,

I am working on a port of ITK to the MipsPro 7.4 compiler, and I have a
working version by making only a few modifcations (this is without
wrapping).  The hardest part so far was tracking down the IRIX OS patch that
installed the C++ std. headers <cmath> <cassert> ... headers.

Here's what I had to do:
1) Code/Common/itkShapedNeighborhoodIterator.h
<   typedef typename Superclass::ImageBoundaryConditionPointerType
<   ImageBoundaryConditionPointerType;
<   
<   /** Typedef support for common objects */
<   typedef TImage ImageType;
<   typedef typename TImage::RegionType RegionType;
<   typedef Index<itkGetStaticConstMacro(Dimension)> IndexType;
<   typedef typename IndexType::IndexValueType IndexValueType;
<   typedef Neighborhood<PixelType, itkGetStaticConstMacro(Dimension)>
NeighborhoodType;
---
>   typedef typename Superclass::NeighborhoodType NeighborhoodType;
>   typedef typename Superclass::IndexType IndexType;
>   typedef typename Superclass::ImageType ImageType;
>   typedef typename Superclass::RegionType RegionType;
>   typedef typename Superclass::IndexValueType IndexValueType;

The original typedef for NeighborhoodType caused a problem for the compiler.
Many other typedefs that were the same were taken from the Superclass
anyway, so I just kept with the convention and converted all the common
types between the subclass and the superclass to reference the superclass.

2)  replaced sqrt, log, and cos with vcl_sqrt, vcl_log, and vcl_cos in the
new itkMersenneTwisterRandomVariateGenerator.h.

3) replaced fabs with vcl_abs in
itkMersenneTwisterRandomVariateGeneratorTest.cxx

In doing this I also found that the use of the vcl_ functions is very
sporadic in the code.  I could have also included <math.h> to solve the this
same problem.  I would suggest that a pass is made through the code with the
following replacements:

Include <math.h> ---> include <vcl_cmath.h>
sqrt(double) -->vcl_sqrt(double)
sqrt(static_cast<double>(numeric_type)) -->vcl_sqrt(numeric_type)

cos(double) --> vcl_cos(double)
cos( static_cast<double>(numeric_type)) --> vcl_cos( numeric_type)


abs(int) --> vcl_abs(int)
fabs(double) --> vcl_abs(double)
fabs( static_cast<double>(numeric_type)) --> vcl_abs( numeric_type)

And so on.

Note that the vcl_foo functions are overloaded based on type ( in most cases
just using the equivalent std::foo function call from <cmath> ).

I'd be willing to make the changes to all files below the "Code"
subdirectory, and run the regression test before committing.

Any objections?  Comments?





More information about the Insight-developers mailing list