Mailman 3 March 2006 - NumPy-Discussion

Tests fail in svn r2195
by Sasha 05 Mar '06

05 Mar '06

Reproduced on Linux with python 2.4 and on MacOS X with python 2.3. ====================================================================== ERROR: Check creation from tuples ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 151, in check_tuple h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ====================================================================== ERROR: Check creation from tuples ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 151, in check_tuple h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ====================================================================== ERROR: Check reading the top fields of a nested array ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 244, in check_access_top_fields h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ====================================================================== ERROR: Check reading the nested fields of a nested array (1st level) ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 262, in check_nested1_acessors h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ====================================================================== ERROR: Check access nested descriptors of a nested array (1st level) ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 310, in check_nested1_descriptor h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ====================================================================== ERROR: Check reading the nested fields of a nested array (2nd level) ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 292, in check_nested2_acessors h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ====================================================================== ERROR: Check access nested descriptors of a nested array (2nd level) ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 318, in check_nested2_descriptor h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ====================================================================== ERROR: check_access_fields (numpy.core.tests.test_numerictypes.test_read_values_plain_single) ---------------------------------------------------------------------- Traceback (most recent call last): File "/bnv/sandbox/numpy-dev/lib/python2.4/site-packages/numpy/core/tests/test_numerictypes.py", line 210, in check_access_fields h = array(self._buffer, dtype=self._descr) TypeError: expected a readable buffer object ---------------------------------------------------------------------- Ran 337 tests in 1.131s FAILED (errors=8)

1 0

Fw: numpy-discussion
by pfpntdfhcz 05 Mar '06

05 Mar '06

----- Original Message ----- From: Bass Aileen To: sgnptwk(a)southtrust.com Sent: Saturday, March 4, 2006 8:21 AM Subject: numpy-discussion

1 0

Re: [SciPy-dev] [Numpy-discussion] Re: numpy.linalg prevents use of scipy.linalg?
by Ed Schofield 04 Mar '06

04 Mar '06

Robert Kern wrote: > Zachary Pincus wrote: > >>> What version of scipy are you using? Before reporting a bug, please >>> make sure it >>> exists in the current SVN revision. >>> >> Sorry I didn't include the version (0.4.6, by the way) in my first >> email. My oversight. >> >> As to your latter statement, are you sure about that? You're only >> interested in getting bug reports from people who rebuild scipy from >> the svn every night, or who have tracked down the problem to the line >> so they know where in the svn to see if it's fixed? >> > > No, I don't expect everyone to rebuild scipy every day. However, when you think > you've found a bug, it is standard procedure for you to build the most recent > version to test it and see if the bug is still there. So yes, I do expect people > to build from SVN when they're about to report a bug, but no more often. > I don't expect this. I think a bug report against the latest released version is better than no bug report. If we think we've seen and fixed the bug in SVN, it takes us less time to reply "Hmmm, check this with the latest SVN" than it would take Zachary or another would-be bug reporter to check out and build the whole tree from SVN, just on the off-chance we've fixed it since then. This lowers the barrier to entry for helpers. Reading bug reports about the current released version can also be a helpful reminder to us of which bugs are still outstanding in the most recent release. -- Ed

3 2

[Fwd: [Fwd: Re: [Numpy-discussion] Numpy and PEP 343]]
by Tim Hochberg 04 Mar '06

04 Mar '06

Check this out: Expression: where(0.1*a > arctan2(a, b), 2*a, arctan2(a,b)) numpy: 0.706635284652 Skipping weave timing numexpr: 0.19127785794 Speed-up of numexpr over numpy: 3.69428689898 270% speed up! Pretty cool. Unfortunately, my implementation of two and three argument functions is still buggy if one of the arguments is a constant. I'm not sure what the best tactic is to deal with that. My strategy for dealing with opcodes that require more than three arguments (just 'where' at present) was to just use two opcode blocks. The second opcode block had the opcode OP_NOOP (which does nothing), but the first opcode steals arguments from it. It's pretty simple and more or less infinitely expandable. I'm off to bed now, perhaps the answer to the constant dilemma will be clear in the morning. [next morning] OK, I know how to fix it, I just need to scrape together a few minutes to do it. -tim

1 0

[Fwd: Re: [Numpy-discussion] Numpy and PEP 343]
by Tim Hochberg 04 Mar '06

04 Mar '06

