Open source develop: assertAlmostEqual

I've been working on a project at work while using Python/Jython. And I'm using unittesting to drive and test the development along the way. Because I deal with things like real data, the usual assertEqual runs into problems when you use floating point computation, because you just don't test for equality in floating point. To much potential for rounding errors at the 20th digit or some other insignificant problem. So you need to use assertAlmostEqual.

And everything is working fine, until I try to run my tests in Jython. And then all my floating point tests start to fail, because assertAlmostEqual does not exist. So, did I spell it wrong, but it worked under normal Python. So a quick google search reveals that assertAlmostEqual was added a bit later, so it was not in Python 2.2 (which Jython is written against). And there is a newsgroup posting in the Python-checkins list about the adding of assertAlmostEqual to the PyUnit testing library (which is what I use for my unit tests).

http://mail.python.org/pipermail/python-checkins/2002-December/032079.html

Sat, 28 Dec 2002 22:11:50 -0600

[Python-checkins] python/nondist/sandbox/twister test_random.py,1.1,1.2

Raymond> To accomodate single precision platforms, only test to seven
    Raymond> digits.

The SciPy folks have added an assertAlmostEqual method to their unit tests.
I believe it more-or-less just wraps what you've done in a callable method
(which takes a number of digits of precision).  Might be a good idea to add
something like it to unittest.py so the wheel doesn't keep getting
reinvented.  They actually have a few variants, coded as functions here:

http://www.scipy.org/site_content/remap?rmurl=http%3A//scipy.net/cgi-bin/viewcvsx.cgi/scipy/scipy_test/testing.py

Skip

Ok. That explains that. But something else looks oddly familiar. I remember doing something with SciPy around the same time
.

http://projects.scipy.org/pipermail/scipy-user/2002-January/008545.html

Sun Jan 20 21:38:03 CST 2002
[SciPy-user] unittests for scipy.stats: assert_almost_equal question

Hmmm, I think that I would like to be testing in terms of
significant digits as opposed to decimal places, especially when
working with floating point.  Since you are asking for such a test,
here it is.  The attached file has a function meant to go into the
scipy_test.py module.  I wrote assert_approx_equal following the
same form as assert_almost_equal
assert_approx_equal(actual,desired,significant=7,err_msg='',verbose=1):
compares 'actual' and 'desired' and determines the first
'significant' significant digits and checks for accuracy.  Let's
see, I think I counted significant digits correctly.  Can anyone
tell?

Louis
> From: "eric"
> To: <scipy-user at scipy.org>
> Subject: Re: [SciPy-user] unittests for scipy.stats:
> assert_almost_equal question
> Date: Sun, 20 Jan 2002 05:36:31 -0500
> Organization: enthought
> Reply-To: scipy-user at scipy.net
>
> Hey Louis,
> 
> A thousand blessing upon you.  I immediately commited it to the
> CVS!
> 

Oh, now I know why this problem looks so familiar. Way back when I was a grad student, I was trying to test some functions. And I ran into the problem about unittesting floating point. So I wrote unittest code to test floating point in SciPy. And it was added to SciPy. And the main Python language developers noticed (since those folks looked to the SciPy/Numpy folks about all things numerical computation related) and added it to the main language. And here I am, five years later, taking advantage of something I did as a grad student.

Add to reasons for "why contribute to open source programming" story.

Computer development platform Part 2

Last month I started working on a model development aspect of a project. And I figured I'd take the time to learn the use of a new toolkit for programming. An update.

I had a project meeting yesterday that went very well. The approach was sound. The work on the model that I've done already has uncovered issues that have not been addressed by prior work, and this is going to lead to major policy recommendations. All the things that a model developer hopes will happen.

In addition, discussion uncovered some details in the system being modeled that I did not realize (helps when multiple heads get together to tease details out). And we are talking deployment when all is said and done. So, I have a few issues:

1. The business logic of the model needs to be modified to handle my improved understanding of the process.
2. A number of additional scenarios need to be considered, preferably without breaking anything else.
3. The whole thing needs to be deployable. And that usually means MS Excel, a Visual Basic application, or Java (because these are things that can be sent to any computer without much trouble)

Number 3 leads to an additional complication. I've been developing the whole thing in Python, using Eclipse. I'm going to decide that for deployment, I will convert the whole thing to Jython, since that makes it deployable on a Java Virtual Machine (and everyone has Java installed). But Python is at version 2.5, while Jython is at version 2.2, so it is a couple years behind.

Well, this whole thing just screams out, unit testing. As it turns out, I've separated the building block objects from the business logic portions and the database access, which makes the whole thing easier. So, I build my test suite in PyUnit that takes the specifications and builds the model. Then the fun starts.

1. I was still working on the business logic that allocates resources. It was messy, but it did provide output. So I wrote test cases that tested discrete stages along the way and rewrote the logic into smaller functions.
2. Converting to Jython broke some functions, because newer versions of Python had some features that were not in Jython (some forms of introspection). So, I had to rewrite these so they worked under the older language specification, without breaking my test cases.
3. Next on the list, write test cases that implement some of the newly described scenarios, and make them work.

Some of this involved serious work. In particular, rewriting the code to version 2.2 vs. 2.5. Right before I did this, I did a commit to version control (Subversion) just in case I completely messed up. The IDE also helps alot since it takes care of version control, checking Python and Jython, and running the unit tests.

A very productive day. I almost think that I'm getting the hang of this programming stuff.