Mailman 3 January 2010 - NumPy-Discussion

Re: [Numpy-discussion] performance matrix multiplication vs. matlab
by Xue (Sue) Yang 06 Jan '10

06 Jan '10

Hi, I followed what I collected about installation of numpy with lapack and atlas and installed numpy on our desktop with RHEL4 and 4 cores. >uname -a Linux curie.physics.usyd.edu.au 2.6.9-89.0.15.ELsmp #1 SMP Sat Oct 10 05:59:16 EDT 2009 i686 i686 i386 GNU/Linux I successfully installed lapack-3.1.1, atlas3.8.0 with fortran comfiler: gfortran, and numpy-1.3.0 with enthought-python distribution (python2.5). > python >>import numpy >>a = numpy.random.randn(6000, 6000) >>numpy.dot(a, a) Surprisingly, it only uses 2 cores instead of 4 cores. Where and how should I set up the number of threads for numpy? Thanks! Dr. Xue (Sue) Yang School of Physics, University of Sydney Ph: 02 9351 6081 Email: x.yang(a)physics.usyd.edu.au

2 1

Lots of 32bits specific errors
by Xavier Gnata 06 Jan '10

06 Jan '10

Hi, I have compiled numpy 1.5.0.dev8039 both on a 32 and a 64bits ubuntu machine. On the 64bits one, everything is fine: numpy.test get a perfect score: <nose.result.TextTestResult run=2504 errors=0 failures=0> On the 32bits ubuntu, the story is not that nice: <nose.result.TextTestResult run=2504 errors=1 failures=16> ERROR: Test filled w/ mvoid ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/ma/tests/test_core.py", line 506, in test_filled_w_mvoid a = mvoid(np.array((1, 2)), mask=[(0, 1)], dtype=ndtype) File "/usr/local/lib/python2.6/dist-packages/numpy/ma/core.py", line 5454, in __new__ _data = ndarray.__new__(self, (), dtype=dtype, buffer=data.data) TypeError: buffer is too small for requested array ====================================================================== FAIL: test_cdouble (test_linalg.TestCond2) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 44, in test_cdouble self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 114, in do old_assert_almost_equal(s[0]/s[-1], linalg.cond(a,2), decimal=5) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 455, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: 9.4348091510413177 DESIRED: 22.757141876814547 ====================================================================== FAIL: test_csingle (test_linalg.TestCond2) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 39, in test_csingle self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 114, in do old_assert_almost_equal(s[0]/s[-1], linalg.cond(a,2), decimal=5) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 455, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: 9.4348097 DESIRED: 22.757143 ====================================================================== FAIL: test_cdouble (test_linalg.TestDet) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 44, in test_cdouble self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 135, in do assert_almost_equal(d, multiply.reduce(ev)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: (8.8817841970012523e-16-4j) DESIRED: (5.2800000000000011-11.040000000000004j) ====================================================================== FAIL: test_csingle (test_linalg.TestDet) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 39, in test_csingle self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 135, in do assert_almost_equal(d, multiply.reduce(ev)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: (8.8817841970012523e-16-4j) DESIRED: (5.2800000000000011-11.040000000000004j) ====================================================================== FAIL: test_cdouble (test_linalg.TestEig) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 44, in test_cdouble self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 94, in do assert_almost_equal(dot(a, evectors), multiply(evectors, evalues)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([[ 2.72530404+2.67511327j, 1.92238375+1.30131653j], [ 5.95809316+4.79684551j, 3.41362547+1.42587017j]]) DESIRED: array([[ 2.01388405+1.03693361j, -1.39512658+1.87085135j], [ 1.78601662+0.01838201j, -0.10408816-3.54121552j]]) ====================================================================== FAIL: test_csingle (test_linalg.TestEig) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 39, in test_csingle self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 94, in do assert_almost_equal(dot(a, evectors), multiply(evectors, evalues)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([[ 2.72530413+2.6751132j , 1.92238379+1.3013165j ], [ 5.95809317+4.79684544j, 3.41362548+1.42587018j]], dtype=complex64) DESIRED: array([[ 2.01388407+1.03693354j, -1.39512670+1.8708514j ], [ 1.78601658+0.01838197j, -0.10408816-3.54121566j]], dtype=complex64) ====================================================================== FAIL: test_cdouble (test_linalg.TestEigh) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 221, in test_cdouble self.do(a) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 259, in do assert_almost_equal(ev, evalues) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([-2.60555128, 4.60555128]) DESIRED: array([-1.71080202-1.00413682j, 3.01849433+1.46567528j]) ====================================================================== FAIL: test_csingle (test_linalg.TestEigh) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 217, in test_csingle self.do(a) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 259, in do assert_almost_equal(ev, evalues) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([-2.60555124, 4.60555124], dtype=float32) DESIRED: array([-1.71080208-1.0041368j , 3.01849437+1.46567523j], dtype=complex64) ====================================================================== FAIL: test_cdouble (test_linalg.TestEigvalsh) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 221, in test_cdouble self.do(a) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 249, in do assert_almost_equal(ev, evalues) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([-2.60555128+0.j, 4.60555128+0.j]) DESIRED: array([-1.71080202-1.00413682j, 3.01849433+1.46567528j]) ====================================================================== FAIL: test_csingle (test_linalg.TestEigvalsh) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 217, in test_csingle self.do(a) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 249, in do assert_almost_equal(ev, evalues) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([-2.60555124+0.j, 4.60555124+0.j], dtype=complex64) DESIRED: array([-1.71080208-1.0041368j , 3.01849437+1.46567523j], dtype=complex64) ====================================================================== FAIL: test_cdouble (test_linalg.TestLstsq) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 44, in test_cdouble self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 141, in do assert_almost_equal(b, dot(a, x)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([ 2.+1.j, 1.+2.j]) DESIRED: array([ 0.95920929+0.98311952j, 1.23494444+0.67346351j]) ====================================================================== FAIL: test_csingle (test_linalg.TestLstsq) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 39, in test_csingle self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 141, in do assert_almost_equal(b, dot(a, x)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([ 2.+1.j, 1.+2.j], dtype=complex64) DESIRED: array([ 0.95920926+0.98311943j, 1.23494434+0.67346334j], dtype=complex64) ====================================================================== FAIL: test_cdouble (test_linalg.TestPinv) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 44, in test_cdouble self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 124, in do assert_almost_equal(dot(a, a_ginv), identity(asarray(a).shape[0])) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([[ 0.29169056-0.07799046j, 0.17767375-0.01332484j], [ 0.04125021-0.38255608j, 0.73402869+0.62377356j]]) DESIRED: array([[ 1., 0.], [ 0., 1.]]) ====================================================================== FAIL: test_csingle (test_linalg.TestPinv) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 39, in test_csingle self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 124, in do assert_almost_equal(dot(a, a_ginv), identity(asarray(a).shape[0])) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([[ 0.29169053-0.07799049j, 0.17767370-0.0133248j ], [ 0.04125014-0.38255614j, 0.73402858+0.62377363j]], dtype=complex64) DESIRED: array([[ 1., 0.], [ 0., 1.]]) ====================================================================== FAIL: test_cdouble (test_linalg.TestSVD) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 44, in test_cdouble self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 100, in do assert_almost_equal(a, dot(multiply(u, s), vt)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([[ 1.+2.j, 2.+3.j], [ 3.+4.j, 4.+5.j]]) DESIRED: array([[ 1.00000000+2.j , 2.36670415+2.98574489j], [ 3.00000000+4.j , 2.80882652+6.25521741j]]) ====================================================================== FAIL: test_csingle (test_linalg.TestSVD) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 39, in test_csingle self.do(a, b) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 100, in do assert_almost_equal(a, dot(multiply(u, s), vt)) File "/usr/local/lib/python2.6/dist-packages/numpy/linalg/tests/test_linalg.py", line 23, in assert_almost_equal old_assert_almost_equal(a, b, decimal=decimal, **kw) File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py", line 435, in assert_almost_equal raise AssertionError(msg) AssertionError: Arrays are not almost equal ACTUAL: array([[ 1.+2.j, 2.+3.j], [ 3.+4.j, 4.+5.j]], dtype=complex64) DESIRED: array([[ 0.99999994+2.j , 2.36670423+2.98574495j], [ 3.00000000+4.j , 2.80882668+6.25521755j]], dtype=complex64) Xavier

2 3

finishing ticket #1035
by Charles R Harris 05 Jan '10

05 Jan '10

Hi All, I'm looking at ticket #1025<http://projects.scipy.org/numpy/ticket/1035#comment:4>with an eye to bringing it to completion but there some issues that need discussion. Currently there are three ways in which nans can be compared: maximum/minimum, fmax/fmin, or the new sort order. The maximum/minimum ufuncs propagate nans, i.e., they will always return a nan if one is present. The fmax/fmin ufuncs don't propagate nans, they ignore nans when possible. The new sort order sorts nans to the end, i.e., nans are treated as larger than any non-nan number; at present there are no ufuncs that correspond to the sort order. The issues I think need resolving are: 1) Should there be ufuncs corresponding to the sort order? 2) What should a.max(), a.argmax(), a.min(), and a.argmin() do? I note that a.argmax() is not consistent with a.max() at the moment: In [9]: a Out[9]: array([ 0., 1., 2., 3., NaN, 5., 6., 7., NaN, NaN]) In [10]: a.argmax() Out[10]: 7 In [11]: a.max() Out[11]: nan Thoughts? Chuck

1 0

Announcing toydist, improving distribution and packaging situation
by David Cournapeau 04 Jan '10

04 Jan '10

(warning, long post) Hi there, As some of you already know, the packaging and distributions of scientific python packages have been a constant source of frustration. Open source is about making it easy for anyone to use software how they see fit, and I think python packaging infrastructure has not been very successfull for people not intimately familiar with python. A few weeks ago, after Guido visited Berkeley and was told how those issues were still there for the scientific community, he wrote an email asking whether current efforts on distutils-sig will be enough (see http://aspn.activestate.com/ASPN/Mail/Message/distutils-sig/3775972). Several of us have been participating to this discussion, but I feel like the divide between current efforts on distutils-sig and us (the SciPy community) is not getting smaller. At best, their efforts will be more work for us to track the new distribute fork, and more likely, it will be all for nothing as it won't solve any deep issue. To be honest, most of what is considered on distutils-sig sounds like anti-goals to me. Instead of keeping up with the frustrating process of "improving" distutils, I think we have enough smart people and manpower in the scientific community to go with our own solution. I am convinced it is doable because R or haskell, with a much smaller community than python, managed to pull out something with is miles ahead compared to pypi. The SciPy community is hopefully big enough so that a SciPy-specific solution may reach critical mass. Ideally, I wish we had something with the following capabilities: - easy to understand tools - http-based package repository ala CRAN, which would be easy to mirror and backup (through rsync-like tools) - decoupling the building, packaging and distribution of code and data - reliable install/uninstall/query of what is installed locally - facilities for building windows/max os x binaries - making the life of OS vendors (Linux, *BSD, etc...) easier The packaging part ============== Speaking is easy, so I started coding part of this toolset, called toydist (temporary name), which I presented at Scipy India a few days ago: http://github.com/cournape/toydist/ Toydist is more or less a rip off of cabal (http://www.haskell.org/cabal/), and consist of three parts: - a core which builds a package description from a declarative file similar to cabal files. The file is almost purely declarative, and can be parsed so that no arbitrary code is executed, thus making it easy to sandbox packages builds (e.g. on a build farm). - a set of command line tools to configure, build, install, build installers (egg only for now) etc... from the declarative file - backward compatibility tools: a tool to convert existing setup.py to the new format has been written, and a tool to use distutils through the new format for backward compatibility with complex distutils extensions should be relatively easy. The core idea is to make the format just rich enough to describe most packages out there, but simple enough so interfacing it with external tools is possible and reliable. As a regular contributor to scons, I am all too aware that a build tool is a very complex beast to get right, and repeating their efforts does not make sense. Typically, I envision that complex packages such as numpy, scipy or matplotlib would use make/waf/scons for the build - in a sense, toydist is written so that writing something like numscons would be easier. OTOH, most if not all scikits should be buildable from a purely declarative file. To give you a feel of the format, here is a snippet for the grin package from Robert K. (automatically converted): Name: grin Version: 1.1.1 Summary: A grep program configured the way I like it. Description: ==== grin ==== I wrote grin to help me search directories full of source code. The venerable GNU grep_ and find_ are great tools, but they fall just a little short for my normal use cases. <snip> License: BSD Platforms: UNKNOWN Classifiers: License :: OSI Approved :: BSD License, Development Status :: 5 - Production/Stable, Environment :: Console, Intended Audience :: Developers, Operating System :: OS Independent, Programming Language :: Python, Topic :: Utilities, ExtraSourceFiles: README.txt, setup.cfg, setup.py, Library: InstallDepends: argparse, Modules: grin, Executable: grin module: grin function: grin_main Executable: grind module: grin function: grind_main Although still very much experimental at this point, toydist already makes some things much easier than with distutils/setuptools: - path customization for any target can be done easily: you can easily add an option in the file so that configure --mynewdir=value works and is accessible at every step. - making packages FHS compliant is not a PITA anymore, and the scheme can be adapted to any OS, be it traditional FHS-like unix, mac os x, windows, etc... - All the options are accessible at every step (no more distutils commands nonsense) - data files can finally be handled correctly and consistently, instead of the 5 or 6 magics methods currently available in distutils/setuptools/numpy.distutils - building eggs does not involve setuptools anymore - not much coupling between package description and build infrastructure (building extensions is actually done through distutils ATM). Repository ======== The goal here is to have something like CRAN (http://cran.r-project.org/web/views/), ideally with a build farm so that whenever anyone submits a package to our repository, it would automatically be checked, and built for windows/mac os x and maybe a few major linux distributions. One could investigate the build service from open suse to that end (http://en.opensuse.org/Build_Service), which is based on xen VM to build installers in a reproducible way. Installed package db =============== I believe that the current open source enstaller package from Enthought can be a good starting point. It is based on eggs, but eggs are only used as a distribution format (eggs are never installed as eggs AFAIK). You can easily remove packages, query installed versions, etc... Since toydist produces eggs, interoperation between toydist and enstaller should not be too difficult. What's next ? ========== At this point, I would like to ask for help and comments, in particular: - Does all this make sense, or hopelessly intractable ? - Besides the points I have mentioned, what else do you think is needed ? - There has already been some work for the scikits webportal, but I think we should bypass pypi entirely (the current philosophy of not enforcing consistent metadata does not make much sense to me, and is at the opposite of most other similar system out there). - I think a build farm for at least windows packages would be a killer feature, and enough incentive to push some people to use our new infrastructure. It would be good to have a windows guy familiar with windows sandboxing/virtualization to do something there. The people working on the opensuse build service have started working on windows support - I think being able to automatically convert most of scientific packages is a significant feature, and needs to be more robust - so anyone is welcomed to try converting existing setup.py with toydist (see toydist readme). thanks, David

11 42

Re: [Numpy-discussion] [matplotlib-devel] [SciPy-dev] Announcing toydist, improving distribution and packaging situation
by David Cournapeau 03 Jan '10

03 Jan '10

On Sun, Jan 3, 2010 at 3:27 AM, Andrew Straw <strawman(a)astraw.com> wrote: >> > Typically, the dependencies only depend on the smallest subset of what > they require (if they don't need lapack, they'd only depend on > python-numpy-core in your example), but yes, if there's an unsatisfiable > condition, then apt-get will raise an error and abort. In practice, this > system seems to work quite well, IMO. Yes, but: - debian dependency resolution is complex. I think many people don't realize how complex the problem really is (AFAIK, any correct scheme to resolve dependencies in debian requires an algorithm which is NP-complete ) - introducing a lot of variants significantly slow down the whole thing. I think it worths thinking whether our problems warrant such a complexity. > > Anyhow, here's the full Debian documentation: > http://www.debian.org/doc/debian-policy/ch-relationships.html This is not the part I am afraid of. This is: http://people.debian.org/~dburrows/model.pdf cheers, David

1 0

ANN: upfirdn 0.2.0
by Tom K. 02 Jan '10

02 Jan '10

ANNOUNCEMENT I am pleased to announce a new release of "upfirdn" - version 0.2.0. This package provides an efficient polyphase FIR resampler object (SWIG-ed C++) and some python wrappers. This release greatly improves installation with distutils relative to the initial 0.1.0 release. 0.2.0 includes no functional changes relative to 0.1.0. Also, the source code is now browse-able online through a Google Code site with mercurial repository. https://opensource.motorola.com/sf/projects/upfirdn http://code.google.com/p/upfirdn/ Thanks to Google for providing this hosting service! -- View this message in context: http://old.nabble.com/ANN%3A-upfirdn-0.2.0-tp26996309p26996309.html Sent from the Numpy-discussion mailing list archive at Nabble.com.

1 0

calculating the difference of an array
by Manuel Wittchen 02 Jan '10

02 Jan '10

Hi, I want to calculate the difference between the values of a numpy-array. The formula is: deltaT = t_(n+1) - t_(n) My approach to calculate the difference looks like this: for i in len(ARRAY): delta_t[i] = ARRAY[(i+1):] - ARRAY[:(len(ARRAY)-1)] print "result:", delta_t But I get a TypeError: File "./test.py", line 19, in <module> for i in len(ARRAY): TypeError: 'int' object is not iterable Where is the mistake in the code? Regards and a happy new year, Manuel Wittchen

3 3

Re: [Numpy-discussion] Announcing toydist, improving distribution and packaging situation
by Pierre Raybaut 02 Jan '10

02 Jan '10

Hi David, Following your announcement for the 'toydist' module, I think that your project is very promising: this is certainly a great idea and it will be very controversial but that's because people expectactions are great on this matter (distutils is so disappointing indeed). Anyway, if I may be useful, I'll gladly contribute to it. In time, I could change the whole Python(x,y) packaging system (which is currently quite ugly... but easy/quick to manage/maintain) to use/promote this new module. Happy New Year! and Long Live Scientific Python! ;-) Cheers, Pierre

