[Insight-developers] Insight-developers Digest, Vol 57, Issue 6

[Simon Warfield]

Hi Tom,

  I think your proposal is very reasonable. It achieves good 
performance, and consistent cross-platform behavior.
  In my mind, one of the most important and common uses of rounding in 
ITK is the conversion of continuous indexes to identify voxels in the data.
  This rounding defines the extents of the voxels, and the consistent 
rounding upwards ensures that every voxel is exactly the same size.

  Some of the interpolators currently don't act consistently.  With this 
change to vnl_math_rnd and the patch you sent to turn on consistent 
treatment of voxel extents, we have the prerequisites in place to 
identify the interpolators that are working incorrectly and to correct them.
>
> Hi Kent and others,
>
> Thanks for the feedback. It seems that a consensus would be to have an
> implementation that is:
> 1) consistent across all platforms
> 2) reasonnably fast
> 3) not too confusing for a 'normal' user (advanced users can always
> write their own implementation)
>
> >From these points, I would vote for implementing vnl_math_rnd with
> half-integers being rounded upwards on all platforms. However what can
> not be guaranteed in this case (if a fast implementation is needed) is
> that vnl_math_rnd behaves correctly for numbers which absolute values
> are greater than INT_MAX/2 or when the rounding mode is changed from
> the default one and is not restored.
>
> A snippet for an implementation that respects these points is shown
> below (optimized version shown for SSE2 only).
>
> // vnl_math_rnd  -- round towards nearest integer
> //         halfway cases are rounded upward, e.g.
> //         vnl_math_rnd( 1.5) ==  2
> //         vnl_math_rnd(-1.5) == -1
> //         vnl_math_rnd( 2.5) ==  3
> //
> // Be careful: argument absolute value must be less than INT_MAX/2,
> // we also assume that the rounding mode is not changed from the default
> // one (or at least that it is always restored to the default one).
> #if VNL_CONFIG_ENABLE_SSE2_ROUNDING
> inline int vnl_math_rnd(float  x){
>   return (_mm_cvtss_si32(_mm_set_ss(2*x+0.5f))>>1);
> }
> #else
> inline int vnl_math_rnd(float  x) {
>   x+=0.5f; return static_cast<int>(x>=0.f?x:(x==static_cast<int>(x)?x:x-1.f));
> }
> #endif
>
> Tell me if you find this reasonable. There's a small price to pay for
> consistently rounding upward but we still have a decent performance
> improvement. On my machine here are some timings:
>
> Time for vanilla halfint round away zero :       643
> Time for vanilla halfint round up :                  832
> Time for lrint (halfint round away zero) :        321
> Time for sse2 halfint round to nearest even : 156
> Time for sse2 halfint round up :                    201
> Time for asm halfint round to nearest even :  175
> Time for asm halfint round up :                     221
>
> Regards,
> Tom
>
> On Wed, Jan 7, 2009 at 7:24 PM, kent williams
> <norman-k-williams at uiowa.edu> wrote:
>   
>> Notice: This UI Health Care e-mail (including attachments) is covered by the
>> Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential
>> and may be legally privileged.  If you are not the intended recipient, you
>> are hereby notified that any retention, dissemination, distribution, or
>> copying of this communication is strictly prohibited.  Please reply to the
>> sender that you have received the message in error, then delete it.  Thank
>> you.
>>
>> Am I the only programmer who thinks hard about rounding, every time I use
>> it, and usually ends up writing my own rounding function so that I know what
>> I'm getting?
>>
>> I can't think of a case in my own coding where I would trust a
>> just_round_it_some_way_or_other function.  But I may not be a 'normal user.'
>>
>> The fact is that even if the programmer doesn't explicitly ask for a
>> particular rounding type, they are making some sort of assumption about the
>> rounding type.  They're likely to be unconsciously making the wrong
>> assumption part of the time, which sometimes doesn't break anything.  But
>> when it does break something, you then spend a lot of time debugging, which
>> is a waste.
>>
>> Having clearly labeled rounding functions would be a big win, because it
>> would force those hidden assumptions to be explicitly stated. And while I
>> can envision algorithms that would work no matter the rounding used, I don't
>> think they're the most likely sort of programming to turn up often.  Usually
>> it matters,and sometimes it matters a lot.
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>     


-- 
Simon