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

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2007-02-19 11:34:09

Gennadiy Rozental writes:
 > 
 > "Dave Steffen" <dgsteffen_at_[hidden]> wrote in message 
 > news:17877.60853.224689.969078_at_yttrium.numerica.us...
 > > > To put things another way: how many people do you expect to
 > > > thinking in terms of persentage differences between floating point
 > > > numbers?  I'm afraid we (mostly) all think in terms of epsilon
 > > > units, and once in that mind set, converting to persentages just
 > > > doesn't come naturally.
 > >
 > > Right.  At least, that's true of people like me who do
 > > mathematical stuff.  Maybe there are vast herds of C++
 > > programmers out there who think in terms of percentage tolerance,
 > > though.  I'm not saying it was necessarily a bad design problem.
 > > It's a (mildly) bad design for what _I_ want, but then, I'm
 > > wrapping the whole unit test library up in my own interface
 > > anyway. :-)
 > 
 > What particularly you are missing/don't like in current interface
 > presented by Boost.Test (other than FP comparison tools interface)?

 Well, the naming and behavior of the floating point comparisons, for
 one thing.  As evidenced by the large number of posts on the subject
 over the weekend, people are A) unhappy with what exists in the Boost
 library right now, and B) not completely happy with each other's
 solutions.

 :-)

 Let me say, though, that while I think anyone who thinks in
 percentage difference is crazy, that's just me, and I have a
 particularly math/physics perspective.  In other words, I don't claim
 that people will or should agree with me.

 Consider, though, the following point. Much of what we do around here
 is linear algebra, so the question arises: how do you relative
 differences between vectors?  The answer is, of course, that there's
 more than one way to do it.  I wanted a system that made it easy (or
 at least possible) to plug other mathematical things into
 BOOST_CHECK_CLOSE: vectors, matrices, track states, Kalman filters...

 My solution -- which I'm not completely happy with -- is to define a
 set of overloaded functions with an appropriate signature, and
 provide my own set of "BOOST_CHECK_CLOSE"-y macros to use them.

 Another thing I'd like to avoid dealing with is the API change to
 BOOST_CHECK_EQUAL_COLLECTIONS (from three to four parameters).  I
 understand that Boost Test is still evolving, and that API's will
 change, and that's fine; I just wanted an extra layer that might
 possibly make the next such transition easier.

 Since there are a few other assertion macros that we find handy, I
 decided to wrap the whole thing, so as to provide a consistent
 interface.  One of the primary things I want out of a unit test
 framework is that it's *easy to use* (which in general Boost Test
 very much is), so I didn't want people to have to think about which
 assertions start with BOOST and which ones start with something else.

 And BTW, I haven't looked at all at 1.34 RC anything.  I know there's
 new functionality there, and will look at it this week.

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