Mailman 3 June 2008 - NumPy-Discussion

Infinity definitions
by Bruce Southey July 16, 2008

July 16, 2008

Hi, Since we are discussing namespace and standardization, I am curious in why there are multiple definitions for defining infinity in numpy when perhaps there should be two (one for positive infinity and one for negative infinity). I really do understand that other people have use of these definitions and that it is easier to leave them in than take them out. Also, it is minor reduction in namespace because I do know that much of the namespace is either defining variables (like different floats and complex numbers) or mathematical functions (like logs and trig functions). Currently we have: numpy.Inf numpy.Infinity numpy.inf numpy.infty numpy.NINF numpy.PINF Most of these are defined in numeric.py: 'Inf = inf = infty = Infinity = PINF' In the f2py/tests subdirectories, the files return_real.py and return_complex.py uses both 'inf','Infinity'. The only occurrence of NINF and PINF are in core/src/umathmodule.c but I don't see any other usage. There does not seem to be any use of 'infty'. A similar case could be made for 'Not a Number' (nan = NaN = NAN). Regards Bruce

7 9

Detecting phase windings
by gruben＠bigpond.net.au July 9, 2008

July 9, 2008

I have a speed problem with the approach I'm using to detect phase wrappings in a 3D data set. In my application, phaseField is a 3D array containing the phase values of a field. In order to detect the vortices/phase windings at each point, I check for windings on each of 3 faces of a 2x2 cube with the following code: def HasVortex(cube): ''' cube is a 2x2x2 array containing the phase values returns True if any of 3 orthogonal faces contains a phase wrapping ''' # extract 3 cube faces - flatten to make indexing easier c1 = cube[0,:,:].flatten() c3 = cube[:,0,:].flatten() c5 = cube[:,:,0].flatten() # now order the phases in a circuit around each face, finishing in the same corner as we began # Use numpy's phase unwrapping code, which has a default threshold of pi u1 = unwrap(c1[cwi]) u3 = unwrap(c3[cwi]) u5 = unwrap(c5[cwi]) # check whether the final unwrapped value coincides with the value in the cell we started at return not allclose(r_[u1[0],u3[0],u5[0]], r_[u1[4],u3[4],u5[4]]) vortexArray = array([int(HasVortex(phaseField[x:x+2,y:y+2,z:z+2])) for x in range(phaseField.shape[0]-1) for y in range(phaseField.shape[1]-1) for z in range(phaseField.shape[2]-1)]\ ).reshape((xs-1,ys-1,zs-1)) Whilst this does what I want, it's incredibly slow. I'm wondering whether anyone has done this before, or can think of a better approach. My thoughts about a better approach are to stack the values along 3 new dimensions making a 6D array and use unwrap along the 3 new dimensions. Something like the following may give you an idea of what I mean, but it's a toy example trying to extend 2D into 3D, rather than 3D into 6D, because I haven't come to grips with enough of numpy's axis reshaping and stacking tricks to avoid getting a severe headache when trying to generalize it: a = array([[1.,3.], [6.,5.]]) b = np.dstack((a, roll(a,-1,axis=1), roll(roll(a,-1,axis=0),-1,axis=1), roll(a,-1,axis=0), a)) print np.unwrap(b, axis=2) A problem with this approach is that the memory requirements for the stacked version will be much greater, so some version using views would be preferable. Any ideas? Gary Ruben

3 3

Running doctests on buildbots
by Alan McIntyre July 4, 2008

July 4, 2008

Hi all, It seems to me that the buildbots should be running the doctests in addition to the unit tests, but right now the buildbot test command "numpy.test(level=9999,verbosity=9999)" doesn't do that. We could either add "doctests=True" to the buildbot test command, or make "level" above some threshhold run them (currently the level argument is just ignored anyway). Since the level and verbosity parameters are going away in the release after 1.2, it seems more appropriate to just add the doctests argument. Any thoughts? Thanks, Alan P.S. Thanks to whoever installed nose on the buildbots!

3 6

Should we fix Ticket #709?
by Charles R Harris July 4, 2008

July 4, 2008

That's Ticket #709 <http://projects.scipy.org/scipy/numpy/ticket/709>: > I'm faily sure that: > numpy.isnan(datetime.datetime.now() > ...should just return False and not raise an exception. > rationale: anything that is not nan should just return False, not raise > TypeErrors? <http://projects.scipy.org/scipy/numpy/wiki/TypeErrors> > <http://projects.scipy.org/scipy/numpy/ticket/709>Chuck

5 6

Record arrays
by Stéfan van der Walt July 3, 2008

July 3, 2008

Hi all, I am documenting `recarray`, and have a question: Is its use still recommended, or has it been superseded by fancy data-types? Regards Stéfan

11 18

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

July 2, 2008

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

4 4

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

July 1, 2008

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

3 6

Python/Sage minisymposium at SIAM Annual meeting July 9/10 2008
by Fernando Perez June 30, 2008

June 30, 2008

Hi all, this is just a reminder, in case you'll be attending the SIAM 2008 annual meeting next week in San Diego, that there will be a 3-part minisymposium focusing on the uses of Python and Sage in scientific computing: http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7369 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7370 http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=7447 We hope to see many of you there! Regards, Fernando and Randy

1 0

Undefined "wrap" in linalg.py:tensorsolve.py
by Alan McIntyre June 30, 2008

June 30, 2008

While I was working on the doctest tweaks, I ran across a doctest that failed because tensorsolve uses a function "wrap" that's not defined. It seems that I should make the following change to fix it (at the start of tensorsolve's code) : - a = asarray(a) + a,wrap = _makearray(a) Doing so seems to make the example run, but I just wanted to see if this was the appropriate thing to do. Thanks, Alan

2 1

SphinxDocString class in new numpy doc framework
by Matt Knox June 30, 2008

June 30, 2008

I guess this question is mostly for Stefan... but I am trying to port the scikits.timeseries module wiki documentation into a sphinx framework, and also trying to follow the numpy doc string standards (which can't be parsed directly by sphinx), so I'm trying to use the SphinxDocString class in docscrape_sphinx.py to pre-process the doc strings. However, the doc strings do not seem to be getting processed correctly. I didn't dig deep into the issue, but I thought I'd ask first before I go any further in case I am approaching this incorrectly all together. If I try to process the numpy.swapaxes docstring for example, I get the following output (note the formatting of the parameters): >>> print SphinxDocString(np.swapaxes.__doc__) Return a view of array a with axis1 and axis2 interchanged. **Parameters** `````````````` **a** : array_like Input array. axis1 : int First axis. axis2 : int Second axis. **Examples** ```````````` >>> x = np.array([[1,2,3]]) >>> np.swapaxes(x,0,1) array([[1], [2], [3]]) >>> x = np.array([[[0,1],[2,3]],[[4,5],[6,7]]]) >>> x array([[[0, 1], [2, 3]], [[4, 5], [6, 7]]]) >>> np.swapaxes(x,0,2) array([[[0, 4], [2, 6]], [[1, 5], [3, 7]]]) ================================================================ I don't know if the SphinxDocString class is even ready for use yet or not, but this didn't look right to me. The other thing I was wondering is if anyone knows how to pre-process doc strings on the fly such that you can mix them in with your .rst files similar to how the autodoc sphinx extension works (rather than just pre-generating a big dump of all the doc strings into a single .rst file). This is probably a question more for the sphinx mailing list, but I thought I'd ask while I'm on the topic in case anyone has any quick tricks they can share. Thanks, - Matt -- View this message in context: http://www.nabble.com/SphinxDocString-class-in-new-numpy-doc-framework-tp18… Sent from the Numpy-discussion mailing list archive at Nabble.com.

3 2