Re: [boost] Boost Test Library: general floating point comparisons

From: Glenn Schrader (gschrad_at_[hidden])
Date: 2007-02-14 11:11:14

Comparing matrices and vectors is a topic that I have had to deal with. 
An important issue here is that there are different ways of comparing 
that are appropriate for different cases. It really depends on the 
computation that produced the vector or matrix. For instance, say we 
have a matrix and we do an FFT along each rows (a common case in signal 
processing). One way to compare the result against a reference matrix is 
to compute an RMS error for each row and take the maximum of the row 
errors for the overall error. Note that a simple maximum of the 
element-wise errors doesn't work well in practice since elements with 
very small values can have large errors (percentage wise) with respect 
to the reference value but will not be significant within the context of 
the values in the row. Also, a full matrix technique (e.g. comparing 
eigenvalues and eigenvectors) wouldn't be appropriate either since each 
row is the result of a separate FFT and the errors will be be correlated 
across rows. Actually, similar problems crop up when comparing 
individual complex values (i.e. values that have both a real and a 
complex component).

The three basic patterns that come to mind are element-wise comparison 
(good for either vectors or matrices), vector-wise comparison (good for 
either vectors or along the rows / columns of a matrix), and 
matrix-wises comparison. If you just need a simple element-wise 
comparison then thats fine but it would be good if the framework is 
extensible enough to handle more complex cases.

Glenn Schrader

Dave Steffen wrote:
> Fine.  Now, we want to be able to compare more complicated
> mathematical objects, such as vectors and matrices.
>
> After some thought, we decided the responsibility for providing such
> functions is the responsibility of the mathematical object, not the
> unit test framework.  That is to say, a function "relative difference
> between matrices" should be in Matrix.h, not some unit test thing.
>
> Which leads to the idea of Matrix.h #including
> "boost/test/floating_point_comparison.hpp", which strikes me as rather
> odd.  My first impulse was to copy/pull the relevent code out of
> floating_point_comparison.hpp and stick it in some more convenient
> place, where mathematical objects could use those functions to
> implement their own comparision functions.
>
> Might this be a common idiom?  Might we consider factoring these
> floating point comparison functions (not the BOOST_CHECK_CLOSE macro,
> but the functions it uses) out into a separate library?  Any comments
> on my approach?
>
> Any and all thoughts, comments, or complaints welcome.  Thanks!
>
> ----------------------------------------------------------------------
> Dave Steffen, Ph.D.                Disobey this command!
> Software Engineer IV                 - Douglas Hofstadter
> Numerica Corporation
> dg_at_steffen a_at_t numerica d_at_ot us  (remove @'s to email me)
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>