Re: [Numpy-discussion] Latest Array-Interface PEP

Christopher Barker wrote: [SNIP] > I think the PEP has far more chances of success if it's seen as a > request from a variety of package developers, not just the numpy crowd > (which, after all, already has numpy This seems eminently sensible. Getting a few developers from other projects on boa

Re: [Numpy-discussion] custom accumlators

Matt Knox wrote: >>> You might want to look at frompyfunc: >>> >>> def expmave2(x, k): >>> def expmave_sub(a, b): >>> return a + k * (b - a) >>> return np.frompyfunc(expmave_sub, 2, 1).accumulate(x) >>> >>> >>> It's amazing wha

Re: [Numpy-discussion] custom accumlators

Tim Hochberg wrote: > A. M. Archibald wrote: > > > [SNIP] > >> Really it would be nice if what vectorize() returned were effectively >> a ufunc, supporting all the various operations we might want from a >> ufunc (albeit inefficiently). This should not be

Re: [Numpy-discussion] custom accumlators

A. M. Archibald wrote: [SNIP] > > Really it would be nice if what vectorize() returned were effectively > a ufunc, supporting all the various operations we might want from a > ufunc (albeit inefficiently). This should not be difficult, but I am > not up to writing it this evening. > You might

Re: [Numpy-discussion] custom accumlators

Matt Knox wrote: > I made a post about this a while ago on the scipy-user mailing list, but I > didn't receive much of a response so I'm just throwing it out there again > (with more detail) in case it got overlooked. > > Basically, I'd like to be able to do accumulate operations with custom > f

Re: [Numpy-discussion] The risks of empty()

Bock, Oliver BGI SYD wrote: > Some of my arrays are not fully populated. (I separately record which > entries are valid.) I want to use numpy.empty() to speed up the > creation of these arrays, but I'm worried about what will happen if I > apply operations to the entire contents of these arrays.

Re: [Numpy-discussion] Type of 1st argument in Numexpr where()

Ivan Vilata i Balaguer wrote: > Tim Hochberg (el 2006-12-20 a les 09:20:01 -0700) va dir:: > > >> Actually, this is on purpose. Numpy.where (and most other switching >> constructs in Python) will switch on almost anything. In particular, any >> number that is nonze

Re: [Numpy-discussion] Type of 1st argument in Numexpr where()

Ivan Vilata i Balaguer wrote: > Hi all, > > I noticed that the set of ``where()`` functions defined by Numexpr all > have a signature like ``xfxx``, i.e. the first argument is a float and > the return, second and third arguments are of the same type (whatever it > is). > > Since the first argument

Re: [Numpy-discussion] slow numpy.clip ?

Robert Kern wrote: > Travis Oliphant wrote: > >> The problem with the copy=True keyword is that it would imply needing to >> expand the C-API for PyArray_Clip and should not be done until 1.1 IMHO. >> > > I don't think we have to change the signature of PyArray_Clip() at all. > PyArray_Cli

Re: [Numpy-discussion] Unexpected output using numpy.ndarray and__radd__

