unittest: Proposal to add failUnlessNear

[Antoon Pardon]

John Roth <newsgroups at jhrothjr.com> wrote:
> "Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message
> news:slrncfpk65.m9.apardon at trout.vub.ac.be...
> > Op 2004-07-19, John Roth schreef <newsgroups at jhrothjr.com>:
> > > "Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message
> > > news:slrncfnaq7.kj.apardon at trout.vub.ac.be...
> > >> I have been working with unittests lately and found that the
> > >> self.failUnlessAlmostEqual, isn't as usefull as it could be.
> > >>
> > >> My main problem is, that it is only usefull with objects
> > >> that can be converted to floats, while there are a whole
> > >> bunch of objects that can be almost equal but not so
> > >> convertable. The first example coming to mind being
> > >> complex numbers.
> > >>
> > >> A secondary objection is that you are limited to
> > >> a very specific set of tolerances. If for instance
> > >> you want to verify that two numbers differ at most
> > >> by 0.0003 you can't specify that.
> > >
> > > Float and complex have two very different issues.
> >
> > Only if you want them to be. Floats are a subset
> > of complex and as such can be treated exactly
> > the same.

> Floats are not a subset of complex. I concur
> with Roy Smith's comments on that issue. There's

Yes they are.

> no reason why complex numbers cannot be
> represented by a pair of integers, or rationals,
> or the new floating decimal type, or whatever.

I think this is getting sidetracked. This started
with a request for a better test to check whether
something is near enough something else. Since
all your alternatives give exact results you don't
need to test for nearness you test for equality.

So within this contexts where you can't calculate
things exactly floats are a subset of complex.

> In addition, you're going to have to do significant
> type checking if you want to combine floats and
> complex in the same method call. That's just
> poor design.

No you don't. Please explain why something like

  abs(a - b) < tolerance

needs typechecking when a and b can be complex
numbers as well as floats

> > > Since I'm maintaining the Python port of FIT, I
> > > had to deal with them. What I did for float was
> > > use the character form of the float to determine
> > > the precision. The default routine appends a
> > > character 5 and then uses this to calculate the
> > > bounds within which the other value must be found.
> > >
> > > An example may help. Let's say I want to
> > > test against '6.23e14'. This method would
> > > establish bounds of 6.235e14 and 6.225e14
> > > and then test whether the other number was
> > > within those bounds. (Note that the '5' is
> > > appended before the numbers are converted
> > > to float, however the second bound is calculated
> > > after the conversion.)
> >
> > Why don't you just test whether the second
> > number lies within a fault tolerance of
> > 5e11 of 6.23e14

> I take it you've never worked with FIT. It's intended
> to be used by non-technical people on a project, such
> as the on-site customer, business analysts and so forth.
> If I did something as silly as requiring them to insert
> a tolerance that is blatently obvious to anyone looking
> at the number involved, I'd get a change request so fast
> that the edges would char from the friction.

A tolerance is never blatantly obvious from looking
at the number involved. On a number like 6.23e14
the tolreance could be 5e11 or 3e12 in fact from
just looking at the number I would guess at a tolerace
of 1e12, in other words bounds between 6.22e14 and
6.24e14.

Besides you are mixing user interface and implementation.
There is nothing stopping you from inferring this obvious
tolerance and using it in your program. The fact that
the user just insered 6.23e14, doesn't stop you the
programmer to test whether a second number lies within
a fault tolerance of 5e11 of 6.23e14

-- 
Antoon Pardon