Mailman 3 June 2006 - NumPy-Discussion

numexpr: where function
by Simon Burton June 5, 2006

June 5, 2006

Is it possible to use the where function in numexpr ? I see some code there for it, but not sure how to use it. While I'm asking, it seems numexpr only does pointwise operations ATM, ie there is no .sum ? Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

2 1

Random number generators.
by Charles R Harris June 4, 2006

June 4, 2006

Hi All, But mostly Robert. I've been fooling around timing random number generators and noticed that on an Athlon64 with 64bit binaries that the MWC8222 rng is about 2.5x as fast as the MT19937 generator. On my machine (1.8 GHz) I get MWC8222: long 2.58e+08 float 1.20e+08 double 1.34e+08 full double 1.02e+08 MT19937: long 9.07e+07 float 6.33e+07 double 6.71e+07 full double 3.81e+07 numbers/sec, where the time includes accumulating the sums. This also impacts the generation of normally distributed numbers MWC8222: nums/sec: 1.12e+08 average : 1.91e-05 sigma : 1.00e-00 MT19937: nums/sec: 5.41e+07 average : -9.73e-05 sigma : 1.00e+00 The times for 32 bit binaries is roughly the same. For generating large arrays of random numbers on 64 bit architectures it looks like MWC8222 is a winner. So, the question is, is there a good way to make the rng selectable? Chuck

3 5

Removing deprecated names
by Ed Schofield June 4, 2006

June 4, 2006

Hi all, I've created four patches to remove deprecated names from the numpy.core and numpy namespaces by default. The motivation for this is to provide a clear separation for both new users and users migrating from Numeric between those names that are deprecated and those that are recommended. The first patch cleans up NumPy to avoid the use of deprecated names internally: http://projects.scipy.org/scipy/numpy/ticket/137 The second patch separates the Numeric-like function interfaces, which Travis has said he doesn't want to deprecate, from the other names in oldnumeric.py, which include the capitalized type names, arrayrange, matrixmultiply, outerproduct, NewAxis, and a few others: http://projects.scipy.org/scipy/numpy/ticket/138 The third patch removes the deprecated names from the numpy.core and numpy namespaces and adds a compatibility function, numpy.Numeric(), that imports the deprecated interfaces into the namespace as before: http://projects.scipy.org/scipy/numpy/ticket/139 The fourth patch (also in ticket #139) is a script that adds the line "numpy.Numeric()" to the appropriate place in all Python files in the specified directory. I've tested this on the SciPy source tree, which still uses the old Numeric interfaces in many places. After running the script, SciPy runs all its 1518 unit tests without errors. These patches make a fairly small difference to the size of NumPy's default namespace: >>> import numpy >>> len(dir(numpy)) 438 >>> numpy.Numeric() >>> len(dir(numpy)) 484 They do, however, help to support Python principle #13 ... -- Ed

1 0

[Reply]for monday watch this stck trade HYWI.PK
by jztlta hwwbyd June 4, 2006

June 4, 2006

1 0

Re: [Numpy-discussion] numpy bug
by David Isaac June 3, 2006

June 3, 2006

"Boris Borcic" <bborcic(a)gmail.com> wrote in message news:447f3338$1_7@news.bluewin.ch... > after a while trying to find the legal manner to file numpy bug reports, > since it's a simple one, I thought maybe a first step is to describe the bug > here. Then maybe someone will direct me to the right channel. > > So, numpy appears not to correctly compute bitwise_and.reduce and > bitwise_or.reduce : instead of reducing over the complete axis, these methods > only take the extremities into account. Illustration : > > >>> from numpy import * > >>> bitwise_or.reduce(array([8,256,32,8])) > 8 > >>> import numpy > >>> numpy.__version__ > '0.9.8' > >>> > > Platform : Win XP SP2, Python 2.4.2 Most bug reports start on the numpy list, I believe. (See above.) Cheers, Alan Isaac

1 0

fromiter
by Tim Hochberg June 3, 2006

June 3, 2006

