[Insight-developers] CovariantVector::GetSquaredNorm()

[David Doria]

The current implementation of CovariantVector::GetSquaredNorm() seems to
assume that the component type may have a problem being multiplied and
added (overflow). However, when the component type IS capable of these
operations, a penalty is still paid in the conversion of everything to
double (itk::NumericTraits<every POD>::RealValueType = double).

In my program, I have images of CovariantVector<int, 3> pixels and I get
about a 20% speed up if I change the current implementation:

template< class T, unsigned int NVectorDimension >
typename CovariantVector< T, NVectorDimension >::RealValueType
CovariantVector< T, NVectorDimension >
::GetSquaredNorm(void) const
{
  RealValueType sum = NumericTraits< RealValueType >::Zero;

  for ( unsigned int i = 0; i < NVectorDimension; i++ )
    {
    const RealValueType value = ( *this )[i];
    sum += value * value;
    }
  return sum;
}

to

 template< class T, unsigned int NVectorDimension >
 typename CovariantVector< T, NVectorDimension >::ValueType
 CovariantVector< T, NVectorDimension >
 ::GetSquaredNorm(void) const
 {
   ValueType sum = NumericTraits< ValueType >::Zero;

   for ( unsigned int i = 0; i < NVectorDimension; i++ )
     {
     const ValueType value = ( *this )[i];
     sum += value * value;
     }
   return sum;
 }

(note that the return type as well as the internal type has changed).

I can't think of a reasonable way to determine automatically if there will
be a problem (it is not just a signed/unsigned type of problem, but rather
it actually depends how large the values are relative to the size of the
type). Would it make sense to add a second function called something like
GetSquaredNormNoCast() or something like that that can be used in cases
where the developer knows that there will be no chance of overflow and
would like to get the speed savings?

Thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120831/de6c7414/attachment.htm>