From: Tom Vercauteren <tom.vercauteren@m4...>  20090310 11:14:44

Hi Amitha, First of all, sorry for taking so long to get back to you on this rounding issue. Since some time has passed let me recap things a little. There is a consensus that efficient floating point to integer functions is definitely a good thing to have. Most of it is already in vnl_math.h. Round to the nearest integer is somewhat ill defined in the sense that we still need a rule for half integers. Typical rules that might be used for halfintegers are:  round away from zero  round up  round down  round to nearest even These rules can be implemented efficiently provided that the following assumptions are made:  The rounding mode of the FPU is not changed from the default one  For some rules the efficient implementation only works for numbers whose absolute value is less than INT_MAX/2 Without these assumptions, there is no possible efficient (and correct) implementation that I know of. Currently, vnl_math_round is implemented in such a way that it tries to pick the most efficient rule among these ones depending on the platform. Having a implementation that is consistent across platforms might however be of interest, notably for several ITK developers who would like to have the round up version. Following our discussion, I have implemented two additional rounding functions:  vnl_math_rnd_halfinttoeven  vnl_math_rnd_halfintup In the attached patch, vnl_math_rnd is now basically a wrapper around vnl_math_rnd_halfinttoeven except when a vanilla c implementation is used. Similarly vnl_math_rnd_halfintup becomes a wrapper around vnl_math_rnd_halfinttoeven with a multiply and divide by two trick except when a vanilla c implementation is used. The unit test for vnl_math has been expanded accordingly. Let me know, if you think this patch needs more work. Regards, Tom On Sat, Jan 17, 2009 at 15:34, Amitha Perera <amithaperera@...> wrote: > Tom Vercauteren wrote: >> Such a solution would be OK for me. I would however use >> "vnl_math_rnd_halfintup" rather than "vnl_math_rnd_nearest" >> and >> "vnl_math_rnd_halfinttoeven" rather than "vnl_math_rnd_even" > > Fine with me. > >> Also some users might find it confusing to have 3 different >> implementations of vnl_math_rnd that only differ in how half integers >> are rounded. > > Well, this cannot be avoided in a general sense, since the > implementations are there because there is already an issue about what > rounding should mean. I think the only solution is good documentation > about which function does what, and what the tradeoffs are, and perhaps > a "if you don't know of the issue, use this" type of recommendation. > > > One alternative would be to drop >> "vnl_math_rnd_halfinttoeven" as it can be made redundant with the >> current "vnl_math_rnd". > > That would imply that vnl_math_rnd must always round to even. This is > not guaranteed, even with the assembler/SSE implementation, because it > is dependent on the rounding mode. (You said the same thing in your > message.) Keeping the three means that the semantics of vnl_math_rnd is > less well defined (e.g., it could be either to even or to nearest), but > is guaranteed to be the fastest possible on the platform. If the > semantics matter more than the speed, then use the appropriately named > function. > > Amitha. > >  > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sfspreadtheword > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > 