Mailman 3 June 2012 - NumPy-Discussion

Strange problem
by Uwe Schmitt 29 Jun '12

29 Jun '12

Hi, I have unreproducable crashes on a customers Win 7 machine with Python 2.7.2 and Numpy 1.6.1. He gets the following message: Problem signature: Problem Event Name: APPCRASH Application Name: python.exe Application Version: 0.0.0.0 Application Timestamp: 4df4ba7c Fault Module Name: umath.pyd Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4e272b96 Exception Code: c0000005 Exception Offset: 0001983a OS Version: 6.1.7601.2.1.0.256.4 Locale ID: 2055 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 I know that I can not expect a clear answer without more information, but my customer is on hollidays and I just wanted to ask for some hints for possible reasons. The machine is not out of memory and despite this crash runs very stable. Regards, Uwe -- Dr. rer. nat. Uwe Schmitt Leitung F/E Mathematik mineway GmbH Gebäude 4 Im Helmerswald 2 66121 Saarbrücken Telefon: +49 (0)681 8390 5334 Telefax: +49 (0)681 830 4376 uschmitt(a)mineway.de www.mineway.de Geschäftsführung: Dr.-Ing. Mathias Bauer Amtsgericht Saarbrücken HRB 12339

2 2

Created NumPy 1.7.x branch
by Travis Oliphant 28 Jun '12

28 Jun '12

Hey all, I made a branch called with_maskna and then merged Nathaniel's PR which removes the mask_na support from master. I then applied a patch to fix the boolean indexing problem reported by Ralf. I then created a NumPy 1.7.x maintenance branch from which the release of NumPy 1.7 will be made. Ondrej Certik and I will be managing the release of NumPy 1.7. Ondrej is the author of SymPy and has agreed to help get NumPy 1.7 out the door. Thanks, Ondrej for being willing to help in this way. In principal only bug-fixes should be pushed to the NumPy 1.7 branch at this point. The target is to make a release of NumPy 1.7.x by July 9th. The schedule we will work for is: RC1 -- June 25 RC2 -- July 5 Release -- July 13 NumPy 1.7 is a significant release and has several changes many of which are documented in the release notes. Several new code paths were added which can have a subtle impact on code. As we make the release candidates, it will be very helpful to receive as much feedback as possible on how any changes affect your code. We will work on the release notes over the coming weeks so that they have as much information as possible. After NumPy 1.7, there is a NumPy 1.8 planned for later this year. Best regards, -Travis

16 79

Non-deterministic test failure in master
by Nathaniel Smith 28 Jun '12

28 Jun '12

According to the Travis-CI build logs, this code produces non-deterministic behaviour in master: a = np.arange(5) a[:3] = a[2:] assert_equal(a, [2, 3, 4, 3, 4]) Sometimes 'a' is [2, 3, 4, 3, 4], and sometimes it is [4, 3, 4, 3, 4]. The latter is what you get if the assignment is done 'backwards', like: a[2] = a[4] a[1] = a[3] a[0] = a[2] For example, in this build the above test failed on Python 3.2 (but passed on all other versions): http://travis-ci.org/#!/numpy/numpy/jobs/1676766 while in this build, it failed on Python 2.5 (but passed on all other versions): http://travis-ci.org/#!/numpy/numpy/jobs/1722121 Looks like we have a memcpy somewhere that should be a memmove? -n

4 4

memory allocation at assignment
by astronomer 28 Jun '12

28 Jun '12

Hi All, I am wondering if there any difference in memory overhead between the following code. a=numpy.arange(10) b=numpy.arange(10) c=a+b and a=numpy.arange(10) b=numpy.arange(10) c=numpy.empty_likes(a) c[:]=a+b Does the later code make a temproray array for the result of (a+b) and then copy it to c. I beleive it does that, but i wanted to make sure. Thanks, -- View this message in context: http://old.nabble.com/memory-allocation-at-assignment-tp34083731p34083731.h… Sent from the Numpy-discussion mailing list archive at Nabble.com.

6 9

dot() function question
by x.piter＠gmail.com 28 Jun '12

28 Jun '12

