[Insight-developers] itk::Math:: limitations (was: Using Math::Floor in interpolation code?)

[Bradley Lowekamp]

Hi,

I am not sure that we know what the types which will be needed. I  
think that we may need to template the methods. Something as follows:

// Template parameter type TReturn must be convertible from int32_32  
and int64_t
template <typename TReturn
#ifndef ITK_LEGACY_REMOVE
= int
#endif
 >
TReturn Round(double x)
{
if (sizeof(TReturn) <= 4)
	static_cast<TReturn>(vnl_fast_round32(x) );
else
	static_cast<TReturn>(vnl_fast_round64(x));
}

// similarly defined with float as well

First, this should maintain backwards compatibility. Second it will  
require, ITK it's self to specify the type we are trying to round to,  
whether that be int, long, ptrdiff_t or int64_t. The compiler  should  
be able to evaluate the "sizeof" expression at compile time so it's  
just as good as a ifdef. The trick will be to call the right version  
of the vnl methods.

So what it the behavior for the other types we don't currently use?  
unsigned integral types? float and double? Is further specialization  
required? We could use our version of  
std::numeric_traits<TReturn>::is_integer also to determine the best  
vnl methods to uses as well. As long as the expression can be  
evaluated at compile time, I would not expect a performance penalty.

Brad

On Jul 22, 2009, at 9:07 AM, Tom Vercauteren wrote:
> As far as I understand it, ptrdiff_t is basically a long (32bits an
> 32bit machine, 64 on 64 machines), right? If that's correct and we
> want a fast Round function that returns a ptrdiff_t, we still need
> something along the lines of


On windows 64, sizeof(long) = 4.



========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090722/53de1b3b/attachment.htm>