No subject

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