2 2

is it safe to change the dtype without rebuilding the array?
by Ernest Adrogué 01 Jan '10

01 Jan '10

Hi, I find myself doing this: In [244]: x Out[244]: array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) In [245]: y=x.copy() In [251]: y.dtype.char Out[251]: 'l' In [252]: dt=np.dtype([('a','l'),('b','l'),('c','l')]) In [254]: y.dtype=dt Is it okay? The problem is that it's not easy to rebuild the array. I tried with: y.astype(dt) np.array(y, dt) np.array(y.tolist(), dt) None worked. Bye. Ernest

2 1

arrays and __eq__
by Keith Goodman 01 Jan '10

01 Jan '10

I have a class that stores some of its data in a numpy array. I can check for equality when myclass is on the left and an array is on the right: >> m = myclass([1,2,3]) >> a = np.asarray([9,2,3]) >> >> m == a myclass([False, True, True], dtype=bool) But I get the wrong answer when an array is on the left and myclass is on the right: >> a == m array([ True, True, True], dtype=bool) import numpy as np class myclass(object): def __init__(self, arr): self.arr = np.asarray(arr) def __eq__(self, other): if np.isscalar(other) or isinstance(other, np.ndarray): x = myclass(self.arr.copy()) x.arr = x.arr == other else: raise TypeError, 'This example just tests numpy arrays and scalars.' return x def __repr__(self): return 'myclass' + repr(self.arr).split('array')[1] I've run into a similar problem with __radd__ but the solution to that problem doesn't work for __eq__: http://www.mail-archive.com/numpy-discussion@scipy.org/msg09476.html

1 0