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
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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk