Mailman 3 December 2007 - NumPy-Discussion

PyArray_ContiguousFromObject & PyDECREF
by Michiel Jan Laurens de Hoon May 17, 2011

May 17, 2011

Dear pythoneers, In Chapter 12 ("Writing a C extension") in the Numerical Python manual, in the first example PyArray_ContiguousFromObject is used together with PyDECREF, while in the last example PyArray_ContiguousFromObject is used but the arrays are not PyDECREF'ed before the function returns. From Chapter 13 ("C API Reference") it seems that a PyDECREF is needed in both cases. Or am I missing something here? Is PyDECREF not needed for some reason in the last example? Thanks in advance, Michiel de Hoon U Tokyo First example: ============== static PyObject * trace(PyObject *self, PyObject *args) { PyObject *input; PyArrayObject *array; double sum; int i, n; if (!PyArg_ParseTuple(args, "O", &input)) return NULL; array = (PyArrayObject *) PyArray_ContiguousFromObject(input, PyArray_DOUBLE, 2, 2); if (array == NULL) return NULL; n = array->dimensions[0]; if (n > array->dimensions[1]) n = array->dimensions[1]; sum = 0.; for (i = 0; i < n; i++) sum += *(double *)(array->data + i*array->strides[0] + i*array->strides[1]); Py_DECREF(array); return PyFloat_FromDouble(sum); } Last example: ============= static PyObject * matrix_vector(PyObject *self, PyObject *args) { PyObject *input1, *input2; PyArrayObject *matrix, *vector, *result; int dimensions[1]; double factor[1]; double real_zero[1] = {0.}; long int_one[1] = {1}; long dim0[1], dim1[1]; extern dgemv_(char *trans, long *m, long *n, double *alpha, double *a, long *lda, double *x, long *incx, double *beta, double *Y, long *incy); if (!PyArg_ParseTuple(args, "dOO", factor, &input1, &input2)) return NULL; matrix = (PyArrayObject *) PyArray_ContiguousFromObject(input1, PyArray_DOUBLE, 2, 2); if (matrix == NULL) return NULL; vector = (PyArrayObject *) PyArray_ContiguousFromObject(input2, PyArray_DOUBLE, 1, 1); if (vector == NULL) return NULL; if (matrix->dimensions[1] != vector->dimensions[0]) { PyErr_SetString(PyExc_ValueError, "array dimensions are not compatible"); return NULL; } dimensions[0] = matrix->dimensions[0]; result = (PyArrayObject *)PyArray_FromDims(1, dimensions, PyArray_DOUBLE); if (result == NULL) return NULL; dim0[0] = (long)matrix->dimensions[0]; dim1[0] = (long)matrix->dimensions[1]; dgemv_("T", dim1, dim0, factor, (double *)matrix->data, dim1, (double *)vector->data, int_one, real_zero, (double *)result->data, int_one); return PyArray_Return(result); } -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon

3 2

Unpleasant behavior with poly1d and numpy scalar multiplication
by Fernando Perez Feb. 15, 2010

Feb. 15, 2010

Hi all, consider this little script: from numpy import poly1d, float, float32 p=poly1d([1.,2.]) three=float(3) three32=float32(3) print 'three*p:',three*p print 'three32*p:',three32*p print 'p*three32:',p*three32 which produces when run: In [3]: run pol1d.py three*p: 3 x + 6 three32*p: [ 3. 6.] p*three32: 3 x + 6 The fact that multiplication between poly1d objects and numbers is: - non-commutative when the numbers are numpy scalars - different for the same number if it is a python float vs a numpy scalar is rather unpleasant, and I can see this causing hard to find bugs, depending on whether your code gets a parameter that came as a python float or a numpy one. This was found today by a colleague on numpy 1.0.4.dev3937. It feels like a bug to me, do others agree? Or is it consistent with a part of the zen of numpy I've missed thus far? Thanks, f

6 17

Compact way of performing array math with specified result type?
by Russell E. Owen Feb. 8, 2010

Feb. 8, 2010

I often find myself doing simple math on sequences of numbers (which might or might not be numpy arrays) where I want the result (and thus the inputs) coerced to a particular data type. I'd like to be able to say: numpy.divide(seq1, seq2, dtype=float) but ufuncs don't allow on to specify a result type. So I do this instead: numpy.array(seq1, dtype=float) / numpy.array(seq2, dtype=float) Is there a more compact solution (without having to create the result array first and supply it as an argument)? -- Russell

4 3

Slicing/selection in multiple dimensions simultaneously
by Mike Ressler March 17, 2009

March 17, 2009

The following seems to be a wart: is it expected? Set up a 10x10 array and some indexing arrays: a=arange(100) a.shape=(10,10) q=array([0,2,4,6,8]) r=array([0,5]) Suppose I want to extract only the "even" numbered rows from a - then print a[q,:] <works - output deleted> Every fifth column: print a[:,r] <works - output deleted> Only the even rows of every fifth column: print a[q,r] --------------------------------------------------------------------------- <type 'exceptions.ValueError'> Traceback (most recent call last) /.../.../.../<ipython console> in <module>() <type 'exceptions.ValueError'>: shape mismatch: objects cannot be broadcast to a single shape But, this works: print a[q,:][:,r] [[ 0 5] [20 25] [40 45] [60 65] [80 85]] So why does the a[q,r] form have problems? Thanks for your insights. Mike -- mike.ressler(a)alum.mit.edu

8 16

Request for advice: project to get NumPy working in IronPython
by Giles Thomas April 26, 2008

April 26, 2008

Hi, At Resolver Systems, we have a product that is written in IronPython - the .NET Python implementation - and allows users to use that language to script a spreadsheet-like interface. Because they're using IronPython, they can access their existing .NET objects and libraries, which has worked out really well for us and for them. But there's an increasing number of users who would like access to CPython C extensions - in particular, NumPy. We *don't* want to just hack something together that would just allow users of our own product to access NumPy; what we'd really like to do is work on an OSS solution that will allow all IronPython users to access NumPy transparently, just as if they were using CPython. My question is, is this something that the readers of this list would like to get involved in, either in terms of contibuting, or even in terms on advice? We're under no illusions; this is a significant undertaking. And we're very keen on hearing from those who know NumPy better about how this should be structured, even if people don't have the time to write code for it. In particular: * How do people feel about a source-code-compatible solution, where (perhaps) we would maintain a project that basically provided an alternative makefile for NumPy - or, even better, we could work with the NumPy developers to contribute a .NET/IronPython package. * Would it be better to try for some kind of "binary compatibility", where we'd write some kind of "glue" that sat between the existing C extension .pyd files and the IronPython engine? Our gut feeling is that this would be much more work, but we might be missing something. * What should the work's relationship to the NumPy project be? Any thoughts, comments, or advice would be very much appreciated. Regards, Giles -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas(a)resolversystems.com +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK

12 16

Problem with numpy.linalg.eig?
by Peter Creasey April 4, 2008

April 4, 2008

Hi all, The following code calling numpy v1.0.4 fails to terminate on my machine, which was not the case with v1.0.3.1 from numpy import arange, float64 from numpy.linalg import eig a = arange(13*13, dtype = float64) a.shape = (13,13) a = a%17 eig(a) Regards, Peter

6 19

planet.scipy.org
by Jarrod Millman April 1, 2008

April 1, 2008

Hey, I just wanted to announce that we now have a NumPy/SciPy blog aggregator thanks to Gaël Varoquaux: http://planet.scipy.org/ Feel free to contact me if you have a blog that you would like included. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

12 24

Faster array version of ndindex
by Jonathan Taylor Feb. 22, 2008

Feb. 22, 2008

I was needing an array representation of ndindex since ndindex only gives an iterator but array(list(ndindex)) takes too long. There is prob some obvious way to do this I am missing but if not feel free to include this code which is much faster. In [252]: time a=np.array(list(np.ndindex(10,10,10,10,10,10))) CPU times: user 11.61 s, sys: 0.09 s, total: 11.70 s Wall time: 11.82 In [253]: time a=ndtuples(10,10,10,10,10,10) CPU times: user 0.32 s, sys: 0.21 s, total: 0.53 s Wall time: 0.60 def ndtuples(*dims): """Fast implementation of array(list(ndindex(*dims))).""" # Need a list because we will go through it in reverse popping # off the size of the last dimension. dims = list(dims) # N will keep track of the current length of the indices. N = dims.pop() # At the beginning the current list of indices just ranges over the # last dimension. cur = np.arange(N) cur = cur[:,np.newaxis] while dims != []: d = dims.pop() # This repeats the current set of indices d times. # e.g. [0,1,2] -> [0,1,2,0,1,2,...,0,1,2] cur = np.kron(np.ones((d,1)),cur) # This ranges over the new dimension and 'stretches' it by N. # e.g. [0,1,2] -> [0,0,...,0,1,1,...,1,2,2,...,2] front = np.arange(d).repeat(N)[:,np.newaxis] # This puts these two together. cur = np.column_stack((front,cur)) N *= d return cur

4 4

Re: [Numpy-discussion] [C++-sig] Overloading sqrt(5.5)*myvector
by Bruce Sherwood Jan. 8, 2008

Jan. 8, 2008

Roman Yakovenko wrote: > On Dec 29, 2007 7:47 AM, Bruce Sherwood <Bruce_Sherwood(a)ncsu.edu> wrote: > >> I realized belatedly that I should upgrade from Boost 1.33 to 1.34. >> Alas, that didn't cure my problem. >> > Can you post small and complete example of what you are trying to achieve? > I don't have a "small and complete" example available, but I'll summarize from earlier posts. VPython (vpython.org) has its own vector class to mimic the properties of 3D vectors used in physics, in the service of easy creation of 3D animations. There is a beta version which imports numpy and uses it internally; the older production version uses Numeric. Boost python and thread libraries are used to connect the C++ VPython code to Python. There is operator overloading that includes scalar*vector and vector*scalar, both producing vector. With Numeric, sqrt produced a float, which was a scalar for the operator overloading. With numpy, sqrt produces a numpy.float64 which is caught by vector*scalar but not by scalar*vector, which means that scalar*vector produces an ndarray rather than a vector, which leads to a big performance hit in existing VPython programs. The overloading and Boost code is the same in the VPython/Numeric and VPython/numpy versions. I don't know whether the problem is with numpy or with Boost or with the combination of the two. Here is the relevant part of the vector class: inline vector operator*( const double s) const throw() { return vector( s*x, s*y, s*z); } and here is the free function for right multiplication: inline vector operator*( const double& s, const vector& v) { return vector( s*v.x, s*v.y, s*v.z); } Maybe the problem is in the Boost definitions: py::class_<vector>("vector", py::init< py::optional<double, double, double> >()) .def( self * double()) .def( double() * self) Left multiplication is fine, but right multiplication isn't. A colleague suggested the following Boost declarations but cautioned that he wasn't sure of the syntax for referring to operator, and indeed this doesn't compile: .def( "__mul__", &vector::operator*(double), "Multiply vector times scalar") .def( "__rmul__", &operator*(const double&, const vector&), "Multiply scalar times vector") I would really appreciate a Boost or numpy expert being able to tell me what's wrong (if anything) with these forms. However, I may have a useful workaround as I described in a post to the numpy discussion list. A colleague suggested that I do something like this for sqrt and other such mathematical functions: def sqrt(x): try: return mathsqrt(x) except TypeError: return numpysqrt(x) That is, first try the simple case of a scalar argument, handled by the math module sqrt, and only use the numpy sqrt routine in the case of an array argument. Even with the overhead of the try/except machinery, one gets must faster square roots for scalar arguments this way than with the numpy sqrt. Bruce Sherwood

5 6

Numpy or Boost problem
by Bruce Sherwood Jan. 7, 2008

Jan. 7, 2008

