unittest: Proposal to add failUnlessNear

[John Roth]

"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
no reason why complex numbers cannot be
represented by a pair of integers, or rationals,
or the new floating decimal type, or whatever.

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.

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

It would also violate the interface agreement that all
ports of FIT are supposed to conform to.

John Roth
>
> -- 
> Antoon Pardon