Hi list. I have got completely cunfused with the numpy.dot() function. dot(A,B) does: - matrix multiplication if A and B are of MxN and NxK sizey - dot product if A and B are of size M How how can I perform matrix multiplication of two vectors? (in matlab I do it like a*a') Thanks. Petro.

3 3

Dropping support for Python 2.4 in NumPy 1.8
by Travis Oliphant 28 Jun '12

28 Jun '12

Hey all, I'd like to propose dropping support for Python 2.4 in NumPy 1.8 (not the 1.7 release). What does everyone think of that? -Travis

7 7

Numpy logo in VTK
by klo uo 28 Jun '12

28 Jun '12

I was reading mayavi documentation and one of the examples (tvtk.ImageData) resembled Numpy logo grid. I added barchart and tweaked a bit colormap and thought to post it for fun: ======================================== import numpy as np from tvtk.api import tvtk from mayavi import mlab def view(dataset): fig = mlab.figure(bgcolor=(1, 1, 1), fgcolor=(0, 0, 0), figure=dataset.class_name[3:]) surf = mlab.pipeline.surface(dataset, opacity=0.2) mlab.pipeline.surface(mlab.pipeline.extract_edges(surf), color=(0, 0, 0), line_width=.1 ) mlab.barchart(n, extent=[0.05, 4.5, 0.05, 4.5, -.35, 1]) n=([[1,0,0,1], [1,0,1,1], [1,1,0,1], [1,0,0,1]]) data = np.random.random((5, 5, 5)) i = tvtk.ImageData(spacing=(1, 1, 1), origin=(0, 0, 0)) i.point_data.scalars = data.ravel() i.point_data.scalars.name = 'scalars' i.dimensions = data.shape view(i) ======================================== Cheers

5 12

NumPy 1.7 release plans
by Travis Oliphant 27 Jun '12

27 Jun '12

In my enthusiasm of finding someone to help with the release of NumPy 1.7 and my desire to get something released by the SciPy conference, I was hasty and didn't gather enough feedback from others about the release of NumPy 1.7. I'm sorry about that. I would like to get NumPy 1.7 out the door as quickly as we can *and* make sure it is as well tested as we can --- in fact I'm hoping we can also use this opportunity to setup a Continuous Integration system for NumPy that will essentially extend NumPy's testing infrastructure and make it easier to do releases in the future. Ondrej, the author of SymPy, has agreed to help on the both the release and the Continuous Integration side. Ideally we would also start producing a code coverage report and a vbench report for NumPy as well. This is much more likely to happen if there are other people willing to pictch in (By the way, one of the goals of NumFOCUS is to provide Continuous Integration and code coverage resources to all of the Scientific Python projects as funds and community resources become available --- please email numfocus(a)googlegroups.com if you are interested in helping with that effort). So, I would propose a code-freeze by July 13th with a beta release of NumPy 1.7 by July 17th. We will work to get that beta release actively tested by as many projects as possible, leading to a release candidate by July 31. If all goes well I could imagine a release by August 14. If we need to make another release candidate, then we can do that August 14th and push the release to August 28th. Let me know if there are any concerns about this updated schedule. Best regards, -Travis

3 3

What's the most numpythonic way to support multiple types in a C extension?
by John Salvatier 27 Jun '12

27 Jun '12

I want to support multiple types in the index_increment function that I've written here: https://github.com/jsalvatier/numpy/blob/master/numpy/core/src/multiarray/m… I need to check that the first argument's type can support addition, cast the dataptr to the appropriate type and do the addition operation for that type. It looks like some of the numpy code uses .c.src files to do templating. Is that what I want to do here? Is the syntax described somewhere? John

2 2

API policy
by Travis Oliphant 27 Jun '12

27 Jun '12

I think we need to update this document: http://projects.scipy.org/numpy/wiki/ApiDeprecation I don't think this characterizes the opinion of all involved in NumPy development (it is certainly not the way I view our commitment to users). Incidentally, in the migration from Trac we should move all pages like this from Trac to Github pages or some other location. The idea that APIs should disappear after one minor release really needs to be re-visited -- especially if there is a strong interest in changing the APIs as there has been in the move from 1.5.x to 1.6 and then from 1.6 to 1.7. This created a situation where a large number of people who did not take the 1.6.x upgrade could potentially have APIs that disappear. Most open source projects do not change APIs that rapidly. One example: OpenGL supported every entry point for 17 years prior to OpenGL 3.0 At the very least APIs, can raise warnings, they can be moved to a legacy headers location, etc, but we are not doing anyone a service by having their code stop working. It frustrates users and makes people hesitate about adopting our library as a dependency. Thanks, -Travis

3 2