Check this out: Expression: where(0.1*a > arctan2(a, b), 2*a, arctan2(a,b)) numpy: 0.706635284652 Skipping weave timing numexpr: 0.19127785794 Speed-up of numexpr over numpy: 3.69428689898 270% speed up! Pretty cool. Unfortunately, my implementation of two and three argument functions is still buggy if one of the arguments is a constant. I'm not sure what the best tactic is to deal with that. My strategy for dealing with opcodes that require more than three arguments (just 'where' at present) was to just use two opcode blocks. The second opcode block had the opcode OP_NOOP (which does nothing), but the first opcode steals arguments from it. It's pretty simple and more or less infinitely expandable. I'm off to bed now, perhaps the answer to the constant dilemma will be clear in the morning. [next morning] OK, I know how to fix it, I just need to scrape together a few minutes to do it. -tim

1 0

numpy.linalg prevents use of scipy.linalg?
by Zachary Pincus 03 Mar '06

03 Mar '06

Hi folks, I can't seem to use any of the functions in scipy.linalg because numpy defines its own linalg which shadows that of scipy! Specifically, scipy.linalg defines 'norm' (in linalg/basic.py), and numpy doesn't. (This among other differences, I assume.) In [1]: import scipy In [2]: scipy.linalg.norm AttributeError: 'module' object has no attribute 'norm' In [3]: scipy.linalg.__file__ Out[3]: '[...]/python2.4/site-packages/numpy/linalg/__init__.pyc' ^^^^^^^ Now, look what happens when we import scipy.linalg directly: In [1]: import scipy.linalg In [2]: scipy.linalg.norm Out[2]: <function norm at 0x14261f0> In [3]: scipy.linalg.__file__ Out[3]: '[...]/python2.4/site-packages/scipy/linalg/__init__.pyc' ^^^^^^^ Something needs to be done to fix this -- but what? Scipy historically imports * from numpy. Scipy historically has a linalg module. The new thing is that numpy has a linalg module, too, which is loaded by default into the numpy namespace. (Compared to Numeric's LinearAlgebra module.) The only thing I can think of is to fold all of scipy.linalg into numpy.linalg, and remove the former. This provides for backwards compatibility for everyone, but perhaps a bit of work. Zach

2 1

The idiom for supporting matrices and arrays in a function
by Bill Baxter 03 Mar '06

03 Mar '06

The NumPy for Matlab Users's wiki is currently pleading to have someone fill in "*the idiom for supporting both matrices and arrays in a function". *Does anyone know what this is? My guess is it depends first off on whether your goal is - to treat everything as a matrix, but also accept 2D arrays and do the conversion to matrix internally (asmatrix()) - to treat everything as a general array, but also accept matrices as a special case of 2D array, converting to arrays I guess it's likely that you'd also like to make it so the type returned is the same as the type input. Is there some slick way to do that? It doesn't seem to me that the latter case should really be specific to matrix/array since matrix is just one particular subclass of array. Is this what those UFuncs are for? Is there some way to write functions that will accept any object that supports the "array protocal"? This comment about the idiom for matrix/array functions is the last major wart remaining on that wiki page, so I'd like to wipe it out. --bb

5 7

Matlab page on scipy wiki
by Bill Baxter 03 Mar '06

03 Mar '06

I added some content to the "NumPy/SciPy for Matlab users" page on the scipy wiki. But my knowledge of NumPy/SciPy isn't sufficient to fill in the whole chart of equivalents that I laid out. If folks who know both could browse by and maybe fill in a blank or two, that would be great. I think this will be a helpful "getting started" page for newbies to NumPy coming from matlab, like me. One of the most frustrating things is when you sit down and can't figure out how to do the most basic things that do in your sleep in another environment (like making a column vector). So hopefully this page will help. The URL is : http://www.scipy.org/Wiki/NumPy_for_Matlab_Addicts Thanks, Bill Baxter

17 39

Truth values of arrays:
by Tim Hochberg 03 Mar '06

03 Mar '06

I'm not a fan of the following behaviour, which I just noticed: >>> a = arange(1); b = arange(1) >>> cmp(a,b) 0 >>> not (a == b) False My feeling is that only shape-() arrays should be usable as truth values. Allowing size-1 arrays to be compared as well is just adding a weird, not particularly useful, corner case that's going to bite someone eventually. -tim

2 2

Re: [Numpy-discussion] Re: problems installing numpy on AIX
by mfmorss＠aep.com 03 Mar '06

03 Mar '06

Well, thank you Travis, that was most exceedingly helpful! With that, numpy installs, and python imports it without complaint. Next: SciPy. Mark F. Morss Principal Analyst, Market Risk American Electric Power Travis Oliphant <oliphant.travis@ ieee.org> To mfmorss(a)aep.com 03/03/2006 11:37 cc AM Subject Re: [Numpy-discussion] Re: problems installing numpy on AIX mfmorss(a)aep.com wrote: > (See attached file: Numpy_install.txt) > > Try changing the line 371 in numerictypes.py to _unicodesize = array('u','U1').itemsize and see what that produces... -Travis

1 0