Re: [Numpy-discussion] ANN: NumPy 1.2.0
BTW, I can confirm that the latest official MKL does not work with numpy, as it is explained on the Intel forum (http://software.intel.com/en-us/forums/intel-math-kernel-library/topic/60460). I get the i_free not defined issue. For those who run into this issue, you have to use MKL 10.0.2 which does nto have the issue. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
I've tested the latest Numpy on a RHEL 4, and I got this result : Running unit tests for numpy NumPy version 1.2.0 NumPy is installed in /.../BRUCHER/local/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Sep 29 2008, 09:47:20) [GCC Intel(R) C++ gcc 3.4 mode] nose version 0.10.3 ...FFF.K.. ..ctypes is not available on this python: skipping the test (import error was: ctypes is not available.) .No distutils available, skipping test. . == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log10', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.30103+1.36437635j]), array([-0.30103+1.36437635j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log1p', -1.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) -- Ran 1726 tests in 7.533s FAILED (KNOWNFAIL=1, failures=3) nose.result.TextTestResult run=1726 errors=0 failures=3 So I have 3 failures that are unexpected. Matthieu 2008/9/26 Jarrod Millman [EMAIL PROTECTED]: I'm pleased to announce the release of NumPy 1.2.0. NumPy is the fundamental package needed for scientific computing with Python. It contains: * a powerful N-dimensional array object * sophisticated (broadcasting) functions * basic linear algebra functions * basic Fourier transforms * sophisticated random number capabilities * tools for integrating Fortran code. Besides it's obvious scientific uses, NumPy can also be used as an efficient multi-dimensional
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, 2008-09-29 at 10:00 +0200, Matthieu Brucher wrote: I've tested the latest Numpy on a RHEL 4, and I got this result : Hi Matthieu, Are you on 32 or 64 bits ? As you can see, those errors are test errors, not errors in the function themselves (tolerance too low; maybe influenced by compilers - maybe gcc 3 ? - , etc...). Any way, those seem harmless, cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
2008/9/29 David Cournapeau [EMAIL PROTECTED]: On Mon, 2008-09-29 at 10:00 +0200, Matthieu Brucher wrote: I've tested the latest Numpy on a RHEL 4, and I got this result : Hi Matthieu, Are you on 32 or 64 bits ? As you can see, those errors are test errors, not errors in the function themselves (tolerance too low; maybe influenced by compilers - maybe gcc 3 ? - , etc...). Any way, those seem harmless, cheers, David Hi, I compiled Python with a 64bits compiler (icc 10.1.018) as well as Numpy (that reminds me that I should link against the MKL as well). I know it's only tolerance errors, but they still show up ;) Matthieu -- French PhD student Information System Engineer Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, 2008-09-29 at 10:21 +0200, Matthieu Brucher wrote: Hi, I compiled Python with a 64bits compiler (icc 10.1.018) as well as Numpy (that reminds me that I should link against the MKL as well). I know it's only tolerance errors, but they still show up ;) Did you compile with the -fast option ? Because this flag is not harmless with numpy in my experience (same for sunsstudio; in the later, numpy crashes quite quickly, actually). I don't know if this is a bug in numpy or in the compilers. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
2008/9/29 David Cournapeau [EMAIL PROTECTED]: On Mon, 2008-09-29 at 10:21 +0200, Matthieu Brucher wrote: Hi, I compiled Python with a 64bits compiler (icc 10.1.018) as well as Numpy (that reminds me that I should link against the MKL as well). I know it's only tolerance errors, but they still show up ;) Did you compile with the -fast option ? Because this flag is not harmless with numpy in my experience (same for sunsstudio; in the later, numpy crashes quite quickly, actually). I don't know if this is a bug in numpy or in the compilers. No, I used -xW -axP because I don't have a Core 2 Duo computer (Opteron) Matthieu -- French PhD student Information System Engineer Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
Mon, 29 Sep 2008 17:19:10 +0900, David Cournapeau wrote: On Mon, 2008-09-29 at 10:00 +0200, Matthieu Brucher wrote: I've tested the latest Numpy on a RHEL 4, and I got this result : Hi Matthieu, Are you on 32 or 64 bits ? As you can see, those errors are test errors, not errors in the function themselves (tolerance too low; maybe influenced by compilers - maybe gcc 3 ? - , etc...). Any way, those seem harmless, I think the errors may imply that with your compiler, numpy gives np.log(-1 + 0j) -3.1415926535897931j or something similar wrong behavior at the branch cut of the logarithm, instead of np.log(-1 + 0j) 3.1415926535897931j np.log(-1 - 1e-99j) -3.1415926535897931j np.log(-1 + 1e-99j) 3.1415926535897931j I'd guess this is typically harmless, but may lead to problems if your code relies on the choice of branch at the branch cut. Could you check if this is really the case? If log seems to work OK, then it's a problem with the test and not the functions. The current implementation of complex log seemed to work on other platforms, but maybe icc has some features that break it in this respect. -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
np.log(-1 + 0j) 3.1415926535897931j np.log(-1 - 1e-99j) -3.1415926535897931j np.log(-1 + 1e-99j) 3.1415926535897931j I'd guess this is typically harmless, but may lead to problems if your code relies on the choice of branch at the branch cut. Could you check if this is really the case? If log seems to work OK, then it's a problem with the test and not the functions. The result is what you expected. BTW, I can confirm that the latest official MKL does not work with numpy, as it is explained on the Intel forum (http://software.intel.com/en-us/forums/intel-math-kernel-library/topic/60460). I get the i_free not defined issue. Matthieu -- French PhD student Information System Engineer Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
Mon, 29 Sep 2008 12:07:53 +0200, Matthieu Brucher wrote: np.log(-1 + 0j) 3.1415926535897931j np.log(-1 - 1e-99j) -3.1415926535897931j np.log(-1 + 1e-99j) 3.1415926535897931j I'd guess this is typically harmless, but may lead to problems if your code relies on the choice of branch at the branch cut. Could you check if this is really the case? If log seems to work OK, then it's a problem with the test and not the functions. The result is what you expected. Do you mean that the problem is with the test, or with the branch cut of log? -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
2008/9/29 Pauli Virtanen [EMAIL PROTECTED]: Mon, 29 Sep 2008 12:07:53 +0200, Matthieu Brucher wrote: np.log(-1 + 0j) 3.1415926535897931j np.log(-1 - 1e-99j) -3.1415926535897931j np.log(-1 + 1e-99j) 3.1415926535897931j I'd guess this is typically harmless, but may lead to problems if your code relies on the choice of branch at the branch cut. Could you check if this is really the case? If log seems to work OK, then it's a problem with the test and not the functions. The result is what you expected. Do you mean that the problem is with the test, or with the branch cut of log? I don't know, but the results are : np.log(-1 + 0j) 3.1415926535897931j np.log(-1 - 1e-99j) -3.1415926535897931j np.log(-1 + 1e-99j) 3.1415926535897931j Matthieu -- French PhD student Information System Engineer Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 2:00 AM, Matthieu Brucher [EMAIL PROTECTED] wrote: I've tested the latest Numpy on a RHEL 4, and I got this result : Running unit tests for numpy NumPy version 1.2.0 NumPy is installed in /.../BRUCHER/local/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Sep 29 2008, 09:47:20) [GCC Intel(R) C++ gcc 3.4 mode] nose version 0.10.3 ...FFF.K .. ..ctypes is not available on this python: skipping the test (import error was: ctypes is not available.) .No distutils available, skipping test. . == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log10', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.30103+1.36437635j]), array([-0.30103+1.36437635j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log1p', -1.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 12:05, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 2:00 AM, Matthieu Brucher [EMAIL PROTECTED] wrote: I've tested the latest Numpy on a RHEL 4, and I got this result : Running unit tests for numpy NumPy version 1.2.0 NumPy is installed in /.../BRUCHER/local/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Sep 29 2008, 09:47:20) [GCC Intel(R) C++ gcc 3.4 mode] nose version 0.10.3 ...FFF.K... ... ..ctypes is not available on this python: skipping the test (import error was: ctypes is not available.) .No distutils available, skipping test. . == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log10', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.30103+1.36437635j]), array([-0.30103+1.36437635j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log1p', -1.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. These asserts are in tests. That is exactly where we are supposed to use them. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 11:09 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:05, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 2:00 AM, Matthieu Brucher [EMAIL PROTECTED] wrote: I've tested the latest Numpy on a RHEL 4, and I got this result : Running unit tests for numpy NumPy version 1.2.0 NumPy is installed in /.../BRUCHER/local/lib/python2.5/site-packages/numpy Python version 2.5.2 (r252:60911, Sep 29 2008, 09:47:20) [GCC Intel(R) C++ gcc 3.4 mode] nose version 0.10.3 ...FFF.K... ... ..ctypes is not available on this python: skipping the test (import error was: ctypes is not available.) .No distutils available, skipping test. . == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log10', -0.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.30103+1.36437635j]), array([-0.30103+1.36437635j])) == FAIL: test_umath.TestComplexFunctions.test_branch_cuts(ufunc 'log1p', -1.5, 1j, 1, -1, True) -- Traceback (most recent call last): File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/nose/case.py, line 182, in runTest self.test(*self.arg) File /data/pau112/INNO/BRUCHER/local/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 333, in _check_branch_cut assert np.all(np.absolute(y0.imag - ym.imag*im_sign) atol), (y0, ym) AssertionError: (array([-0.69314718+3.14159265j]), array([-0.69314718+3.14159265j])) Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. These asserts are in tests. That is exactly where we are supposed to use them. Wrong, asserts are for debugging, not for general tests. Using them will give incorrect results when running the tests. This tends to be a problem on windows platforms. It needs to be fixed. Chuck
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 11:14 AM, Pauli Virtanen [EMAIL PROTECTED] wrote: Mon, 29 Sep 2008 11:05:09 -0600, Charles R Harris wrote: [clip: assert in tests] Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. assert FOO is used in quite many of Numpy's test cases, and it appears Nose endorses using assert (and uses it in its own tests). Should we go ahead and change all assert FOO in Numpy's tests to something like 'self.failUnless'? I fixed the np.testing functions to use if (foo) : raise AssertionError(Da Bomb) That way no changes to exception catching are needed, but the error will still be raised when the -OO option is used. Strictly speaking, it isn't quite right, but so it goes... Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 12:23, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:14 AM, Pauli Virtanen [EMAIL PROTECTED] wrote: Mon, 29 Sep 2008 11:05:09 -0600, Charles R Harris wrote: [clip: assert in tests] Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. assert FOO is used in quite many of Numpy's test cases, and it appears Nose endorses using assert (and uses it in its own tests). Should we go ahead and change all assert FOO in Numpy's tests to something like 'self.failUnless'? I fixed the np.testing functions to use if (foo) : raise AssertionError(Da Bomb) That way no changes to exception catching are needed, but the error will still be raised when the -OO option is used. Strictly speaking, it isn't quite right, but so it goes... When is -OO ever used for running tests? The assert statement is used for tests under nose. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:23, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:14 AM, Pauli Virtanen [EMAIL PROTECTED] wrote: Mon, 29 Sep 2008 11:05:09 -0600, Charles R Harris wrote: [clip: assert in tests] Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. assert FOO is used in quite many of Numpy's test cases, and it appears Nose endorses using assert (and uses it in its own tests). Should we go ahead and change all assert FOO in Numpy's tests to something like 'self.failUnless'? I fixed the np.testing functions to use if (foo) : raise AssertionError(Da Bomb) That way no changes to exception catching are needed, but the error will still be raised when the -OO option is used. Strictly speaking, it isn't quite right, but so it goes... When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:23, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:14 AM, Pauli Virtanen [EMAIL PROTECTED] wrote: Mon, 29 Sep 2008 11:05:09 -0600, Charles R Harris wrote: [clip: assert in tests] Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. assert FOO is used in quite many of Numpy's test cases, and it appears Nose endorses using assert (and uses it in its own tests). Should we go ahead and change all assert FOO in Numpy's tests to something like 'self.failUnless'? I fixed the np.testing functions to use if (foo) : raise AssertionError(Da Bomb) That way no changes to exception catching are needed, but the error will still be raised when the -OO option is used. Strictly speaking, it isn't quite right, but so it goes... When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:23, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:14 AM, Pauli Virtanen [EMAIL PROTECTED] wrote: Mon, 29 Sep 2008 11:05:09 -0600, Charles R Harris wrote: [clip: assert in tests] Using assert for this sort of thing is a bug, assert goes away with the -OO options. This needs to be fixed. assert FOO is used in quite many of Numpy's test cases, and it appears Nose endorses using assert (and uses it in its own tests). Should we go ahead and change all assert FOO in Numpy's tests to something like 'self.failUnless'? I fixed the np.testing functions to use if (foo) : raise AssertionError(Da Bomb) That way no changes to exception catching are needed, but the error will still be raised when the -OO option is used. Strictly speaking, it isn't quite right, but so it goes... When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
Mon, 29 Sep 2008 11:40:26 -0600, Charles R Harris wrote: [clip] Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. Perhaps the Nose author would have input on this? At least Nose seems to be the place where any warnings saying that tests won't work with -OO should go. -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 11:50 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. Asserts are transparent. If they go away, programs containing asserts should still run correctly. It's like bounds checking in array references, say in the std::vector class. If compiled with -DNODEBUG, the programs still run. Programs shouldn't use asserts for non-debugging purposes, they should raise real exceptions. If you think the numpy tests are essentially debugging tests, then they should all disappear when run with the -OO option, i.e., nose should do nothing. If nose wants to make that change, that is fine with me. But as is, incorrect failures may be reported and that is an error. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 13:07, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:50 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. Asserts are transparent. If they go away, programs containing asserts should still run correctly. It's like bounds checking in array references, say in the std::vector class. If compiled with -DNODEBUG, the programs still run. Programs shouldn't use asserts for non-debugging purposes, they should raise real exceptions. If you think the numpy tests are essentially debugging tests, then they should all disappear when run with the -OO option, i.e., nose should do nothing. If nose wants to make that change, that is fine with me. But as is, incorrect failures may be reported and that is an error. What failures? -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 12:17 PM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 13:07, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:50 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. Asserts are transparent. If they go away, programs containing asserts should still run correctly. It's like bounds checking in array references, say in the std::vector class. If compiled with -DNODEBUG, the programs still run. Programs shouldn't use asserts for non-debugging purposes, they should raise real exceptions. If you think the numpy tests are essentially debugging tests, then they should all disappear when run with the -OO option, i.e., nose should do nothing. If nose wants to make that change, that is fine with me. But as is, incorrect failures may be reported and that is an error. What failures? Read the ticket. And if a test incorrectly passes, that is also an error. Wrong is wrong, programming ain't philosophy. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 13:22, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:17 PM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 13:07, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:50 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. Asserts are transparent. If they go away, programs containing asserts should still run correctly. It's like bounds checking in array references, say in the std::vector class. If compiled with -DNODEBUG, the programs still run. Programs shouldn't use asserts for non-debugging purposes, they should raise real exceptions. If you think the numpy tests are essentially debugging tests, then they should all disappear when run with the -OO option, i.e., nose should do nothing. If nose wants to make that change, that is fine with me. But as is, incorrect failures may be reported and that is an error. What failures? Read the ticket. And if a test incorrectly passes, that is also an error. Wrong is wrong, programming ain't philosophy. And practicality beats purity. Just don't run the damn tests with -OO. Yes, it's an abuse of the assert statement which was intended for inline debugging inside production code. Unit tests are not production code. They don't have the same constraints or requirements. In particular, unit tests written for the nose framework use (and are encouraged to use) assert statements. Deal with it. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
A Monday 29 September 2008, Charles R Harris escrigué: On Mon, Sep 29, 2008 at 11:50 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. Asserts are transparent. If they go away, programs containing asserts should still run correctly. It's like bounds checking in array references, say in the std::vector class. If compiled with -DNODEBUG, the programs still run. Programs shouldn't use asserts for non-debugging purposes, they should raise real exceptions. If you think the numpy tests are essentially debugging tests, then they should all disappear when run with the -OO option, i.e., nose should do nothing. If nose wants to make that change, that is fine with me. But as is, incorrect failures may be reported and that is an error. Plain assert clauses used to be the most common way to check for test units in the original unittest module. Later on, the authors started to introduce things like self.assert_() and family and warned that the use of the assert clause should be avoided (maybe thinking about possible changes in semantics inside Python itself, maybe thinking about the use of -OO). But I agree with Robert Kern that tests *should* never be run under -OO because they are *tests*, not production code, and using the -OO for running the test units is simply a wrong practice. However, in the long term it should be useful to get rid of all the plain asserts in the test suite. My two cents, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 12:32 PM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 13:22, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:17 PM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 13:07, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:50 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. Asserts are transparent. If they go away, programs containing asserts should still run correctly. It's like bounds checking in array references, say in the std::vector class. If compiled with -DNODEBUG, the programs still run. Programs shouldn't use asserts for non-debugging purposes, they should raise real exceptions. If you think the numpy tests are essentially debugging tests, then they should all disappear when run with the -OO option, i.e., nose should do nothing. If nose wants to make that change, that is fine with me. But as is, incorrect failures may be reported and that is an error. What failures? Read the ticket. And if a test incorrectly passes, that is also an error. Wrong is wrong, programming ain't philosophy. And practicality beats purity. Just don't run the damn tests with -OO. Yes, it's an abuse of the assert statement which was intended for inline debugging inside production code. Unit tests are not production code. They don't have the same constraints or requirements. In particular, unit tests written for the nose framework use (and are encouraged to use) assert statements. Deal with it. Knowingly writing incorrect public code when it is easy to do it right can't be justified. If nose has a bug in this regard, nose should be fixed. And I think the numpy unit tests *are* production code, they give us information on the behavior of the different platforms and compilers out there. And what if there are *real* errors that only show up if python is run with the -OO options? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 13:43, Francesc Alted [EMAIL PROTECTED] wrote: Plain assert clauses used to be the most common way to check for test units in the original unittest module. Later on, the authors started to introduce things like self.assert_() and family and warned that the use of the assert clause should be avoided (maybe thinking about possible changes in semantics inside Python itself, maybe thinking about the use of -OO). Mostly it was reporting, I think. With assertEquals(x,y), you get a nice message showing the values of x and y. This is obviated by nose, which can introspect to get the values. From the unittest documentation: These methods are used instead of the assert statement so the test runner can accumulate all test results and produce a report. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Mon, Sep 29, 2008 at 12:43 PM, Francesc Alted [EMAIL PROTECTED]wrote: A Monday 29 September 2008, Charles R Harris escrigué: On Mon, Sep 29, 2008 at 11:50 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:40, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:35 AM, Robert Kern [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:30, Charles R Harris [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:27 AM, Robert Kern [EMAIL PROTECTED] wrote: When is -OO ever used for running tests? The assert statement is used for tests under nose. When it is the default on windows platforms. There was a ticket.. I see #893, which talks about when -OO is used explicitly and when numpy is part of a py2exe application. This does not refer to any default configuration on Windows platforms. Let's put it this way, if the tests were consistent with assert then they couldn't be run with the -OO option. If they *can* be run with the -OO option then they had better run correctly. I'm afraid that I don't understand what you are referring to. Asserts are transparent. If they go away, programs containing asserts should still run correctly. It's like bounds checking in array references, say in the std::vector class. If compiled with -DNODEBUG, the programs still run. Programs shouldn't use asserts for non-debugging purposes, they should raise real exceptions. If you think the numpy tests are essentially debugging tests, then they should all disappear when run with the -OO option, i.e., nose should do nothing. If nose wants to make that change, that is fine with me. But as is, incorrect failures may be reported and that is an error. Plain assert clauses used to be the most common way to check for test units in the original unittest module. Later on, the authors started to introduce things like self.assert_() and family and warned that the use of the assert clause should be avoided (maybe thinking about possible changes in semantics inside Python itself, maybe thinking about the use of -OO). But I agree with Robert Kern that tests *should* never be run under -OO because they are *tests*, not production code, and using the -OO for running the test units is simply a wrong practice. What if someone abuses assert in production code, how are you going to catch that without using -OO? Assert abuse seems to be a common bug... Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
A Monday 29 September 2008, Robert Kern escrigué: On Mon, Sep 29, 2008 at 13:43, Francesc Alted [EMAIL PROTECTED] wrote: Plain assert clauses used to be the most common way to check for test units in the original unittest module. Later on, the authors started to introduce things like self.assert_() and family and warned that the use of the assert clause should be avoided (maybe thinking about possible changes in semantics inside Python itself, maybe thinking about the use of -OO). Mostly it was reporting, I think. With assertEquals(x,y), you get a nice message showing the values of x and y. This is obviated by nose, which can introspect to get the values. From the unittest documentation: These methods are used instead of the assert statement so the test runner can accumulate all test results and produce a report. Maybe. At any rate, getting rid of plain asserts in test units seems to be a good practice generally speaking. Cheers, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
David Cournapeau schrieb: Thomas Heller wrote: Well, the first question is: What does happen when I install the SSE3 version (or how it's called) on my machine, use py2exe to build an app, and this app runs on a SSE2 machine - degraded performance, or hard crashes? Hard crash. That's the whole point of the installer, actually: install the right version. The problem is two fold: - it is practically impossible to force ATLAS to configure itself to use an instruction set different than the one used to build ATLAS. - we don't have a system to dynamically load the right ATLAS when importing numpy. Note that this is not new: you had the problem before, because before, numpy was *only* built with SSE2 support, and any machine wo SSE2 would crash when using numpy. I see. So, maybe the gui could allow to select whether to install the high-performance version specialized for the current cpu, or a more portable but a little bit slower version (I assume there is one included) that can be safely used for py2exe. Is it really complicated to decompress the .exe to get the installers and choose the one you want ? I am reluctant to add a GUI option because nsis is primitive, and adding gui is no fun (I use it only because it is open source and has a plug-in system; the scripting language to build the binary is awful). Also, the nsis installer itself has no GUI on purpose, to avoid confusing people with a two stages installer. No, it isn't complicated. I searched a little about command line options, and didn't find any. But 7-zip did unpack the installers. I can live with that. -- Thanks, Thomas ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
Thomas Heller wrote: No, it isn't complicated. I searched a little about command line options, and didn't find any. But 7-zip did unpack the installers. I can live with that. I will look into adding a command line switch. I don't want to add a GUI, but adding some command line switches for advanced uses and scripting makes a lot of sense, without risks of disrupting the whole install experience. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] ANN: NumPy 1.2.0
I'm pleased to announce the release of NumPy 1.2.0. NumPy is the fundamental package needed for scientific computing with Python. It contains: * a powerful N-dimensional array object * sophisticated (broadcasting) functions * basic linear algebra functions * basic Fourier transforms * sophisticated random number capabilities * tools for integrating Fortran code. Besides it's obvious scientific uses, NumPy can also be used as an efficient multi-dimensional container of generic data. Arbitrary data-types can be defined. This allows NumPy to seamlessly and speedily integrate with a wide-variety of databases. This minor release comes almost four months after the 1.1.0 release. The major features of this release are a new testing framework and huge amount of documentation work. It also includes a some minor API breakage scheduled in the 1.1 release. Please note that NumPy 1.2.0 requires Python 2.4 or greater. For information, please see the release notes: http://sourceforge.net/project/shownotes.php?group_id=1369release_id=628858 You can download the release from here: http://sourceforge.net/project/showfiles.php?group_id=1369package_id=175103 Thank you to everybody who contributed to this release. Enjoy, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
Jarrod Millman wrote: For information, please see the release notes: http://sourceforge.net/project/shownotes.php?group_id=1369release_id=628858 You can download the release from here: http://sourceforge.net/project/showfiles.php?group_id=1369package_id=175103 Note that updated packages for various linux distributions (Fedora, Centos/RHEL, OpenSuse) are available: http://download.opensuse.org/repositories/home:/ashigabou/ Please consider using this before building your own if you are not confortable with building numpy and more importantly blas/lapack from sources, thanks, David P.S Some repositories are broken (Fedora 9, etc... the packages are not built, so there is no chance of breaking anything); I unfortunately can't fix them ATM, but I will as soon as the issues preventing me from fixing it will be solved. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
Thomas Heller wrote: I see that the windows installer is now a superkac installer, which AFAIU selects the 'right' components for the target computer at install time. Yes, it is the case since 1.1.0. It is not ideal, but it effectively solved a common problem of people not having the right architecture (AFAICS, the support emails on that point drop from several /months to 0). If I now build applications using numpy with py2exe for distribution, what will happen on the target computers if the components are not 'right' for the actual machine type? Note that the superpack is actually quite primitive: it is a nsis installer which encompasses actual installers built with bdist_wininst, the nsis being used only to detect CPU arch automatically. So if you need the installers as before, you can just ask nsis to extract all three installers I believe, from the command line. If it is a problem, or if we can make it easier for you, please tell us. I am the one who did this scheme, and I do not use py2exe (or windows for that matter), so I would be happy to solve the problems if you tell me how :) cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.2.0
On Fri, Sep 26, 2008 at 12:24 PM, Thomas Heller [EMAIL PROTECTED] wrote: [Thomas] If I now build applications using numpy with py2exe for distribution, what will happen on the target computers if the components are not 'right' for the actual machine type? [David] Note that the superpack is actually quite primitive: it is a nsis installer which encompasses actual installers built with bdist_wininst, the nsis being used only to detect CPU arch automatically. So if you need the installers as before, you can just ask nsis to extract all three installers I believe, from the command line. If it is a problem, or if we can make it easier for you, please tell us. I am the one who did this scheme, and I do not use py2exe (or windows for that matter), so I would be happy to solve the problems if you tell me how :) Well, the first question is: What does happen when I install the SSE3 version (or how it's called) on my machine, use py2exe to build an app, and this app runs on a SSE2 machine - degraded performance, or hard crashes? I could probably live with the least performance, but not with the crashes ;-). Probably hard crashes. So, maybe the gui could allow to select whether to install the high-performance version specialized for the current cpu, or a more portable but a little bit slower version (I assume there is one included) that can be safely used for py2exe. Compiling without Atlas would probably be the safest. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
