From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2007-02-19 11:34:09
Gennadiy Rozental writes:
> "Dave Steffen" <dgsteffen_at_[hidden]> wrote in message
> > > 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
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
dg_at_steffen a_at_t numerica d_at_ot us (remove @'s to email me)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk