Mailman 3 November 2010 - NumPy-Discussion

Merging the refactor.
by Charles R Harris 12 Nov '10

12 Nov '10

Hi All, I''d like to open a discussion about the steps to be followed in merging the numpy refactor. I have two concerns about this. First, the refactor repository branched off some time ago and I'm concerned about code divergence, not just in the refactoring, but in fixes going into the master branch on github. Second, it is likely that a flag day will look like the easiest solution and I think we should avoid that. At the moment it seems to me that the changes can be broken up into three categories: 1) Movement of files and resulting changes to the build process. 2) Refactoring of the files for CPython. 3) Addition of an IronPython interface. I'd like to see 1) go into the master branch as soon as possible, followed by 2) so that the changes can be tested and fixes will go into a common repository. The main github repository can then be branched for adding the IronPython stuff. In short, I think it would be usefull to abandon the teoliphant fork at some point and let the work continue in a fork of the numpy repository. I'm not intimately familiar with details of the changes that have been made in the refactor, so I welcome any thoughts by those folks involved in the work. And of course by the usual numpy people who will need to adjust to the changes. Chuck

7 18

Change in Python/Numpy numerics with Py version 2.6 ?
by Lou Pecora 12 Nov '10

12 Nov '10

I ran across what seems to be a change in how numerics are handled in Python 2.6 or Numpy 1.3.0 or both, I'm not sure. I've recently switched from using Python 2.4 and Numpy 1.0.3 to using the Python 2.6 and Numpy 1.3.0 that comes with SAGE which is a large mathematical package. But the issue seems to be a Python one, not a SAGE one. Here is a short example of code that gives the new behavior: # ---- Return the angle between two vectors ------------ def get_angle(v1,v2): '''v1 and v2 are 1 dimensional numpy arrays''' # Make unit vectors out of v1 and v2 v1norm=sqrt(dot(v1,v1)) v2norm=sqrt(dot(v2,v2)) v1unit=v1/v1norm v2unit=v2/v2norm ang=acos(dot(v1unit,v2unit)) return ang When using Python 2.6 with Numpy 1.3.0 and v1 and v2 are parallel the dot product of v1unit and v2unit sometimes gives 1.0+epsilon where epsilon is the smallest step in the floating point numbers around 1.0 as given in the sys module. This causes acos to throw a Domain Exception. This does not happen when I use Python 2.4 with Numpy 1.0.3. I have put in a check for the exception situation and the code works fine again. I am wondering if there are other changes that I should be aware of. Does anyone know the origin of the change above or other differences in the handling of numerics between the two versions? Thanks for any insight. -- Lou Pecora, my views are my own.

4 6

Developmental version numbering with git
by Bruce Southey 11 Nov '10

11 Nov '10

Hi, Since the change to git the numpy version in setup.py is '2.0.0.dev' regardless because the prior numbering was determined by svn. Is there a plan to add some numbering system to numpy developmental version? Regardless of the answer, the 'numpy/numpy/version.py' will need to changed because of the reference to the svn naming. Bruce

4 6

specifying array sizes in random vs. ones, zeros, etc
by Michael Friedlander 11 Nov '10

11 Nov '10

I'm a hopeful Matlab refugee trying to understand the numpy way. Perhaps someone can explain why some numpy functions require shape specifications in different ways. For example, below I create a random 2-by-3 array, and then a "ones" 2-by-3 array: A = numpy.random.randn(2,3) B = numpy.ones((2,3)) The first call takes 2 arguments; the 2nd takes a single tuple argument. This strikes me as inconsistent, but probably I'm not grokking some numpy subleties. Can someone please explain?

2 1

Trac unaware of github move
by Ralf Gommers 11 Nov '10

11 Nov '10

Hi, I just noticed that the Trac wiki is not displaying updates to files kept in the source tree, for example http://projects.scipy.org/numpy/wiki/TestingGuidelines is stuck at an older version. Can one of the admins point the ReST plugin to github? Ralf

4 6

C-compiler options
by Dan Yamins 11 Nov '10

11 Nov '10

Hi: I'm trying to build numpy with python27, 64-bit, on OSX 10.5.8. When I run python setup.py build, only 32-bit binaries get built. I can see what is happening is that not 64-bit flags are getting passed to the c compiler (I don't know about the fortran compiler. So I have two questions; 1) Shouldn't the system be determining that 64-bit nature automatically? I've used the same build process on the same machine (in what I thought were identical situations, apparently not) a number of times in the past, and it has always built correctly as 64 bit. I never needed to set compiler options. 2) How do I set C compiler options for the numpy build process? thanks, Dan

3 5

Is numpy.convolve based on LAPACK routine?
by LittleBigBrain 11 Nov '10

11 Nov '10

Hi everyone, I am wondering, is numpy.convolve based on LAPACK routine? Can it be speedup by using ATLAS? Sincerely, LittleBigBrain

3 2

new memcpy implementation exposes bugs in some software.
by Charles R Harris 11 Nov '10

11 Nov '10

Hi All, Apparently the 64 bit version of memcpy in the Fedora 14 glibc will do the copy in the downwards rather than the usual upwards direction on some processors. This has exposed bugs where the the source and destination overlap in memory. Report and discussion can be found at fedora bugzilla<https://bugzilla.redhat.com/show_bug.cgi?id=638477>. I don't know that numpy has any problems of this sort but it is worth keeping in mind. Chuck

2 1

review request for half type
by Mark Wiebe 10 Nov '10

10 Nov '10

This set of patches fully implements a 16-bit floating point half type into NumPy. It's got a lot of changes, but I've tried to organize them logically so that it builds and the tests run after each patch. This took some tweaks to the building and ufunc generation code, so please check that, as particularly the setup.py looks like it could have subtleties I may have missed. I implemented only the half type, but a complex variant wouldn't be that hard to add once this is all set. Here are the main features: * 16-bit float as numpy.half or numpy.float16 * generates underflow/overflow signals * rounds to the nearest (with half to even) * uses character code 'j' -- The short type already had 'h', but if there's a better choice, let me know. The tests might provide the quickest insight into to workings of this code, so I would suggest looking through it first: test_half.py<https://github.com/m-paradox/numpy/blob/f04138667e638e47e6ea6096e05ef306070…> Here's the branch with the patches: https://github.com/m-paradox/numpy/compare/master...implement_half_dtype Thanks, Mark

1 0

Python2.7 version check for OSX numpy installer (please Test)
by Vincent Davis 10 Nov '10

10 Nov '10

No need to actualy install, You should get an error right away if you do not have both. /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-32 If you have python-2.7-macosx10.5.dmg installed or built python2.7 for both 32 and 64 bit it should work (let you install) If you have python-2.7-macosx10.3.dmg installed it should not. It will fail to find /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-32 I think :-) Should this check be a warning or prevent install? The installer is numpy-1.5.1rc2-py2.7-python.org-macosx10.5 I should have a numpy-1.5.1rc2-py2.7-python.org-macosx10.3 ready for testing later. http://dl.dropbox.com/u/1340248/1-nov%209%202010/numpy1.5.1rc2-Py2.7-32-64-… -- Thanks Vincent Davis 720-301-3003

2 2

NumPy-Discussion November 2010