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

[Luis Ibanez]

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