Mark Hoffmann wrote: > I appreciate the answer and the solution suggestion. I see that it is > possible to make a work around by subclassing from ndarray. Still, in the > "print a+c" statement, I don't understand why a.__add__(c) doesn't return > NotImplemented (because ndarray shouldn't recogni

Re: [Numpy-discussion] Pyrex and numpy

Evan Lapisky wrote: >> I was just going to try pyrex out with numpy to see how it compares with >> weave (which is cool but quirky). My first attempt ended in failure: I >> tried to compile the demo in in numpy/doc/pyrex and got this error: >> >>c_numpy.pxd:99:22: Array element cannot be a Pyth

[Numpy-discussion] Pyrex and numpy

I was just going to try pyrex out with numpy to see how it compares with weave (which is cool but quirky). My first attempt ended in failure: I tried to compile the demo in in numpy/doc/pyrex and got this error: c_numpy.pxd:99:22: Array element cannot be a Python object Does anyone who us

Re: [Numpy-discussion] Definition of correlation, correlate and so on ?

David Cournapeau wrote: > Charles R Harris wrote: > >> On 12/12/06, *David Cournapeau* <[EMAIL PROTECTED] >> > wrote: >> >> Hi, >> >> I am polishing some code to compute autocorrelation using fft, and >> when testing the code against numpy.correlate, I

Re: [Numpy-discussion] a==b for numpy arrays

Abel Daniel wrote: > Robert Kern gmail.com> writes: > > >> Abel Daniel wrote: >> >>> Now, I think that having a way of getting an element-wise comparison >>> (i.e. getting an array of bools) is great. _But_ why make that the >>> result of a '==' comparison? Is there any actual code that do

Re: [Numpy-discussion] lapack_lite dgesv

R. David wrote: > Hello, > > > >> Try replacing 'int' with intc (or numpy.intc if you are not using >> 'import *'). The following 'works' for me in the sense that it doesn't >> throw any errors (although I imagine the results are nonsense): >> > Thanks, it works now !! > Great. Glad th

Re: [Numpy-discussion] lapack_lite dgesv

R. David wrote: > Hello Tim, > >> The problem is probably your definition of ipiv. "(DIM)" is just a >> parenthesized scalar, what you probably want is "(DIM,)", which is a >> one-tuple. Personally, I'd recommend using list notation ("[nbrows, >> nbcols]", "[DIM]") rather than tuple notation

Re: [Numpy-discussion] lapack_lite dgesv

R. David wrote: > Hello, > > I am trying to use the lapack_lite dgesv routine. > > The following sample code : > > from numpy import * > [] > a=zeros((nbrows,nbcols),float,order='C') > [] > ipiv=zeros((DIM),int,order='C') > [] > linalg.lapack_lite.dgesv(DIM,1,a,DIM,asarray(ipiv),b,DIM,i

Re: [Numpy-discussion] Precision in Python

Elton Mendes wrote: > Hi. > I'm having a precision problem in python > > Example: > > > >>> a = 5.14343434 > >>> b = round(a,1) > >>> b > 5.0996 > >>> > > It´s possible to round the number exactly to 5.1 Read this: http://www.python.org/infogami-faq/general/why-are-floating-point-calc

Re: [Numpy-discussion] How to speed up this function?

[EMAIL PROTECTED] wrote: > Hello, > > I'm taking a CFD class, one of the codes I wrote runs very slow. When I look > at hotshot is says the function below is the problem. Since this is an > explicit step, the for loops are only traversed once, so I think it's caused > by memory usage, but I'm no

Re: [Numpy-discussion] extremely slow array indexing?

Fang Fang wrote: > Thanks for your reply. The simplified code is as follows. It takes 7 > seconds to process 1000 rows, which is tolerable, but I wonder why it > takes so long. Isn't vectorized operation supposed to run very quickly. > > from numpy import * > > componentcount = 30 > currSum =

Re: [Numpy-discussion] can int and float exists in one array?(about difference in indexing Matlab matrix and Numpy array)

Zhang Sam wrote: > Thanks for so many replies. > > In fact, I want to use several arrays to store the original data from > a practical project. In every arrays, two or three column will be > store the index. The main computation is still on matrices(float type) > which is built from the origin

Re: [Numpy-discussion] can int and float exists in one array?(about difference in indexing Matlab matrix and Numpy array)

Zhang Sam wrote: > Hi, there > > I have a practical problem. For some reason, I hope int and float can > exist one array as shown in matlab code. > --- > >> x = [2 2.5 3.5; 1 2.6 3.5] > > x = > > 2.2.5000

Re: [Numpy-discussion] numpy.random.shuffle

Robert Kern wrote: > Tim Hochberg wrote: > >> Robert Kern wrote: >> > > >>> One possibility is to check if the object is an ndarray (or subclass) and >>> use >>> .copy() if so; otherwise, use the current implementation and hope that

Re: [Numpy-discussion] numpy.random.shuffle

Robert Kern wrote: > Christopher Barker wrote: > >> Robert Kern wrote: >> [SNIP] >>> I copied the algorithm from Python's random >>> module. At the core of it is a set of swaps: >>> >>> x[i], x[j] = x[j], x[i] >>> >>> With the kind of sequences that the stdlib random module is expecting

[Numpy-discussion] fromiter and objects

I was looking at fromiter again today with an eye toward extending it to accept iterators of sequences instead of just iterators of scalars. For example: fromiter(([x, x // 2, x+5] for x in range(1000)), dtype=int) This would result in a shape-(1000,3) array. At first glance at least, thi

Re: [Numpy-discussion] mysql -> record array

Eric Emsellem wrote: > Hi Travis, > > sorry to bother you with that, but who's responsible with the numpy list? > I am receiving ALL numpy-list emails directly now (although I always opted for > the bundle option and checked that it is still on). I sent a mail about this, > but no answer so far. >