Fixing bugs in the release candidate

This week, I mostly worked on fixing bugs that people found in the release candidate I released last week. I discovered right after releasing it that it did not work in Python 2.4 or 2.5 because of a syntax error. So I fixed those and created SymPy 0.7.0.rc2 (source; windows installer).

Things were going pretty smoothly with that, until Renato Coutinho discovered that there were test failures in Python 2.4 on Windows, and that the tests failed if ran twice in the same session (i.e., by using test() in isympy). I was able to fix the failures resulting from two sessions, which were almost all caused by a test modifying some global value or being written in a way that did not allow it to pass when run twice. But I do not have a Windows machine, so I couldn’t reproduce the Windows failures.

Fortunately, yesterday, Renato, Chris Smith, and I were able to debug the problems over IRC. The main problem was that sympy/core/evalf.py had code

INF = 1e1000
MINUS_INF = -1e1000

These were intended to give float('inf') and float('-inf'), respectively (floating point infinity and negative infinity). And they did do this… on all platforms except for Python 2.4 on Windows. From what I can tell from what Chris told me, on that platform it instead gives 1.0. Strangely, float('inf') did not give floating point infinity either. We discovered that float(mpmath_inf) did give floating point infinity, where mpmath_inf is mpmath’s infinity. This of course also works in all other platforms, so changing it made the code work everywhere.

After that, there was only one test failure left in Windows (originally there were dozens of errors, but all but one were caused by the above problem). It turns out that the subprocess module from the codegen module was causing the test runner to fail entirely. Our solution was to skip this test completely in Python 2.4 on Windows.

So now we had all tests passing on all platforms with all ground types, even if run twice from within the same session.

But it turned out there was still one more error lurking, found by Renato. A bunch of mpmath tests failed in Python 2.4 when gmpy was installed. I had never gotten gmpy to compile, so I have only had it installed on my machine for those Python executables installed by fink (2.5-2.7, 64-bit).

It turns out that mpmath uses gmpy if it is installed. There were a few places in the code where it was doing things like line 1947 of mpmath/libmp/gammazeta.py, shown below:

return mpf_pos(small_factorial_cache[n-1], prec, rnd)

The problem was that n was an mpz, or gmpy integer. But Python 2.4 and ealier do not support non-int types as the index to lists. It wasn’t until Python 2.5′s __index__ method that non-int/long types were able to be used as slice indices.

This idiom was being used in several places throughout the code, so rather than try to patch them all, we decided to just disable the gmpy backend in mpmath for Python 2.4. This issue had never come up before to my knowledge, so it seems that he was the first person to run the mpmath tests in Python 2.4 with gmpy installed.

So now tests should be passing everywhere in the 0.7.0 branch. Please continue to test it, though. If it will make it easier to test, I will create a 0.7.0.rc3 with all the latest fixes. Otherwise, barring any further major fixes, I will release 0.7.0 final in about a week.

And a big thanks for Renato Coutinho and Chris Smith for helping me debug and fix these bugs.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 122 other followers

%d bloggers like this: