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

[Tom Vercauteren]

Hi,

On Wed, Jul 22, 2009 at 15:52, Bradley Lowekamp<blowekamp at mail.nih.gov> wrote:
> 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.

I really like this proposal! It seems perfects. Attached is a modified
test that implements its. As expected the compiler is smart enough to
detect which if branch to take at compile time. See below for some
numbers generated with the attached test code. The templated and
non-templated code perform very similarly.

> 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.

I am not sure if it's worth implementing these specialization but of
course it's doable. I would rather have an initial version that
assumes the return type is signed integral. We could also add a
concept check to ensure this assumption.

Tom


The timings. 64 or 32 stands for the implementation and if a t is
appended this means we go through the templated version.

32 bit mac
-----------------
time64_ref:   1283.29
time64_lround:1461.32
time64_lrint: 678.082
time64_asm:   522.517

time32_ref:   778.252
time32_lround:1125.76
time32_lrint: 424.175
time32_asm:   281.587
time32_sse2:  233.783

time64t_lround:1459.49
time64t_lrint: 678.447
time64t_asm:   522.429

time32t_lround:1125.35
time32t_lrint: 423.215
time32t_asm:   281.682
time32t_sse2:  233.911


64 bit linux
-----------------
time64_ref:   809.522
time64_lround:1744.89
time64_lrint: 362.238
time64_asm:   285.881
time64_sse2:  188.616

time32_ref:   817.97
time32_lround:1751.11
time32_lrint: 360.676
time32_asm:   287.01
time32_sse2:  188.54

time64t_lround:1721.61
time64t_lrint: 362.308
time64t_asm:   286.329
time64t_sse2:  189.178

time32t_lround:1753.6
time32t_lrint: 360.406
time32t_asm:   286.096
time32t_sse2:  188.454


32 bit linux
-----------------
time64_ref:   1269.19
time64_lround:1929.4
time64_lrint: 870.431
time64_asm:   325.291

time32_ref:   991.258
time32_lround:1896.04
time32_lrint: 442.18
time32_asm:   328.958
time32_sse2:  285.988

time64t_lround:1910.28
time64t_lrint: 868.839
time64t_asm:   322.855

time32t_lround:1832.57
time32t_lrint: 439.395
time32t_asm:   329.541
time32t_sse2:  286.428
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rounding64_time_tests.cxx
Type: text/x-c++src
Size: 9650 bytes
Desc: not available
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090722/685cf30f/attachment.cxx>