I'm not sure whether this is a Numpy problem or a Boost problem, so I'm posting to both communities. In old Numeric, type(sqrt(5.5)) was float, but in numpy, type(sqrt(5.5)) is numpy.float64. This leads to a big performance hit in calculations in a beta version of VPython, using the VPython 3D "vector" class, compared with the old version that used Numeric (VPython is a 3D graphics module for Python; see vpython.org). Operator overloading of the VPython vector class works fine for vector*sqrt(5.5) but not for sqrt(5.5)*vector. The following free function catches 5.5*vector but fails to catch sqrt(5.5)*vector, whose type ends up as numpy.ndarray instead of the desired vector, with concomitant slow conversions in later vector calculations: inline vector operator*( const double& s, const vector& v) { return vector( s*v.x, s*v.y, s*v.z); } I've thrashed around on this, including trying to add this: inline vector operator*( const npy_float64& s, const vector& v) { return vector( s*v.x, s*v.y, s*v.z); } But the compiler correctly complains that this is in conflict with the version of double*vector, since in fact npy_float64 is actually double. It's interesting and presumably meaningful to the knowledgeable (not me) that vector*sqrt(5.5) yields a vector, even though the overloading speaks of double, not a specifically numpy name: inline vector operator*( const double s) const throw() { return vector( s*x, s*y, s*z); } VPython uses Boost, and the glue concerning vectors includes the following: py::class_<vector>("vector", py::init< py::optional<double, double, double> >()) .def( self * double()) .def( double() * self) As far as I can understand from the Boost Python documentation, this is the proper way to specify the left-hand and right-hand overloadings. But do I have to add something like .def( npy_float64() * self)? Help would be much appreciated. Bruce Sherwood

5 5

Towards using scons in numpy: 1st step
by David Cournapeau Jan. 4, 2008

Jan. 4, 2008

Hi, as discussed with some other numpy developers, in particular Travis, I started to prepare my work related to scons for step-by-step merging into the trunk. The first step is done, and is in cleanconfig_rtm branch (rtm for ready to merge). This branch basically: - avoid introducing new SIZEOF_* like symbols, which are usually used by autotools. Python itself defines some of those, but should not. - avoid #ifdef/#endif in config.h files: normally, configuration headers should only contains define. This also makes their generation more straightforward, and more compatible with standard build tools (autotools/scons). This is the main goal of the branch - split configuration defines into two files: one private (config.h), which is not visible by any other packages compiled against numpy headers, and one public (numpyconfig.h), which replaces the config.h. If there is no problem, I would like to merge this one as quickly as possible: since it changes numpy.core public header, it may potentially break things, and I would prefer detecting those breakages now. cheers, David

2 3

[OT] Which version of svn does svn.scipy.org run ?
by David Cournapeau Jan. 4, 2008

Jan. 4, 2008

Hi, Is it possible to know which version of subversion is used by the svn.scipy.org server ? I am trying to use svnsync on it, without any success, and wanted to know if this was coming from svn.scipy.org or from something else ? cheers, David

2 2

random access iterators
by Neal Becker Dec. 30, 2007

Dec. 30, 2007

I'm looking at writing some c++ code to interoperate with numpy. A c++ random access iterator must include a 'distance' function. distance (i1, i2) must return the number of times i1 has to be incremented to reach i2. Is there a way to get this from PyArrayIterObject?

2 1

how do I list all combinations
by Mathew Yeates Dec. 30, 2007

Dec. 30, 2007

Hi I've been looking at "fromfunction" and itertools but I'm flummoxed. I have an arbitrary number of lists. I want to form all possible combinations from all lists. So if r1=["dog","cat"] r2=[1,2] I want to return [["dog",1],["dog",2],["cat",1],["cat",2]] It's obvious when the number of lists is not arbitrary. But what if thats not known until runtime? Mathew

8 12

iterator speed
by Neal Becker Dec. 30, 2007

Dec. 30, 2007

In numpybook, in discussing iterators, it says that if you know your array is contiguous, it may be faster to just use C-style pointers instead of iterators. Looking at the code a little, it appears that PyArray_ITER_NEXT(it) attempts to optimize for certain cases. I wonder if anyone has done any benchmarks on modern compilers? In particular, I'm hoping that PyArray_ITER_NEXT on a modern compiler will optimize the contiguous case to give equivalent performance to a c-style pointer. In that case, I could happily use the generic iterator without a speed penalty.

1 0

Doc-day
by Travis E. Oliphant Dec. 30, 2007

Dec. 30, 2007

Doc-day will start tomorrow (in about 12 hours). It will be Friday for much of America and be moving into Saturday for Europe and Asia. Join in on the irc.freenode.net (channel scipy) to coordinate effort. I imaging people will be in an out. I plan on being available in IRC from about 9:30 am CST to 6:00 pm CST and then possibly later. If you are available at different times in different parts of the world, jump in and pick something to work on. Jarrod and/or I will put out a list of priorities in the next few hours. -Travis O.

8 16

Passing a Null pointer after ndarray prototype definition
by Nicholas Dec. 30, 2007

Dec. 30, 2007

I have a problem in that I have a DLL function which accepts several numpy double arrays, but you need to pass a NULL pointer for the ones from which you do not require results. The prototype is as follows: T_ndDp = numpy.ctypeslib.ndpointer(dtype=float, ndim=1, flags='C_CONTIGUOUS') Prototype_example = CFUNCTYPE(None, c_long, T_ndDp, T_ndDp, T_ndDp) In ctypes None is equivelent to NULL, though in order to get past the prototype argchecks you need to cast the object to None. If for example the pointer was to a simple double one could write something like: cast(None, POINTER(c_double)) the problem is in casting to None for the above (T_ndDp) type Any help would be greatly appreciated Nicholas

1 0

numpy installed but can' use
by dikshie Dec. 29, 2007

Dec. 29, 2007

Hi, successfully installed numpy but i cant use it (numpy is not defined). for example: Python 2.5.1 (r251:54863, Nov 25 2007, 02:18:29) [GCC 4.2.1 20070719 [FreeBSD]] on freebsd7 Type "help", "copyright", "credits" or "license" for more information. >>> from numpy import * >>> numpy.__version__ Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'numpy' is not defined >>> any hints ? regards, -- -dikshie-

5 6

numpy and math sqrt timings
by Bruce Sherwood Dec. 29, 2007

Dec. 29, 2007

On the VPython list Scott Daniels suggested using try/except to deal with the problem of sqrt(5.5) being numpy.float64 and thereby making sqrt(5.5)*(VPython vector) not a (VPython vector), which ends up as a big performance hit on existing programs. I tried his suggestion and did some timing using the program shown below. Using "from numpy import *", the numpy sqrt(5.5) gives 5.7 microsec per sqrt, whereas using "from math import *" a sqrt is only 0.8 microsec. Why is numpy so much slower than math on this simple case? For completeness I also timed the old Numeric sqrt, which was 14 microsec, so numpy is a big improvement, but still very slow compared to math. Using Daniels's suggestion of first trying the math sqrt, falling through to the numpy sqrt only if the argument isn't a simple scalar, gives 1.3 microsec per sqrt on the simple case of a scalar argument. Shouldn't/couldn't numpy do something like this internally? Bruce Sherwood ---------------------------- from math import * mathsqrt = sqrt from numpy import * numpysqrt = sqrt from time import clock # 0.8 microsec for "raw" math sqrt # 5.7 microsec for "raw" numpy sqrt # 1.3 microsec if we try math sqrt first def sqrt(x): try: return mathsqrt(x) except TypeError: return numpysqrt(x) # Check that numpy sqrt is invoked on an array: nums = array([1,2,3]) print sqrt(nums) x = 5.5 N = 500000 t1 = clock() for n in range(N): y = sqrt(x) y = sqrt(x) y = sqrt(x) y = sqrt(x) y = sqrt(x) y = sqrt(x) y = sqrt(x) y = sqrt(x) y = sqrt(x) y = sqrt(x) t2 = clock() for n in range(N): pass t3 = clock() # t3-t2 is the loop overhead (turns out negligible) print "%i loops over 10 sqrt's takes %.1f seconds" % (N,t2-t1) print "Total loop overhead = %.2f seconds (negligible)" % (t3-t2) print "One sqrt takes %.1f microseconds" % (1e6*((t2-t1)-(t3-t2))/(10*N))

2 1

Re: [Numpy-discussion] [C++-sig] Overloading sqrt(5.5)*myvector
by Bruce Sherwood Dec. 29, 2007

Dec. 29, 2007

Thanks for the suggestion. It hadn't occurred to me to try to override numpy as you suggest. However, when I try the code shown below as the start of a test of this scheme, I get the following error: Traceback (most recent call last): File "C:\Documents and Settings\Bruce\My Documents\0VPythonWork\vectors.py", line 24, in <module> numpy.float64.__mul__ = new_mul TypeError: can't set attributes of built-in/extension type 'numpy.float64' I'm copying this to the numpy discussion list, as maybe someone there will see where to go starting from your suggestion. Bruce Sherwood --------------- import numpy class vector(object): def __init__(self,x,y,z): self.data = [x,y,z] def __mul__(self,other): return vector(other*self.data[0], other*self.data[1], other*self.data[2]) __rmul__ = __mul__ def show(self): print self.data old_mul = numpy.float64.__mul__ def new_mul( self, other ): if isinstance( other, vector ): return other*self else: return old_mul( self, other ) numpy.float64.__mul__ = new_mul a = vector(1,2,3) a.show() b = 5*a b.show() c = a*7 c.show() Roman Yakovenko wrote: > On Dec 26, 2007 8:11 AM, Bruce Sherwood <Bruce_Sherwood(a)ncsu.edu> wrote: > >> Sorry to repeat myself and be insistent, but could someone please at >> least comment on whether I'm doing anything obviously wrong, even if you >> don't immediately have a solution to my serious problem? There was no >> response to my question (see copy below) which I sent to both the numpy >> and Boost mailing lists. >> >> To the Boost experts: Is there something wrong, or something I >> could/should change in how I'm trying to define to Boost the overloaded >> multiplication of a numpy square root (or other numpy function) times my >> own "vector" object? I'm seeing a huge performance hit in going from >> Numeric to numpy because Numeric sqrt returned float whereas numpy sqrt >> returns numpy.float64, so that the result is not one of my vector >> objects. I don't have a problem with myvector*sqrt(5.5). Here is what I >> currently am doing: >> >> py::class_<vector>("vector", py::init< py::optional<double, double, >> double> >()) >> .def( self * double()) >> .def( double() * self) >> >> Desperately, >> > > If I understand you right, than you can do something like this: > > replace __mul__ method of numpy.float64 class: > > old_mul = numpy.float64.__mul__ > > def new_mul( self, other ): > if other isinstance( vector ): > return other*self > else: > return old_mul( self, other ) > > numpy.float64.__mul__ = new_mul > > HTH > >

3 5

any better way to normalise a matrix
by devnew＠gmail.com Dec. 29, 2007

Dec. 29, 2007

