test failures in Sympy 0.7.0 rc2

[Renato Coutinho]

Hello,

I just tested the new rc. In linux 64-bits using tox, all tests pass
with python and gmpy ground types.

In Windows XP, all tests pass with python 2.5-2.7. With python2.4 I
get a lot of errors, and the test suite doesn't even finish. I
uploaded the output to https://gist.github.com/1026644. I'm not sure
if it's worthwhile to pursue all those errors though.

I also noticed that caching introduces some errors. In python2.7 in
linux, if I run sympy.test() twice in the same session, I get the
errors below. Fortunately, none of the failures look too dangerous,
but it shows caching does have some colateral effects.

Renato

_____________ sympy/core/tests/test_numbers.py:test_integers_cache _____________
File "/home/renato/down/sympy-0.7.0.rc2/sympy/core/tests/test_numbers.py",
line 14, in test_integers_cache
value += 1
UnboundLocalError: local variable 'value' referenced before assignment

________________________________________________________________________________
_________ sympy/assumptions/tests/test_query.py:test_key_extensibility _________
File "/home/renato/down/sympy-0.7.0.rc2/sympy/assumptions/tests/test_query.py",
line 976, in test_key_extensibility
raises(AttributeError, "ask(Q.my_key(x))")
File "sympy/utilities/pytest.py", line 49, in raises
raise AssertionError("DID NOT RAISE")
AssertionError: DID NOT RAISE
________________________________________________________________________________
__________ sympy/core/tests/test_numbers.py:test_conversion_to_mpmath __________
File "/home/renato/down/sympy-0.7.0.rc2/sympy/core/tests/test_numbers.py",
line 703, in test_conversion_to_mpmath
assert mpmath.mpmathify(Float('1.23')) == mpmath.mpf('1.23')
AssertionError
________________________________________________________________________________
_________________ sympy/core/tests/test_symbol.py:test_symbols _________________
File "/home/renato/down/sympy-0.7.0.rc2/sympy/core/tests/test_symbol.py",
line 123, in test_symbols
raises(DeprecationWarning, "symbols('xyz', each_char=True)")
File "sympy/utilities/pytest.py", line 49, in raises
raise AssertionError("DID NOT RAISE")
AssertionError: DID NOT RAISE
________________________________________________________________________________
______________ sympy/geometry/tests/test_geometry.py:test_polygon ______________
File "/home/renato/down/sympy-0.7.0.rc2/sympy/geometry/tests/test_geometry.py",
line 593, in test_polygon
raises(UserWarning, "p1.distance(p2)")
File "sympy/utilities/pytest.py", line 49, in raises
raise AssertionError("DID NOT RAISE")
AssertionError: DID NOT RAISE

[Aaron Meurer]

Hi.

Thanks for reporting this. I think I can fix the bugs you give below,
but I don't think I can fix the Windows bugs without some help, as I
don't have Windows and can't reproduce those on my Mac. Do you think
you could help me debug them? If possible, pull in the latest 0.7.0
branch on Windows, because I'll be pushing in fixes for the below
errors there soon.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>

[Aaron Meurer]

Regarding the last two, it seems that testing warnings is not as easy
as I though. To quote
http://docs.python.org/library/warnings.html?highlight=warnings:

"One thing to be aware of is that if a warning has already been raised
because of a once/default rule, then no matter what filters are set
the warning will not be seen again unless the warnings registry
related to the warning has been cleared."

I can't figure out how to actually reset this registry
(warnings.resetwarnings() does not do it). So I will XFAIL these
tests and create an issue for this.

Aaron Meurer

[Aaron Meurer]

The int cache test tests the integer cache, which is not the same
after a second execution (it tests that something is *not* in the
cache). See http://code.google.com/p/sympy/issues/detail?id=1946.

The mpmath test fails because test_lambdify.py sets mpmath.mp.dps,
which changes the precision globally. Is there a way to use a
different precision in that test without changing it globally?

Aaron Meurer

[Tom Bachmann]

On 15.06.2011 20:08, Aaron Meurer wrote:
> The int cache test tests the integer cache, which is not the same
> after a second execution (it tests that something is *not* in the
> cache). See http://code.google.com/p/sympy/issues/detail?id=1946.
>
> The mpmath test fails because test_lambdify.py sets mpmath.mp.dps,
> which changes the precision globally. Is there a way to use a
> different precision in that test without changing it globally?
>

Isn't the common idiom to do

oldprec = mpmath.dps
mpmath.dps = ...
...
mpmath.dps = oldprec

[Mateusz Paprocki]

Hi,

On 15 June 2011 21:11, Tom Bachmann <e_m...@web.de> wrote:

On 15.06.2011 20:08, Aaron Meurer wrote:

The int cache test tests the integer cache, which is not the same
after a second execution (it tests that something is *not* in the
cache).  See http://code.google.com/p/sympy/issues/detail?id=1946.

The mpmath test fails because test_lambdify.py sets mpmath.mp.dps,
which changes the precision globally.  Is there a way to use a
different precision in that test without changing it globally?

Isn't the common idiom to do

oldprec = mpmath.dps
mpmath.dps = ...
...
mpmath.dps = oldprec

The best way is to do:

dps = mpmath.dps

mpmath.dps = ...

try:

    ...

finally:

    mpmath.dps = dps

(until we will be able to use with statement in the library).

Mateusz

[Aaron Meurer]

The problem is that I'll have to do this within each test function
that uses this. I'll use this idiom for now, but a cleaner one would
be better.

Aaron Meurer

[Mateusz Paprocki]

Hi,

On 15 June 2011 15:53, Aaron Meurer <asme...@gmail.com> wrote:

The problem is that I'll have to do this within each test function
that uses this.  I'll use this idiom for now, but a cleaner one would
be better.

Maybe lets add a decorator that will wrap test code in try: finally: block and restore dps automatically?

Mateusz

[Aaron Meurer]

I have no idea how to do that. For now, I've just put in the try
blocks manually. We can add this to the TODO for issue 2493.

Aaron Meurer

[Aaron Meurer]

OK, I've fixed these problems. There is now one failure if you run
the test twice which is caused by the cache (if you turn it off, the
failure is fixed). There are also a ton of failures if you the whole
test suite with the cache turned off. But these are all nontrivial to
fix, and I don't consider them to be high priority for the release,
especially considering running the tests without the cache takes hours
because of the gruntz test. So I will open an issue for them.

However, I would like to be able to fix the Windows errors, if
possible. Can anyone who can reproduce them (Renato) help me to
debug/fix them?

Aaron Meurer

[Chris Smith]

I can help. How should we do this? Do I make corrections and make new pull requests or what.

[Aaron Meurer]

You can reproduce the problem!?

Right now, Renato and I are debugging it on IRC. If you could figure
out what's causing the problems, that would be great. If you have the
ability, could you join us on IRC right now? If you don't have a
working client, you can use http://webchat.freenode.net/.

So far, we've determined that the problems all seem to relate to
mpmath. See https://gist.github.com/1028555.

Aaron Meurer

On Wed, Jun 15, 2011 at 9:24 PM, Chris Smith <smi...@gmail.com> wrote:
> I can help. How should we do this? Do I make corrections and make new pull
> requests or what.
>

[Aaron Meurer]

So we managed to figure this out. There should be no more test
failures in Windows in the 0.7.0 branch. Big thanks to Renato
Coutinho and Chris Smith for helping me debug and fix these errors.

The main cause of the problems was that Python 2.4 in Windows did not
convert 1e1000 to float('inf') in evalf.py. In fact, it doesn't even
convert float('inf') to float('inf'). We ended up using
float(mpmath_inf).

It also turned out that the subprocess module causes problems in
Python 2.4 on Windows, so we had to skip the codegen tests completely
there.

Do people want me to create another release candidate? The 0.7.0
branch contains not only these fixes but also fixes for the problems
of running the tests twice in the same session that were reported in
this same thread. If having another release candidate will make it
easier for people to test the code, just let me know and I will make
one.

Otherwise, I will put all this in a final release in about a week,
barring any further problems.

Aaron Meurer

[Ondrej Certik]

On Wed, Jun 15, 2011 at 11:14 PM, Aaron Meurer <asme...@gmail.com> wrote:
> So we managed to figure this out.  There should be no more test
> failures in Windows in the 0.7.0 branch.  Big thanks to Renato
> Coutinho and Chris Smith for helping me debug and fix these errors.
>
> The main cause of the problems was that Python 2.4 in Windows did not
> convert 1e1000 to float('inf') in evalf.py.  In fact, it doesn't even
> convert float('inf') to float('inf').  We ended up using
> float(mpmath_inf).
>
> It also turned out that the subprocess module causes problems in
> Python 2.4 on Windows, so we had to skip the codegen tests completely
> there.
>
> Do people want me to create another release candidate?  The 0.7.0
> branch contains not only these fixes but also fixes for the problems
> of running the tests twice in the same session that were reported in
> this same thread.  If having another release candidate will make it
> easier for people to test the code, just let me know and I will make
> one.
>
> Otherwise, I will put all this in a final release in about a week,
> barring any further problems.

As to me, I would just release. If something still pops up, we can
make a new release, hopefully we'll do it more often from now on.
All tests run for me in the 0.7.0 branch. But you can of course
release another rc if you prefer.

In any case, many thanks for such an awesome job everyone!

Ondrej

[Aaron Meurer]

OK. By the way, I should note that anyone with the git version can
make a tarball or Windows executable by running the commands

./setup.py sdist
./setup.py bdist_wininst

respectively (this will build them in the dist directory).

Aaron Meurer