Mailman 3 July 2008 - NumPy-Discussion

Doctest items
by Alan McIntyre July 2, 2008

July 2, 2008

Just a few questions/comments about doctests: 1. Should all doctests be written such that you could start Python, do an "import numpy as np", and then type in the examples verbatim? There are a number that currently wouldn't work that way (they depend on the function under test being in the local namespace, for example). 2. In regard to the auto-ignore of "plt.", etc. in commands: using the existing ellipsis feature of doctest should cover a significant portion of the cases that the auto-ignore was suggested to solve, and it's a very minor change to enable it (whereas the auto-ignore is more involved). If nobody objects, I will enable ellipsis for all doctests (which doesn't cause any obvious problems in existing NumPy tests), and use it to clean up existing doctests where appropriate. If the auto-ignore capability is still needed after that, I'll work on it. 3. When the test suite is run with doctests enabled, some unit tests fail that normally wouldn't, and some doctests fail that shouldn't. There's probably some state that needs to be reset (or otherwise managed) between doctest runs; I'll look into that and provide a fix as soon as possible. I just figured I should mention it in case it causes somebody problems before it gets fixed. Thanks, Alan

7 21

New numpy.test() failures
by Nils Wagner July 2, 2008

July 2, 2008

Hi all, If I run numpy.test() >>> numpy.__version__ '1.2.0.dev5331' I obtain ====================================================================== FAIL: Tests count ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/numpy/ma/tests/test_core.py", line 566, in test_count_func assert_equal(3, count(ott)) File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 97, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: ACTUAL: 3 DESIRED: 4 ====================================================================== FAIL: Tests reshape ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/numpy/ma/tests/test_core.py", line 1461, in test_reshape assert_equal(y._mask.shape, (2,2,)) File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 94, in assert_equal return _assert_equal_on_sequences(actual, desired, err_msg='') File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 66, in _assert_equal_on_sequences assert_equal(len(actual),len(desired),err_msg) File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 97, in assert_equal assert desired == actual, msg AssertionError: Items are not equal: ACTUAL: 0 DESIRED: 2 ====================================================================== FAIL: Tests dot product ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/numpy/ma/tests/test_extras.py", line 223, in test_dot assert_equal(c.mask, [[1,1],[1,0]]) File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 111, in assert_equal return assert_array_equal(actual, desired, err_msg) File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 177, in assert_array_equal header='Arrays are not equal') File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 171, in assert_array_compare verbose=verbose, header=header) File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 240, in assert_array_compare assert cond, msg AssertionError: Arrays are not equal (mismatch 75.0%) x: array([[False, False], [False, False]], dtype=bool) y: array([[1, 1], [1, 0]]) ====================================================================== FAIL: Test of average. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/numpy/ma/tests/test_extras.py", line 35, in test_testAverage1 assert_equal(average(ott,axis=0), [2.0, 0.0]) File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 111, in assert_equal return assert_array_equal(actual, desired, err_msg) File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 177, in assert_array_equal header='Arrays are not equal') File "/usr/local/lib64/python2.5/site-packages/numpy/ma/testutils.py", line 171, in assert_array_compare verbose=verbose, header=header) File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 240, in assert_array_compare assert cond, msg AssertionError: Arrays are not equal (mismatch 50.0%) x: array([ 1., 1.]) y: array([ 2., 1.]) ====================================================================== FAIL: Test of average. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/numpy/ma/tests/test_old_ma.py", line 526, in test_testAverage1 self.failUnless(eq(average(ott,axis=0), [2.0, 0.0])) AssertionError ====================================================================== FAIL: Test count ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/numpy/ma/tests/test_old_ma.py", line 159, in test_xtestCount self.failUnless (eq(3, count(ott))) AssertionError ---------------------------------------------------------------------- Ran 1660 tests in 12.483s FAILED (failures=6) Nils

5 11

set_local_path in test files
by Alan McIntyre July 2, 2008

July 2, 2008

Some test files have a set_local_path()/restore_path() pair at the top, and some don't. Is there any reason to be changing sys.path like this in the test modules? If not, I'll take them out when I see them. Thanks, Alan

6 10

Change of behavior in flatten between 1.0.4 and 1.1
by Stuart Brorson July 2, 2008

July 2, 2008

Hi -- I have noticed a change in the behavior of numpy.flatten(True) between NumPy 1.0.4 and NumPy 1.1. The change affects 3D arrays. I am wondering if this is a bug or a feature. Here's the change. Note that the output from flatten(True) is different between 1.0.4 and 1.1. ======= First the preliminary set up: ======= In [3]: A = numpy.array([[[1, 2], [3, 4]], [[5, 6], [7, 8]], [[9, 10], [11, 12]]]) In [4]: A Out[4]: array([[[ 1, 2], [ 3, 4]], [[ 5, 6], [ 7, 8]], [[ 9, 10], [11, 12]]]) ======= Now the change: Numpy 1.0.4 ======= In [5]: A.flatten() Out[5]: array([ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]) In [6]: A.flatten(True) Out[6]: array([ 1, 5, 9, 2, 6, 10, 3, 7, 11, 4, 8, 12]) ======= Numpy 1.1 ======= In [4]: A.flatten() Out[4]: array([ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]) In [5]: A.flatten(True) Out[5]: array([ 1, 5, 9, 3, 7, 11, 2, 6, 10, 4, 8, 12]) Note that the output of A.flatten(True) is different. Is this a bug or a feature? Cheers, Stuart Brorson Interactive Supercomputing, inc. 135 Beaver Street | Waltham | MA | 02452 | USA http://www.interactivesupercomputing.com/

