[Insight-developers] vnl updates : Rounding Test : Performance and Correctness

[Bill Lorensen]

Luis.

I agree 100%!.

Bill

On Tue, Dec 30, 2008 at 5:09 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
> To get some hard data on timing and correctness
> I just added a test:
>
>          itkVNLRoundProfileTest1.cxx
>
> to Insight/Testing/Code/Common
>
>
> It does the following:
>
>
>    A) Compares the "if" implementation
>       of rounding to the vnl_math_rnd()
>
>    B) Measures the computation time needed
>       for executing vnl_math_rnd()
>
>
> After running the test on Linux, gcc 4.2 we observe that
> it fails due to the policy of rounding to Even...
>
>
> Here are my early impressions:
>
>  1) Rounding is too much of a basic operation.
>
>  2) Implementing it is a very minimal amount of code
>
>  3) We use it everywhere
>
>  4) We need it to be cross-platform
>
>  5) We need it to be reasonably fast,
>     but it is not the most demanding part of our
>     algorithms.
>
>
>
> That leads me to suggest:
>
>
>  a) Let's stop using vnl_math_rnd()
>
>  b) Write our own (let's discuss the details in a separate email)
>
>     We are talking about 10 ~ 20 lines of code,
>     we should be able to do that  :-)
>
>
>  c) Have a biased and non-biased implementation
>
>      * double itkRound( double )
>      * double itkNonBiasRound( double )
>      * ... and maybe other flavors too...
>
>
>     and use one or the other depending on the application.
>
>
>
> The overall impression is that: ITK being a library with
> more than 130,000 lines of code, it would be shameful to
> depend on a third party library for implementing correctly
> an operation as basic as rounding, particularly when we
> can implement it in 10 lines of code.
>
>
>
>     Luis
>
>
>
> --------------------
> Bill Lorensen wrote:
>>
>> I wonder what the radiology community says about this?
>>
>> On Tue, Dec 30, 2008 at 4:32 PM, Steve M. Robbins <steve at sumost.ca> wrote:
>>
>>> On Tue, Dec 30, 2008 at 01:58:28PM -0500, Luis Ibanez wrote:
>>>
>>>
>>>> Choosing the rounding standard based on the performance of the platform
>>>> doesn't seem to be a good solution for ITK.
>>>>
>>>> We would want a round() function that produces the *same* output on
>>>> *every* platform.
>>>
>>> That makes sense to me.
>>>
>>>
>>>
>>>> If we pick a rounding policy, it should be the same for all
>>>> platforms, and it should also include a specification on how
>>>> it will apply to negative numbers.
>>>
>>> I've always been under the impression that round-to-even is to be
>>> preferred, since the other methods (round-up, round-down, or
>>> round-to-zero) will bias the calculations.
>>>
>>> Quoting Wikipedia:
>>>
>>>  Despite the custom of rounding the number 4.5 up to 5, in fact 4.5
>>>  is no nearer to 5 than it is to 4 (it is 0.5 away from both). When
>>>  dealing with large sets of scientific or statistical data, where
>>>  trends are important, traditional rounding on average biases the
>>>  data upwards slightly. Over a large set of data, or when many
>>>  subsequent rounding operations are performed as in digital signal
>>>  processing, the round-to-even rule tends to reduce the total
>>>  rounding error, with (on average) an equal portion of numbers
>>>  rounding up as rounding down. This generally reduces upwards
>>>  skewing of the result.
>>>
>>>  http://en.wikipedia.org/wiki/Rounding
>>>
>>> Also, according to Goldberg's classic paper [1] Knuth also prefers
>>> round-to-even, which is a strong recommendation in my books ;-)
>>>
>>> [1] http://docs.sun.com/source/806-3568/ncg_goldberg.html
>>>
>>> Cheers,
>>> -Steve
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>> iD8DBQFJWpNp0i2bPSHbMcURAkkEAKCeGnxwyjeQYc+NiJ7tcPiw/3birgCfZ9zv
>>> F5W5uGojrYesCPeonZloUpw=
>>> =E/CS
>>> -----END PGP SIGNATURE-----
>>>
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>
>>
>>
>