in my code i am trying to normalise a matrix as below mymatrix=matrix(..# items are of double type..can be negative values....) numrows,numcols=mymatrix.shape for i in range(numrows): temp=mymatrix[i].max() for j in range(numcols): mymatrix[i,j]=abs(mymatrix[i,j]/temp) # i am using abs() to make neg vals positive this way the code takes too much time to run for a case of numrows=25, and numcols=8100 etc.. being a beginner in numpy and python ,i would like to know if this can be done more efficiently..can anyone advise? thanx dn

3 6

Scipy server down...
by Fernando Perez Dec. 28, 2007

Dec. 28, 2007

Any chance it might be brought back up? (I'm trying to commit the weave cleanup work Min did at the sprint...) Thanks, f

3 3

SciPy Sprint results
by Travis E. Oliphant Dec. 27, 2007

Dec. 27, 2007

Hi all, We had a great Sprint at Berkeley over last weekend. Jarrod deserves a huge hand for organizing it and Fernando should be also congradulated for making the Sprint a productive communication session with a lot of different people. Going forward, there will be a relatively informal SciPy board whose purpose is to keep SciPy (and NumPy) moving forward. Currently, this board consists of (alphabetically) Eric Jones Robert Kern Jarrod Millman Travis Oliphant Our goal is to clean up SciPy and get it ready for 1.0 release over the next year or so (which will need lots of help from the community). If anybody else is interested in serving on this board, just send me email. As part of this goal, we will be having regular "sprints" as well virtual "bug-days" and "doc-days" where people who want to participate using IRC can join in and coordinate efforts. There will be at least one bug-day or doc-day every month over the next year (on the last Friday of the month). The first one is a "doc-day" which will be held Friday on December 28, 2007 (getting started on New Year's resolutions early). This doc-day will be virtual where anyone with an internet connection can join in on the scipy channel on irc.freenode.net. At least one board member will be available at each "doc-day" or "bug-day" (even if we have to recruit board members to make it happen :-) ) The recent Sprint was very helpful. Jarrod is putting together some material from the Sprint. But, I wanted to provide over-view information for those who may be interested in what happend. Summary: A lot of great discussion took place (and some fine actual coding by a few) which resulted in the following plans: Schedule ------------ * NumPy 1.0.5 in mid January * SciPy 0.7.0 in mid March to April * NumPy 1.1 by August 2008 (may slip a bit depending on what is wanted to be included) The plans below are for NumPy 1.0.5 and SciPy 0.7.0 unless otherwise noted. IO ---- * scipy.io will be gutted and what functionality remains will be placed in numpy.io. * scipy.io will be a place for file readers and writers for various data formats (data, audio, video, images, matlab, excel, etc.) * NumPy will get a standard binary file format (.npy/.npz) for arrays/groups_of_arrays. * NumPy will be trying to incorporate some of matplotlib's csv2rec and rec2csv functionality. * Pickling arrays will be discouraged (you will still be able to do it, we will just try to not make it seem that it is the "default" way to save arrays). Testing --------- * scipy unit-testing will be "nose-compliant" and therefore nose will be required to run the SciPy tests. * NumPy will still use the current testing framework but will support SciPy's desire to be nose-compliant. NumPy 1.1 tests may move to just being "nose-compliant" * The goal is to make tests easier for contributors to write. Weave --------- * weave will not move into NumPy yet, but possibly at NumPy 1.1, there could be a separate package containing all the "wrapping" support code for NumPy in a more unified fashion (if somebody is interested in this, it is a great time to jump in). Sandbox ----------- * the scipy sandbox is disappearing (except for user playgrounds) and useful code in it will be placed in other areas. Python versions -------------------- * SciPy 0.7.0 will require Python 2.4 (we can now use decorators for SciPy). * NumPy will still be useful with Python 2.3 until at least 1.1 Other discussions ---------------------- * numpy-scons will be a separate package for now for building extensions with scons (we need experience to figure out what to do with it). * fixes to repr for numpy float scalars were put in place * Thanks to Rob Falck scipy.optimize grew slsqp (sequential least-squares programming) method (allows for equality and inequality constraints). The code by Dieter Kraft was wrapped. * We will be working to coordinate efforts with William Stein (of SAGE fame) in the future. Sage developers will be coming to Austin at the end of February to do some cooperative sprinting. * Brian Granger is working on a parallel version of NumPy that is very interesting. Deprecation approaches ------------------------------- Functions in SciPy that are disappearing will be "deprecated" with appendages to the docstring to explain how to do it differently. The deprecation will issue a warning when the function is run. In the next version, the function will disappear. Once SciPy hits 1.0, the deprecation paradigm will be a bit more conservative. A lot of fabulous things are happening with SciPy. It is an exciting time to be a part of it. There are a lot of ways to jump in and participate so feel free. If there is something you think needs addressing, then please share it. We may have a simple PEP process in the future, but for now the rule is basically "working code." Best regards, -Travis O.

3 2

Re: [Numpy-discussion] non uniform random number generator
by Nadav Horesh Dec. 27, 2007

Dec. 27, 2007

Lot of nonuniform distributions, see numpy.random module. Nadav. -----Original Message----- From: numpy-discussion-bounces(a)scipy.org on behalf of dikshie Sent: Thu 27-Dec-07 17:45 To: numpy-discussion(a)scipy.org Subject: [Numpy-discussion] non uniform random number generator hi, does numpy support non uniform random number generator ? regards, -dikshie- _______________________________________________ Numpy-discussion mailing list Numpy-discussion(a)scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

1 0

non uniform random number generator
by dikshie Dec. 27, 2007

Dec. 27, 2007

hi, does numpy support non uniform random number generator ? regards, -dikshie-

2 1