[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