[Numpy-discussion] Anyone coming to the sprints have a >= 1GB memory stick or blank CD?

If so, and I could use it to try to install Kubuntu tomorrow, I'd really appreciate it if you'd bring it w/ you. Thanks! DG __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _

Re: [Numpy-discussion] Fwd: GPU Numpy

Erik Tollerud skrev: >> NumPy arrays on the GPU memory is an easy task. But then I would have to >> write the computation in OpenCL's dialect of C99? > This is true to some extent, but also probably difficult to do given > the fact that paralellizable algorithms are generally more difficult > to f

Re: [Numpy-discussion] GPU Numpy

Agreed! What would be the best name? Our package will provide non-pythonic bindings to cuda (e.g. import cuda; cuda.cudaMemcpy( ... ) ) and some numpy sugar (e.g. from cuda import sugar; sugar.fft.fftconvolve(ndarray_a, ndarray_b, 'same')). How about cuda-ctypes or ctypes-cuda? Any suggestion? At

Re: [Numpy-discussion] GPU Numpy

2009/8/21 Nicolas Pinto : > For those of you who are interested, we forked python-cuda recently and > started to add some numpy "sugar". The goal of python-cuda is to > *complement* PyCuda by providing an equivalent to the CUDA Runtime API > (understand: not Pythonic) using automatically-generated

Re: [Numpy-discussion] GPU Numpy

Hello from gpunumpy import * > x=zeros(100,dtype='gpufloat') # Creates an array of 100 elements on the GPU > y=ones(100,dtype='gpufloat') > z=exp(2*x+y) # z in on the GPU, all operations on GPU with no transfer > z_cpu=array(z,dtype='float') # z is copied to the CPU > i=(z>2.3).nonzero()[0] # oper

Re: [Numpy-discussion] Accelerating NumPy computations [Was: GPU Numpy]

Matthew Brett, on 2009-08-21 11:51, wrote: > Hi, > > > Indeed. In the future, if OpenCL is the way to go, it may even be > > helpful to have Numpy using OpenCL directly, as AMD provides an SDK > > for OpenCL, and with Larrabee approaching, Intel will surely provide > > one of its own. > > I was

Re: [Numpy-discussion] PRNGs and multi-threading

Xavier Saint-Mleux skrev: > Of course, the mathematically correct way would be to use a correct > jumpahead function, but all the implementations that I know of are GPL. > A recent article about this is: > > www.iro.umontreal.ca/~lecuyer/myftp/papers/jumpmt.pdf > > I know of no efficient "jumpa

Re: [Numpy-discussion] Problems distributing NumPy

Hi again- I've been working on this problem off and on over the last couple of years, and of course did not find the solution until I finally broke down and posted to the list. It looks like the problem is very simple: Although I was adding my private folder to the Python path, I was not doing

Re: [Numpy-discussion] Accelerating NumPy computations [Was: GPU Numpy]

On Fri, Aug 21, 2009 at 2:51 PM, Matthew Brett wrote: > I can imagine Numpy being useful for scripting in this > C-and-assembler-centric world, making it easier to write automated > testers, or even generate C code. > > Is anyone out there working on this kind of stuff?  I ask only because > there

Re: [Numpy-discussion] PRNGs and multi-threading

Robert Kern wrote: > On Fri, Aug 21, 2009 at 20:50, Sturla Molden wrote: > >> Sturla Molden skrev: >> >>> It seems there is a special version of the Mersenne Twister for this. >>> The code is LGPL (annoying for SciPy but ok for me). >>> >> http://www.math.sci.hiroshima-u.ac.jp/~m-mat

Re: [Numpy-discussion] A better median function?

> On Fri, Aug 21, 2009 at 11:33 AM, Matthew Brett > wrote: >> Nicolas investigated algorithms that find the lower (or upper) median >> value.  The lower median is the median iff there are an odd number of >> entries in our list, or the lower of the central values in the sort, >> when there are an

Re: [Numpy-discussion] A better median function?

Hi, On Fri, Aug 21, 2009 at 11:33 AM, Matthew Brett wrote: > Nicolas investigated algorithms that find the lower (or upper) median > value.  The lower median is the median iff there are an odd number of > entries in our list, or the lower of the central values in the sort, > when there are an even

Re: [Numpy-discussion] PRNGs and multi-threading

On Fri, Aug 21, 2009 at 20:50, Sturla Molden wrote: > Sturla Molden skrev: >> It seems there is a special version of the Mersenne Twister for this. >> The code is LGPL (annoying for SciPy but ok for me). > > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf >

[Numpy-discussion] Problems distributing NumPy

Hi all- I am writing a C++ application with embedded Python scripting. Some of the scripts use NumPy, so I have been working out the best way to distribute NumPy with my software. At the moment, I've got a private folder which I add to the Python path. In this folder, I include all the files wh

Re: [Numpy-discussion] Accelerating NumPy computations [Was: GPU Numpy]

Hi, > Indeed. In the future, if OpenCL is the way to go, it may even be > helpful to have Numpy using OpenCL directly, as AMD provides an SDK > for OpenCL, and with Larrabee approaching, Intel will surely provide > one of its own. I was just in a lecture by one of the Intel people about OpenCL:

