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

[Amitha Perera]

I'm going to write some comments which I'm sure will be controversial. 
I'm not looking to start a flame war, and I don't intend to respond 
further on this topic.

I come from the vxl/vnl side, and so I'm sure I have obvious biases. 
 From that land, though, I appreciate very much to Tom's contributions 
to efficient rounding.

The gist of my position on rounding in imaging (vision and medical) 
applications is this: if your algorithm's success depends on whether a 
pixel with value 12.5 is rounded to 12 or 13, then your algorithm is so 
brittle as to be useless.

If you pause to think about the source of your floating point pixels, 
you will quickly realize that a value of 12.5 is really just a sample 
from a distribution around 12.5, and it is just as possible that the 
sampled value (from the same source) is 12.5+eps or 12.5-eps.  And this 
is from the imaging hardware; floating point representation inaccuracies 
also introduces issues.  (Case in point: Luis's test case mentioned 
earlier in the thread.)

Now, there are certainly problems where the source numbers are better 
known, and where the rounding mode does affect things.  (Statistical 
analysis of large financial data sets has been mentioned previously.) 
And to this point, the IEEE floating point specification defines 
rounding modes for this purpose.

However, I'd argue that this issue is really not critical to most image 
processing algorithms.  While I certainly understand and accept that 
variances add, properly managing the addition of noise can only be done 
by really understanding and characterizing the source of the noise. 
I'll challenge anyone to honestly tell me that they have a noise model 
so accurate that the rounding mode critically affects the noise model of 
the rounded pixel values.

So, while I agree with Luis's principle that there should be 
RoundToNearest, RoundToEven, RoundAwayFromZero, RoundDown, RoundUp 
(wait... those are the IEEE rounding modes.  What a coincidence.), one 
should not lose sight of the fact that most often required function is
   JustRoundItQuickly

Also keep in mind that making someone choose RoundToNearest or 
RoundToEven implies that the person is in a position to determine from 
some underlying model that one or the other is correct.  I'd wager that 
most folks are not in that position, and would simply want to pick 
whichever is faster.

As you, the itk developer community, resolve this issue, I would urge 
you not to forget that while the distinctions between different rounding 
modes are important in a theoretical sense, they are often not important 
in practice.

Another comment on this thread that I agree with the spirit of: the 
results should be reproducible across platforms.  Again, my opinion is 
that instead of measuring if
    Alg( FixedInput ) = KnownOutput
you should really be measuring
    Alg( FixedInput + Noise ) = KnownOutput

I dare say that if such a test passes for one platform, it'll pass for 
all platforms regardless of the specific rounding mode.

Anyway.  I've probably generated more heat than light, so I should stop 
now... :-)

Cheers,
Amitha.