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 suggest
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. It
Hi,
On Thu, Aug 20, 2009 at 7:07 AM, Francesc Alted fal...@pytables.org 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
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.
specialized
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
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
On Fri, Aug 21, 2009 at 17:48, Sturla Moldenstu...@molden.no 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
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
Ouch, didn't check my to address first, sorry!!!
DG
--- On Fri, 8/21/09, David Goldsmith d_l_goldsm...@yahoo.com wrote:
From: David Goldsmith d_l_goldsm...@yahoo.com
Subject: Re: [Numpy-discussion] A better median function?
To: Discussion of Numerical Python numpy-discussion@scipy.org
Date:
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 not
Hi Vincent
2009/8/21 Vincent Schut sc...@sarvision.nl:
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
On Fri, Aug 21, 2009 at 8:47 AM, Mike Resslermike.ress...@alum.mit.edu 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
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
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
http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/DC/dgene.pdf
Basically it encodes the
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:
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
Hi,
On Fri, Aug 21, 2009 at 11:33 AM, Matthew Brettmatthew.br...@gmail.com 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,
On Fri, Aug 21, 2009 at 11:33 AM, Matthew Brettmatthew.br...@gmail.com
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
On Fri, Aug 21, 2009 at 2:51 PM, Matthew Brettmatthew.br...@gmail.com 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
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
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 jumpahead
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 just in a
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=(z2.3).nonzero()[0] # operation
2009/8/21 Nicolas Pinto pi...@mit.edu:
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
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?
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
26 matches
Mail list logo