Some time ago some people, myself including, were making some noise about having 'array' iterate over iterable object producing ndarrays in a manner analogous to they way sequences are treated. I finally got around to looking at it seriously and once I came to the following three conclusions: 1. All I really care about is the 1D case where dtype is specified. This case should be relatively easy to implement so that it's fast. Most other cases are not likely to be particularly faster than converting the iterators to lists at the Python level and then passing those lists to array. 2. 'array' already has plenty of special cases. I'm reluctant to add more. 3. Adding this to 'array' would be non-trivial. The more cases we tried to make fast, the more likely that some of the paths would be buggy. Regardless of how we did it though, some cases would be much slower than other, which would probably be suprising. So, with that in mind, I retreated a little and implemented the simplest thing that did the stuff that I cared about: fromiter(iterable, dtype, count) => ndarray of type dtype and length count This is essentially the same interface as fromstring except that the values of dtype and count are always required. Some primitive benchmarking indicates that 'fromiter(generator, dtype, count)' is about twice as fast as 'array(list(generator))' for medium to large arrays. When producing very large arrays, the advantage of fromiter is larger, presumably because 'list(generator)' causes things to start swapping. Anyway I'm about to bail out of town till the middle of next week, so it'll be a while till I can get it clean enough to submit in some form or another. Plenty of time for people to think of why it's a terrible idea ;-) -tim

2 2

rand argument question
by Sven Schreiber June 3, 2006

June 3, 2006

Hi all, this may be a stupid question, but why doesn't rand accept a shape tuple as argument? I find the difference between the argument types of rand and (for example) zeros somewhat confusing. (See below for illustration.) Can anybody offer an intuition/explanation? (This is still on 0.9.6 because of matplotlib compatibility.) Thanks much, Sven >>> import numpy as n >>> n.rand((3,2)) Traceback (most recent call last): File "<interactive input>", line 1, in ? File "mtrand.pyx", line 433, in mtrand.RandomState.rand File "mtrand.pyx", line 361, in mtrand.RandomState.random_sample File "mtrand.pyx", line 131, in mtrand.cont0_array TypeError: an integer is required >>> n.zeros((3,2)) array([[0, 0], [0, 0], [0, 0]]) >>> n.zeros(3,2) Traceback (most recent call last): File "<interactive input>", line 1, in ? TypeError: data type not understood >>> n.rand(3,2) array([[ 0.27017528, 0.98280906], [ 0.58592731, 0.63706962], [ 0.74705193, 0.65980377]]) >>>

3 8

searchsorted
by Jonathan Taylor June 3, 2006

June 3, 2006

I was wondering if there was an easy way to get searchsorted to be "right-continuous" instead of "left-continuous". By continuity, I am talking about the continuity of the function "count" below... >>> import numpy as N >>> >>> x = N.arange(20) >>> x.searchsorted(9) 9 >>> import numpy as N >>> >>> x = N.arange(20) >>> >>> def count(u): ... return x.searchsorted(u) ... >>> count(9) 9 >>> count(9.01) 10 >>> Thanks, Jonathan -- ------------------------------------------------------------------------ I'm part of the Team in Training: please support our efforts for the Leukemia and Lymphoma Society! http://www.active.com/donate/tntsvmb/tntsvmbJTaylor GO TEAM !!! ------------------------------------------------------------------------ Jonathan Taylor Tel: 650.723.9230 Dept. of Statistics Fax: 650.725.8977 Sequoia Hall, 137 www-stat.stanford.edu/~jtaylo 390 Serra Mall Stanford, CA 94305

2 1

Re: [Numpy-discussion] Suggestions for NumPy
by joris＠ster.kuleuven.ac.be June 2, 2006

June 2, 2006

[DC]: My only concern with this is numpy is positioned for a wider audience: [DC]: everybody who needs arrays, and the extra speed that numpy gives, but [DC]: doesn't need what scipy gives. So merging the two could lead to [DC]: confusion on what provides what, and what you need to do which. I completely agree with this. SciPy and NumPy on one site, yes, but not so interweaven that it gets confusing or even plain useless for NumPy-only users. J. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

1 0

Updates to NumPy
by Travis Oliphant June 2, 2006

June 2, 2006

I've been busy with NumPy and it has resulted in some C-API changes. So, after checking out a new SVN version of NumPy you will need to re-build extension modules (It stinks for me too --- SciPy takes a while to build). The API changes have made it possible to allow user-defined data-types to optionally participate in the coercion and casting infrastructure. Previously, casting was limited to built-in data-types. Now, there is a mechanism for users to define casting to and from their own data-type (and whether or not it can be done safely and whether or not a particular kind of user-defined scalar can be cast --- remember a scalar mixed with an array has a different set of casting rules). This should make user-defined data-types much more useful, but the facility needs to be tested. Does anybody have a data-type they want to add to try out the new system. The restriction on adding another data-type is that it must have a fixed element size (a variable-precision float for example would have to use a pointer to the actual structure as the "data-type"). -Travis

1 0