[Insight-developers] vnl update and vnl_math_round

[Tom Vercauteren]

Hi Simon,

Thanks for the feedback. I just wrote a patch for vnl and proposed it
on the vxl mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_name=28392e8b0901120918l45e9e81bq5395cb6630ddacc1%40mail.gmail.com&forum_name=vxl-maintainers

Let's see how it goes.

Regards,
Tom

On Fri, Jan 9, 2009 at 9:01 PM, Simon Warfield
<simon.warfield at childrens.harvard.edu> wrote:
> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>