2 2

Time to fix ticket #390?
by Charles R Harris July 2, 2008

July 2, 2008

Questions about ticket #390<http://projects.scipy.org/scipy/numpy/ticket/390>: 1. Should we fix this for 1.2? 2. Is the attached patch the correct fix for this? Chuck

4 4

problem with NumPy test harness in 1.1.0?
by David Brown July 1, 2008

July 1, 2008

Hi, Our code depends on NumPy and we have been taking advantage of the NumPy test harness to create test scripts for new features as we develop them. As recently as version 1.1.0.dev5064 we had no problem running our tests from the directory in which they live, e.g.: python test_script.py .....<much output> . ---------------------------------------------------------------------- Ran 10 tests in 0.397s OK However, with the released version NumPy 1.1.0 none of our tests work any longer and instead we get this error message: Traceback (most recent call last): File "test_mfio.py", line 426, in <module> NumpyTest().run() File "/usr/local/lib/python2.5/site-packages/numpy/testing/ numpytest.py", line 655, in run testcase_pattern=options.testcase_pattern) File "/usr/local/lib/python2.5/site-packages/numpy/testing/ numpytest.py", line 575, in test level, verbosity) File "/usr/local/lib/python2.5/site-packages/numpy/testing/ numpytest.py", line 453, in _test_suite_from_all_tests importall(this_package) File "/usr/local/lib/python2.5/site-packages/numpy/testing/ numpytest.py", line 681, in importall for subpackage_name in os.listdir(package_dir): OSError: [Errno 2] No such file or directory: '' Looking through the archives I have found a reference to the same error at http://www.nabble.com/NumpyTest-problem-td17603890.html. However, this thread is focused on the use of NumpyTest for test scripts within the NumPy source tree and the suggestions do not seem to apply to our situation. My question is whether using NumpyTest for our own tests is considered to be a proper application of the test module. If not why not? If it is, is there some modification we can make to our tests to make them work with NumpyTest as it is now configured? Or is this possibly a bug in NumPyTest? Dave Brown PyNGL/PyNIO development team

3 5

More pending test framework changes (please give feedback)
by Alan McIntyre July 1, 2008

July 1, 2008

Hi all, I can commit any/all of the following changes as long as they are agreeable to everybody: 1. All doctests in NumPy will have the numpy module available in their execution context as "np". 2. Turn on the normalized whitespace option for all doctests. Having a doctest fail just because there's a space after your result seems like an unnecessary hassle for documenters. 3. Output will be ignored for each doctest expected output line that contains "#random". I figured this can serve both as an ignore flag and indication to the reader that the listed output may differ from what they see if they execute the associated command. So you would be able to do: >>> random.random() 0.1234567890 #random: output may differ on your system And have the example executed but not cause a failure. You could also use this to ignore the <SomeObject at 0x1234ABCD> output from plot methods as well. If these get committed, I'll also revert doctests I changed earlier so that they use the provided "np" instead of importing it, and fix any currently failing doctests that can be addressed with the new behavior. I've already got a batch of these changes made locally just to try out the new features, but I'll wait to see if adding the features causes any troubles on the buildbots first. There are a couple of options that I haven't got patches for yet: 4. Doctest commands starting with "plt." or "plot." will automatically have their output ignored. 5. Add a decorator that causes all doctest output for that function/method's docstring to be ignored. (This is for cases with many examples, all of which should be executed but not compared, so you don't have to clutter up each output line with #random or ellipsis) If there is still a big need for these, I'll work on them. As an alternative to 3,4 and 5, you could use the ELLIPSIS directive to ignore the varying bits of the output, but you'd still have to put the directive on each command line where you needed it. Unless I turn on the ellipsis feature for all doctests, that is; it's easy to do, and it doesn't cause me any obvious problems locally. I don't know whether that's something that's generally a good idea, though. Thanks, Alan

3 6

Coverage improvement requests
by Alan McIntyre July 1, 2008

July 1, 2008

Hi all, This week I'm going to start working on new tests to improve Python code coverage in NumPy (C code coverage will come later in the summer, or maybe even after GSoC). Does anyone have recommendations for particularly important bits of code that need coverage? If not, I'm just going to start on modules with the largest number of uncovered lines, and go from there. Thanks, Alan (Sorry for the flood of posts)

2 1

ANN: SfePy 00.46.02
by Robert Cimrman July 1, 2008

July 1, 2008

I am pleased announce the release of SfePy 00.46.02. SfePy is a finite element analysis software in Python, based primarily on Numpy and SciPy. Mailing lists, issue tracking, mercurial repository: http://sfepy.org Home page: http://sfepy.kme.zcu.cz Major improvements: - alternative short syntax for specifying essential boundary conditions, variables and regions - manufactured solutions tests: - SymPy support - site configuration now via script/config.py + site_cfg.py - new solvers - new terms For more information on this release, see http://sfepy.googlecode.com/svn/web/releases/004602_RELEASE_NOTES.txt If you happen to come to Leipzig for EuroSciPy 2008, see you there! Best regards, Robert Cimrman & SfePy developers

1 0