Re: [Numpy-discussion] ANN: NumPy 1.6.2 release candidate 1
All tests for 1.6.2rc1 pass on Mac OS X 10.7.3 python 2.7.2 gcc 4.2 (Apple) Great! Paul On 6. mai 2012, at 00:12, Charles R Harris wrote: On Sat, May 5, 2012 at 2:56 PM, Paul Anton Letnes paul.anton.let...@gmail.com wrote: Hi, I'm getting a couple of errors when testing. System: Arch Linux (updated today) Python 3.2.3 gcc 4.7.0 (Anything else?) I think that this error: AssertionError: selectedrealkind(19): expected -1 but got 16 is due to the fact that newer versions of gfortran actually supports precision this high (quad precision). Yes, but it should be fixed. I can't duplicate this here with a fresh checkout of the branch. snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quaternion data type
On Sat, May 5, 2012 at 9:43 PM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 1:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 11:55 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft aldcr...@head.cfa.harvard.edu wrote: On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell ischn...@enthought.com wrote: Hi Chuck, thanks for the prompt reply. I as curious because because someone was interested in adding http://pypi.python.org/pypi/Quaternion to EPD, but Martin and Mark's implementation of quaternions looks much better. Hi - I'm a co-author of the above mentioned Quaternion package. I agree the numpy_quaternion version would be better, but if there is no expectation that it will move forward I can offer to improve our Quaternion. A few months ago I played around with making it accept arbitrary array inputs (with similar shape of course) to essentially vectorize the transformations. We never got around to putting this in a release because of a perceived lack of interest / priorities... If this would be useful then let me know. Would you be interested in carrying Martin's package forward? I'm not opposed to having quaternions in numpy/scipy but there needs to be someone to push it and deal with problems if they come up. Martin's package disappeared in large part because Martin disappeared. I'd also like to hear from Mark about other aspects, as there was also a simple rational user type proposed that we were looking to put in as an extension 'test' type. IIRC, there were some needed fixes to Numpy, some of which were postponed in favor of larger changes. User types is one of the things we want ot get fixed up. I kind of like the idea of there being a package, separate from numpy, which collects these dtypes together. To start, the quaternion and the rational type could go in it, and eventually I think it would be nice to move datetime64 there as well. Maybe it could be called numpy-dtypes, or would a more creative name be better? I'm trying to think about how that would be organized. We could create a new repository, numpy-user-types (numpy-extension-types), under the numpy umbrella. It would need documents and such as well as someone interested in maintaining it and making releases. A branch in the numpy repository wouldn't work since we would want to rebase it regularly. It could maybe go in scipy but a new package would need to be created there and it feels too distant from numpy for such basic types as datetime. Do you have thoughts about the details? Another repository under the numpy umbrella would best fit what I'm imagining, yes. I would imagine it as a package of additional types that aren't the core ones, but that many people would probably want to install. It would also be a way to continually exercise the type extension system, to make sure it doesn't break. It couldn't be a branch of numpy, rather a collection of additional dtypes and associated useful functions. I would be in favor of this as well. We could start the repository by having one trivial dtype that would serve as an example. That's something I have been interested in, I can lock a couple of hours / week to help this with. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Extension types repository
On Sun, May 6, 2012 at 5:44 AM, Travis Oliphant tra...@continuum.io wrote: +1 Travis -- Travis Oliphant (on a mobile) 512-826-7480 On May 5, 2012, at 10:19 PM, Charles R Harris charlesr.har...@gmail.com wrote: All, Tom Aldcroft volunteered to bring quaternions into numpy. The proposal is to set up a separate repository under the numpy name on github, npydtypes or some such, and bring in Martin Ling's quaternion extension dtype as a start. Other extension types that would reside in the repository would be the simple rational type, and perhaps some specialized astronomical time types. So here is the proposal. +1 1. Make Tom a member of the numpy organization on github. Would need a new team to be set up too. Travis is the only one who can do that. Ralf 1. Set up an extension dtypes repository in github.com/numpy Other proposals for the name are welcome. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quaternion data type
On Sun, May 6, 2012 at 3:56 AM, David Cournapeau courn...@gmail.com wrote: On Sat, May 5, 2012 at 9:43 PM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 1:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 11:55 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft aldcr...@head.cfa.harvard.edu wrote: On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell ischn...@enthought.com wrote: Hi Chuck, thanks for the prompt reply. I as curious because because someone was interested in adding http://pypi.python.org/pypi/Quaternion to EPD, but Martin and Mark's implementation of quaternions looks much better. Hi - I'm a co-author of the above mentioned Quaternion package. I agree the numpy_quaternion version would be better, but if there is no expectation that it will move forward I can offer to improve our Quaternion. A few months ago I played around with making it accept arbitrary array inputs (with similar shape of course) to essentially vectorize the transformations. We never got around to putting this in a release because of a perceived lack of interest / priorities... If this would be useful then let me know. Would you be interested in carrying Martin's package forward? I'm not opposed to having quaternions in numpy/scipy but there needs to be someone to push it and deal with problems if they come up. Martin's package disappeared in large part because Martin disappeared. I'd also like to hear from Mark about other aspects, as there was also a simple rational user type proposed that we were looking to put in as an extension 'test' type. IIRC, there were some needed fixes to Numpy, some of which were postponed in favor of larger changes. User types is one of the things we want ot get fixed up. I kind of like the idea of there being a package, separate from numpy, which collects these dtypes together. To start, the quaternion and the rational type could go in it, and eventually I think it would be nice to move datetime64 there as well. Maybe it could be called numpy-dtypes, or would a more creative name be better? I'm trying to think about how that would be organized. We could create a new repository, numpy-user-types (numpy-extension-types), under the numpy umbrella. It would need documents and such as well as someone interested in maintaining it and making releases. A branch in the numpy repository wouldn't work since we would want to rebase it regularly. It could maybe go in scipy but a new package would need to be created there and it feels too distant from numpy for such basic types as datetime. Do you have thoughts about the details? Another repository under the numpy umbrella would best fit what I'm imagining, yes. I would imagine it as a package of additional types that aren't the core ones, but that many people would probably want to install. It would also be a way to continually exercise the type extension system, to make sure it doesn't break. It couldn't be a branch of numpy, rather a collection of additional dtypes and associated useful functions. I would be in favor of this as well. We could start the repository by having one trivial dtype that would serve as an example. That's something I have been interested in, I can lock a couple of hours / week to help this with. How about if I start by working on adding tests within numpy_quaternion, then this can be migrated into an extended dtypes package when it is set up. A nice trivial dtype example would be very useful, as I mentioned just last week our group was wondering how to make a new dtype. - Tom ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Extension types repository
On Sun, May 6, 2012 at 2:38 AM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Sun, May 6, 2012 at 5:44 AM, Travis Oliphant tra...@continuum.iowrote: +1 Travis -- Travis Oliphant (on a mobile) 512-826-7480 On May 5, 2012, at 10:19 PM, Charles R Harris charlesr.har...@gmail.com wrote: All, Tom Aldcroft volunteered to bring quaternions into numpy. The proposal is to set up a separate repository under the numpy name on github, npydtypes or some such, and bring in Martin Ling's quaternion extension dtype as a start. Other extension types that would reside in the repository would be the simple rational type, and perhaps some specialized astronomical time types. So here is the proposal. +1 1. Make Tom a member of the numpy organization on github. Would need a new team to be set up too. Travis is the only one who can do that. Yes, looks like Travis needs to create the new repository and add at least one core team member, who can then add others. I'd suggest numpy-extension-dtypes for the repository name, Tom is on github as taldcroft. Travis, it might be a good idea to add one more person with ownership permissions as a backup if that is possible. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quaternion data type
On Sun, May 6, 2012 at 6:02 AM, Tom Aldcroft aldcr...@head.cfa.harvard.eduwrote: On Sun, May 6, 2012 at 3:56 AM, David Cournapeau courn...@gmail.com wrote: On Sat, May 5, 2012 at 9:43 PM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 1:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 11:55 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft aldcr...@head.cfa.harvard.edu wrote: On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell ischn...@enthought.com wrote: Hi Chuck, thanks for the prompt reply. I as curious because because someone was interested in adding http://pypi.python.org/pypi/Quaternion to EPD, but Martin and Mark's implementation of quaternions looks much better. Hi - I'm a co-author of the above mentioned Quaternion package. I agree the numpy_quaternion version would be better, but if there is no expectation that it will move forward I can offer to improve our Quaternion. A few months ago I played around with making it accept arbitrary array inputs (with similar shape of course) to essentially vectorize the transformations. We never got around to putting this in a release because of a perceived lack of interest / priorities... If this would be useful then let me know. Would you be interested in carrying Martin's package forward? I'm not opposed to having quaternions in numpy/scipy but there needs to be someone to push it and deal with problems if they come up. Martin's package disappeared in large part because Martin disappeared. I'd also like to hear from Mark about other aspects, as there was also a simple rational user type proposed that we were looking to put in as an extension 'test' type. IIRC, there were some needed fixes to Numpy, some of which were postponed in favor of larger changes. User types is one of the things we want ot get fixed up. I kind of like the idea of there being a package, separate from numpy, which collects these dtypes together. To start, the quaternion and the rational type could go in it, and eventually I think it would be nice to move datetime64 there as well. Maybe it could be called numpy-dtypes, or would a more creative name be better? I'm trying to think about how that would be organized. We could create a new repository, numpy-user-types (numpy-extension-types), under the numpy umbrella. It would need documents and such as well as someone interested in maintaining it and making releases. A branch in the numpy repository wouldn't work since we would want to rebase it regularly. It could maybe go in scipy but a new package would need to be created there and it feels too distant from numpy for such basic types as datetime. Do you have thoughts about the details? Another repository under the numpy umbrella would best fit what I'm imagining, yes. I would imagine it as a package of additional types that aren't the core ones, but that many people would probably want to install. It would also be a way to continually exercise the type extension system, to make sure it doesn't break. It couldn't be a branch of numpy, rather a collection of additional dtypes and associated useful functions. I would be in favor of this as well. We could start the repository by having one trivial dtype that would serve as an example. That's something I have been interested in, I can lock a couple of hours / week to help this with. How about if I start by working on adding tests within numpy_quaternion, then this can be migrated into an extended dtypes package when it is set up. Sounds like a good start. You might want to ping Martin too. A nice trivial dtype example would be very useful, as I mentioned just last week our group was wondering how to make a new dtype. There is the rational dtype https://github.com/girving/rational. I expect there will be some interaction between numpy and the extension types as the bugs are worked out. Extension types for numpy haven't been much used. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.6.2 release candidate 1
On Sat, May 5, 2012 at 8:15 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: I'm pleased to announce the availability of the first release candidate of NumPy 1.6.2. This is a maintenance release. Due to the delay of the NumPy 1.7.0, this release contains far more fixes than a regular NumPy bugfix release. It also includes a number of documentation and build improvements. Great! Sources and binary installers can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.6.2rc1/ Please test this release and report any issues on the numpy-discussion mailing list. i've just tested the debian package and it builds fine! The tests print some ResourceWarning with python3.2 but they all pass! Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] ANN Scikit-learn 0.11-beta
On behalf of our release manager, Andreas Mueller, and all the scikit-learn contributors, I am happy to announce the 0.11 beta. We are doing a quick beta and will hopefuly be releasing the final version tomorrow. The purpose of this beta is to get feedback on any release-critical bugs such as build issues. You can download the zip files of the beta on: https://github.com/scikit-learn/scikit-learn/zipball/0.11-beta You can also retrieve the latest code on https://github.com/scikit-learn/scikit-learn/zipball/master or using 'git clone g...@github.com:scikit-learn/scikit-learn.git' Any feedback is more than welcome, Cheers, Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] How to run NumPy's tests with coverage?
Hi, I'm trying to figure out how to run NumPy's tests with coverage enabled (i.e. numpy.test(coverage=True) ). I can run the tests successfully like this: $ git clone git://github.com/numpy/numpy.git [...] $ cd numpy/ $ python setup.py build_ext -i [...] $ cd .. # (avoid running from source directory) $ export PYTHONPATH=numpy/ $ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. python import numpy python numpy.test() Running unit tests for numpy NumPy version 1.7.0.dev-259fff8 NumPy is installed in [...]/numpy Python version 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] nose version 0.11.1 [...] Ran 3710 tests in 27.654s OK (KNOWNFAIL=3, SKIP=6) nose.result.TextTestResult run=3710 errors=0 failures=0 However, if I try to run the tests with coverage, I get lots of errors (and seven more tests are run than without coverage): python numpy.test(coverage=True) Running unit tests for numpy NumPy version 1.7.0.dev-259fff8 NumPy is installed in [...]/numpy Python version 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] nose version 0.11.1 Could not locate executable icc Could not locate executable ecc [...]/numpy/numarray/alter_code2.py:12: UserWarning: numpy.numarray.alter_code2 is not working yet. warnings.warn(numpy.numarray.alter_code2 is not working yet.) [...]/numpy/oldnumeric/alter_code2.py:26: UserWarning: numpy.oldnumeric.alter_code2 is not working yet. warnings.warn(numpy.oldnumeric.alter_code2 is not working yet.) [...] == ERROR: Failure: ImportError (No module named waflib.Configure) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/build_utils/waf.py, line 4, in module import waflib.Configure ImportError: No module named waflib.Configure == ERROR: Failure: ImportError (No module named numscons.numdist) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/core/scons_support.py, line 21, in module from numscons.numdist import process_c_str as process_str ImportError: No module named numscons.numdist == ERROR: Failure: ImportError (No module named numscons) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/core/setupscons.py, line 8, in module from numscons import get_scons_build_dir ImportError: No module named numscons == ERROR: test_multiarray.TestNewBufferProtocol.test_roundtrip -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/case.py, line 183, in runTest self.test(*self.arg) File [...]/numpy/core/tests/test_multiarray.py, line 2233, in test_roundtrip assert_raises(ValueError, self._check_roundtrip, x) File [...]/numpy/testing/utils.py, line 1053, in assert_raises return nose.tools.assert_raises(*args,**kwargs) File /usr/lib/python2.6/unittest.py, line 336, in failUnlessRaises callableObj(*args, **kwargs) File [...]/numpy/core/tests/test_multiarray.py, line 2167, in _check_roundtrip y = np.asarray(x) File [...]/numpy/core/tests/test_multiarray.py, line 2167, in _check_roundtrip y = np.asarray(x) File /usr/lib/python2.6/dist-packages/coverage.py, line 322, in t self.c[(f.f_code.co_filename, f.f_lineno)] = 1 RuntimeWarning: tp_compare didn't return -1 or -2 for exception
[Numpy-discussion] numpy_quaternion and gcc 4.1.2
I ran into a problem trying to build and import the numpy_quaternion extension on CentOS-5 x86_64: $ python setup.py build SNIP C compiler: gcc -pthread -fno-strict-aliasing -fPIC -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-I/data/cosmos2/ska/arch/x86_64-linux_CentOS-5/lib/python2.7/site-packages/numpy/core/include -I/data/cosmos2/ska/arch/x86_64-linux_CentOS-5/include/python2.7 -c' gcc: quaternion.c quaternion.c: In function \u2018quaternion_isfinite\u2019: quaternion.c:55: warning: implicit declaration of function \u2018isfinite\u2019 gcc: numpy_quaternion.c gcc -pthread -shared build/temp.linux-x86_64-2.7/quaternion.o build/temp.linux-x86_64-2.7/numpy_quaternion.o -o build/lib.linux-x86_64-2.7/quaternion/numpy_quaternion.so running scons There was a subsequent import error with numpy_quaternion.so: undefined symbol: isfinite. This problem does not occur for Ubuntu 11.10 and I presume it is due to CentOS-5 gcc (4.1.2) defaulting to -c89. I fixed this in setup.py by adding extra_compile_args['-std=c99'] to the add_extension() call. Is there a more general way in numpy to deal with issues like this? Thanks, Tom ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to run NumPy's tests with coverage?
On Sun, May 6, 2012 at 9:08 PM, Chris Ball ceb...@gmail.com wrote: Hi, I'm trying to figure out how to run NumPy's tests with coverage enabled (i.e. numpy.test(coverage=True) ). I can run the tests successfully like this: This seems to have been broken somewhere along the way. If you remove the argument --cover-inclusive from line 242 in numpy/testing/nosetester.py, that should fix all errors except TestNewBufferProtocol.test_roundtrip. Not sure what's going on with that one. Ralf $ git clone git://github.com/numpy/numpy.git [...] $ cd numpy/ $ python setup.py build_ext -i [...] $ cd .. # (avoid running from source directory) $ export PYTHONPATH=numpy/ $ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. python import numpy python numpy.test() Running unit tests for numpy NumPy version 1.7.0.dev-259fff8 NumPy is installed in [...]/numpy Python version 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] nose version 0.11.1 [...] Ran 3710 tests in 27.654s OK (KNOWNFAIL=3, SKIP=6) nose.result.TextTestResult run=3710 errors=0 failures=0 However, if I try to run the tests with coverage, I get lots of errors (and seven more tests are run than without coverage): python numpy.test(coverage=True) Running unit tests for numpy NumPy version 1.7.0.dev-259fff8 NumPy is installed in [...]/numpy Python version 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] nose version 0.11.1 Could not locate executable icc Could not locate executable ecc [...]/numpy/numarray/alter_code2.py:12: UserWarning: numpy.numarray.alter_code2 is not working yet. warnings.warn(numpy.numarray.alter_code2 is not working yet.) [...]/numpy/oldnumeric/alter_code2.py:26: UserWarning: numpy.oldnumeric.alter_code2 is not working yet. warnings.warn(numpy.oldnumeric.alter_code2 is not working yet.) [...] == ERROR: Failure: ImportError (No module named waflib.Configure) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/build_utils/waf.py, line 4, in module import waflib.Configure ImportError: No module named waflib.Configure == ERROR: Failure: ImportError (No module named numscons.numdist) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/core/scons_support.py, line 21, in module from numscons.numdist import process_c_str as process_str ImportError: No module named numscons.numdist == ERROR: Failure: ImportError (No module named numscons) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/core/setupscons.py, line 8, in module from numscons import get_scons_build_dir ImportError: No module named numscons == ERROR: test_multiarray.TestNewBufferProtocol.test_roundtrip -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/case.py, line 183, in runTest self.test(*self.arg) File [...]/numpy/core/tests/test_multiarray.py, line 2233, in test_roundtrip assert_raises(ValueError, self._check_roundtrip, x) File [...]/numpy/testing/utils.py, line 1053, in assert_raises return nose.tools.assert_raises(*args,**kwargs) File /usr/lib/python2.6/unittest.py, line 336, in failUnlessRaises callableObj(*args, **kwargs) File
Re: [Numpy-discussion] numpy_quaternion and gcc 4.1.2
On Sun, May 6, 2012 at 1:35 PM, Tom Aldcroft aldcr...@head.cfa.harvard.eduwrote: I ran into a problem trying to build and import the numpy_quaternion extension on CentOS-5 x86_64: $ python setup.py build SNIP C compiler: gcc -pthread -fno-strict-aliasing -fPIC -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-I/data/cosmos2/ska/arch/x86_64-linux_CentOS-5/lib/python2.7/site-packages/numpy/core/include -I/data/cosmos2/ska/arch/x86_64-linux_CentOS-5/include/python2.7 -c' gcc: quaternion.c quaternion.c: In function \u2018quaternion_isfinite\u2019: quaternion.c:55: warning: implicit declaration of function \u2018isfinite\u2019 gcc: numpy_quaternion.c gcc -pthread -shared build/temp.linux-x86_64-2.7/quaternion.o build/temp.linux-x86_64-2.7/numpy_quaternion.o -o build/lib.linux-x86_64-2.7/quaternion/numpy_quaternion.so running scons There was a subsequent import error with numpy_quaternion.so: undefined symbol: isfinite. This problem does not occur for Ubuntu 11.10 and I presume it is due to CentOS-5 gcc (4.1.2) defaulting to -c89. I fixed this in setup.py by adding extra_compile_args['-std=c99'] to the add_extension() call. Is there a more general way in numpy to deal with issues like this? You might take a look at core/include/numpy/npy_math.h, which I suspect goes with core/lib/libnpymath.a. Running nm on the latter, it looks like there are some extra symbols exported, but that is a bit to the side. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to run NumPy's tests with coverage?
On Sun, May 6, 2012 at 4:39 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, May 6, 2012 at 9:08 PM, Chris Ball ceb...@gmail.com wrote: Hi, I'm trying to figure out how to run NumPy's tests with coverage enabled (i.e. numpy.test(coverage=True) ). I can run the tests successfully like this: This seems to have been broken somewhere along the way. If you remove the argument --cover-inclusive from line 242 in numpy/testing/nosetester.py, that should fix all errors except TestNewBufferProtocol.test_roundtrip. Not sure what's going on with that one. removing --cover-inclusive helped me also with statsmodels, with it it ran all example scripts and got stuck several times, (permanently stuck in some multiprocessing example?) Now coverage=True worked for the first time. Is it possible to make this optional or remove it from numpy? from a beneficiary of the nice numpy testing support outside of numpy Thanks for the tip, Josef Ralf $ git clone git://github.com/numpy/numpy.git [...] $ cd numpy/ $ python setup.py build_ext -i [...] $ cd .. # (avoid running from source directory) $ export PYTHONPATH=numpy/ $ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. python import numpy python numpy.test() Running unit tests for numpy NumPy version 1.7.0.dev-259fff8 NumPy is installed in [...]/numpy Python version 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] nose version 0.11.1 [...] Ran 3710 tests in 27.654s OK (KNOWNFAIL=3, SKIP=6) nose.result.TextTestResult run=3710 errors=0 failures=0 However, if I try to run the tests with coverage, I get lots of errors (and seven more tests are run than without coverage): python numpy.test(coverage=True) Running unit tests for numpy NumPy version 1.7.0.dev-259fff8 NumPy is installed in [...]/numpy Python version 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] nose version 0.11.1 Could not locate executable icc Could not locate executable ecc [...]/numpy/numarray/alter_code2.py:12: UserWarning: numpy.numarray.alter_code2 is not working yet. warnings.warn(numpy.numarray.alter_code2 is not working yet.) [...]/numpy/oldnumeric/alter_code2.py:26: UserWarning: numpy.oldnumeric.alter_code2 is not working yet. warnings.warn(numpy.oldnumeric.alter_code2 is not working yet.) [...] == ERROR: Failure: ImportError (No module named waflib.Configure) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/build_utils/waf.py, line 4, in module import waflib.Configure ImportError: No module named waflib.Configure == ERROR: Failure: ImportError (No module named numscons.numdist) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/core/scons_support.py, line 21, in module from numscons.numdist import process_c_str as process_str ImportError: No module named numscons.numdist == ERROR: Failure: ImportError (No module named numscons) -- Traceback (most recent call last): File /usr/lib/pymodules/python2.6/nose/loader.py, line 379, in loadTestsFromName addr.filename, addr.module) File /usr/lib/pymodules/python2.6/nose/importer.py, line 39, in importFromPath return self.importFromDir(dir_path, fqname) File /usr/lib/pymodules/python2.6/nose/importer.py, line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File [...]/numpy/core/setupscons.py, line 8, in module from numscons import get_scons_build_dir ImportError: No module named numscons == ERROR: test_multiarray.TestNewBufferProtocol.test_roundtrip -- Traceback (most recent call last): File
Re: [Numpy-discussion] Quaternion data type
On May 6, 2012, at 12:16 PM, Charles R Harris wrote: On Sun, May 6, 2012 at 6:02 AM, Tom Aldcroft aldcr...@head.cfa.harvard.edu wrote: On Sun, May 6, 2012 at 3:56 AM, David Cournapeau courn...@gmail.com wrote: On Sat, May 5, 2012 at 9:43 PM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 1:06 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, May 5, 2012 at 11:55 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft aldcr...@head.cfa.harvard.edu wrote: On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell ischn...@enthought.com wrote: Hi Chuck, thanks for the prompt reply. I as curious because because someone was interested in adding http://pypi.python.org/pypi/Quaternion to EPD, but Martin and Mark's implementation of quaternions looks much better. Hi - I'm a co-author of the above mentioned Quaternion package. I agree the numpy_quaternion version would be better, but if there is no expectation that it will move forward I can offer to improve our Quaternion. A few months ago I played around with making it accept arbitrary array inputs (with similar shape of course) to essentially vectorize the transformations. We never got around to putting this in a release because of a perceived lack of interest / priorities... If this would be useful then let me know. Would you be interested in carrying Martin's package forward? I'm not opposed to having quaternions in numpy/scipy but there needs to be someone to push it and deal with problems if they come up. Martin's package disappeared in large part because Martin disappeared. I'd also like to hear from Mark about other aspects, as there was also a simple rational user type proposed that we were looking to put in as an extension 'test' type. IIRC, there were some needed fixes to Numpy, some of which were postponed in favor of larger changes. User types is one of the things we want ot get fixed up. I kind of like the idea of there being a package, separate from numpy, which collects these dtypes together. To start, the quaternion and the rational type could go in it, and eventually I think it would be nice to move datetime64 there as well. Maybe it could be called numpy-dtypes, or would a more creative name be better? I'm trying to think about how that would be organized. We could create a new repository, numpy-user-types (numpy-extension-types), under the numpy umbrella. It would need documents and such as well as someone interested in maintaining it and making releases. A branch in the numpy repository wouldn't work since we would want to rebase it regularly. It could maybe go in scipy but a new package would need to be created there and it feels too distant from numpy for such basic types as datetime. Do you have thoughts about the details? Another repository under the numpy umbrella would best fit what I'm imagining, yes. I would imagine it as a package of additional types that aren't the core ones, but that many people would probably want to install. It would also be a way to continually exercise the type extension system, to make sure it doesn't break. It couldn't be a branch of numpy, rather a collection of additional dtypes and associated useful functions. I would be in favor of this as well. We could start the repository by having one trivial dtype that would serve as an example. That's something I have been interested in, I can lock a couple of hours / week to help this with. How about if I start by working on adding tests within numpy_quaternion, then this can be migrated into an extended dtypes package when it is set up. Sounds like a good start. You might want to ping Martin too. A nice trivial dtype example would be very useful, as I mentioned just last week our group was wondering how to make a new dtype. There is the rational dtype. I expect there will be some interaction between numpy and the extension types as the bugs are worked out. Extension types for numpy haven't been much used. Actually, they have been used fairly extensively in multiple projects that I am aware of. They have just not been discussed enough, nor is there a good open-source collection of extension dtypes. It is also harder than it really should be to create extension dtypes. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
