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

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2007-02-23 12:18:58

Gennadiy Rozental writes:
 > 
 > "Dave Steffen" <dgsteffen_at_[hidden]> wrote in message 
 > news:17881.53633.397413.288713_at_yttrium.numerica.us...
 > > > 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.
 > 
 > Could you be please more strait to the point. I need some specifics instead 
 > of general "I don't like behavior"
 > 
 > What behavior? Which comparisons? How would you like it to behave? Specific 
 > examples please.

 As I've said before, the use of percentages to specify tolerances
 drives me crazy.  But, as a stronger (and more useful statement), the
 continued existence of this thread, with all kinds of different
 opinions about what kinds of comparisons should be supported and what
 they should be named, is empirical evidence that A) I'm not the only
 one who doesn't like that, and B) nobody agrees on a better solution.

 In other words, it's not an easy problem. :-)

 _I_ don't have any better ideas, aside from a general agreement with
 the other posters in this thread, that it would be nice if the Boost
 Test library had a naming convention that makes the kind of floating
 point comparison more clear, and that it should support more kinds.

 > > 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...
 > 
 > IMO BOOST_CHECK_PREDICATE + class predicate result should satisfy your 
 > needs. Again: general answer on general comment.
 > 
 > > 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.
 > 
 > This is one of the few examples where original interface was deemed unsafe 
 > and I moved to new safer one. It shouldn't happened on a regular basis

 Right.  And I knew when I started using Boost 1.32's library that it
 was still experimental, and that such changed might happen.  I'm
 happy to continue using the library under those circumstances.

 > > Since there are a few other assertion macros that we find handy, I
 > 
 > Like what?

 We have our own set of ASSERT, WARN, and FAIL macros we use in our
 application code.  Under one compilation setup, ASSERT throws a
 special kind of exception ("Death") that can be caught by a unit
 test; that is, the unit test can intentionally break a class
 invariant and check that the class correctly complains.

 Since the "Death exception" is an implementation detail, I simply
 created a macro called "CHECK_ASSERTION" which wraps a
 CHECK_EXCEPTION.

 Just so we're clear: I'm not complaining about having to wrap things.
 I don't consider this a failure of the library.  I like the boost
 test library, and think that its design is reasonable... except for
 the floating point comparison issues people are talking about
 now. :-)  The library is going to have a "shape", and if people want
 their unit test framework to have a slightly different shape (as I
 do), that's not necessarily a criticism of the original library, nor
 is it necessarily the sign of a design problem.

 > > 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.
 > 
 > Did you have a change to review it?

 Sigh... not yet. Between a company ski trip, and an unsuccessful
 library update on my laptop (I usually like Mandrake Linux, but argh)
 I haven't gotten around to it. :-(

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