Re: [Numpy-discussion] PRNGs and multi-threading

Sturla Molden skrev: > It seems there is a special version of the Mersenne Twister for this. > The code is LGPL (annoying for SciPy but ok for me). http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf Basically it encodes

Re: [Numpy-discussion] PRNGs and multi-threading

Robert Kern skrev: > As long as you use different seeds, I believe this is fine. The state > size of MT is so enormous that almost any reasonable use will not find > overlaps. > It seems there is a special version of the Mersenne Twister for this. The code is LGPL (annoying for SciPy but ok fo

Re: [Numpy-discussion] A better median function?

Hi, > Nicolas Devillard discusses several algorithms at > http://ndevilla.free.fr/median/median/index.html Thanks for this. A loud 'yes' from the back of the internet too. I contacted Nicolas Devillard a year or so ago to ask him if we could include his code in Scipy, and he said 'yes'. I can

Re: [Numpy-discussion] A better median function?

On Fri, Aug 21, 2009 at 8:47 AM, Mike Ressler wrote: > I presented this during a lightning talk at the scipy conference > yesterday, so again, at the risk of painting myself as a flaming > idiot: > > - > Wanted: A Better/Faster median() Function > > numpy implementation uses sim

Re: [Numpy-discussion] Removing scipy.stsci was [Re: [SciPy-dev] Deprecate chararray [was Plea for help]]

Hi Vincent 2009/8/21 Vincent Schut : > I know it probably will be a pretty involved task, as ndimage comes from > numarray and seems to be largely implemented in C. But I really wanted > to raise the issue now the image processing subject turns up once again, > and hope some folks with more/better

Re: [Numpy-discussion] PRNGs and multi-threading

Robert Kern skrev: > Although you don't really have re-entrancy issues, you will usually > want one PRNG per thread for determinism. > I see... numpy.random.rand does not have re-entrancy issues because of the GIL, but I get indeterminism from the OS scheduling the threads. RandomState might n

Re: [Numpy-discussion] A better median function?

Ouch, didn't check my to address first, sorry!!! DG --- On Fri, 8/21/09, David Goldsmith wrote: > From: David Goldsmith > Subject: Re: [Numpy-discussion] A better median function? > To: "Discussion of Numerical Python" > Date: Friday, August 21, 2009, 9:50 AM > Not to make you regret your pos

Re: [Numpy-discussion] A better median function?

Not to make you regret your post ;-) but, you having readily furnished your email address, I'm taking the liberty of forwarding you my resume - I'm the guy who introduced himself yesterday by asking if you knew Don Hall - in case you have need of an experienced CCD data reduction programmer who

Re: [Numpy-discussion] PRNGs and multi-threading

On Fri, Aug 21, 2009 at 17:48, Sturla Molden wrote: > > I am not sure if this is the right place to discuss this issue. However, > I problem I keep running into in Monte Carlo simulations is generating > pseudorandom numbers with multiple threads. PRNGs such as the Mersenne > Twister keep an intern

[Numpy-discussion] PRNGs and multi-threading

I am not sure if this is the right place to discuss this issue. However, I problem I keep running into in Monte Carlo simulations is generating pseudorandom numbers with multiple threads. PRNGs such as the Mersenne Twister keep an internal state, which prevents the PRNG from being re-entrant a

[Numpy-discussion] A better median function?

I presented this during a lightning talk at the scipy conference yesterday, so again, at the risk of painting myself as a flaming idiot: - Wanted: A Better/Faster median() Function numpy implementation uses simple sorting algorithm: Sort all the data using the .sort() method R

Re: [Numpy-discussion] Accelerating NumPy computations [Was: GPU Numpy]

>> I personally think that, in general, exposing GPU capabilities directly >> to NumPy would provide little service for most NumPy users.  I rather >> see letting this task to specialized libraries (like PyCUDA, or special >> versions of ATLAS, for example) that can be used from NumPy. > > speciali

Re: [Numpy-discussion] Accelerating NumPy computations [Was: GPU Numpy]

Hi, On Thu, Aug 20, 2009 at 7:07 AM, Francesc Alted wrote: > El dj 20 de 08 del 2009 a les 00:37 -0700, en/na Erik Tollerud va > escriure: > > > NumPy arrays on the GPU memory is an easy task. But then I would have > to > > > write the computation in OpenCL's dialect of C99? But I'd rather > pro

Re: [Numpy-discussion] itemsize() doesn't work

Fri, 21 Aug 2009 04:47:09 +, David Goldsmith wrote: [clip] > > > http://numpy.scipy.org/numpydoc/numpy-10.html [clip] > Is this editable through the Wiki? I went to the > Docstrings page and searched for "numpydoc" and "tutorial" and got no > hits. This is the old Numeric module documentation

Re: [Numpy-discussion] Removing scipy.stsci was [Re: [SciPy-dev] Deprecate chararray [was Plea for help]]

Christopher Hanley wrote: > Hi Stefan, > > Never mind. I just found the Sprint website and read the > description. I'm sorry I hadn't found this sooner. I would have made > plans to stay and help. My apologizes. > Hi list, I just saw this too and would like to misuse this thread to sugge