On Wed, Sep 9, 2009 at 9:47 PM, Sturla Molden wrote:
> James Bergstra skrev:
>> Suppose you want to evaluate "dot(a*b+c*sqrt(d), e)". The GPU is
>> great for doing dot(),
> The CPU is equally great (or better?) for doing dot(). In both cases:
>
> - memory access scale O(n) for dot producs.
> - com
On 10-Sep-09, at 12:47 AM, Sturla Molden wrote:
> The CPU is equally great (or better?) for doing dot(). In both cases:
>
> - memory access scale O(n) for dot producs.
> - computation scale O(n) for dot producs.
> - memory is low
> - computation is fast (faster for GPU)
You do realize that the th
James Bergstra skrev:
> Suppose you want to evaluate "dot(a*b+c*sqrt(d), e)". The GPU is
> great for doing dot(),
The CPU is equally great (or better?) for doing dot(). In both cases:
- memory access scale O(n) for dot producs.
- computation scale O(n) for dot producs.
- memory is low
- computat
George Dahl skrev:
> I know that for my work, I can get around an order of a 50-fold
speedup over
> numpy using a python wrapper for a simple GPU matrix class. So I
might be
> dealing with a lot of matrix products where I multiply a fixed 512 by
784 matrix
> by a 784 by 256 matrix that chan
On 9-Sep-09, at 4:48 AM, Francesc Alted wrote:
> Yes, this later is supported in PyTables as long as the underlying
> filesystem
> supports files > 2 GB, which is very usual in modern operating
> systems.
I think the OP said he was on Win32, in which case it should be noted:
FAT32 has its u
Ruben Salvador wrote:
> Your results are what I expected...but. This code is called from my main
> program, and what I have in there (output array already created for both
> cases) is:
>
> print "lambd", lambd
> print "np.shape(a)", np.shape(a)
> print "np.shape(r)", np.shape(r)
> print "np.shap
On Wed, Sep 9, 2009 at 11:40, Christopher Barker wrote:
> Robert Kern wrote:
>> On Wed, Sep 9, 2009 at 07:15, Darren Dale wrote:
>> We aren't supposed to break APIs that aren't related to the 2-3
>> transition. PEP3118 is related to the 2-3 transition. Since I'm that
>> somebody that always pipes u
Robert Kern wrote:
> On Wed, Sep 9, 2009 at 07:15, Darren Dale wrote:
> We aren't supposed to break APIs that aren't related to the 2-3
> transition. PEP3118 is related to the 2-3 transition. Since I'm that
> somebody that always pipes up about this topic, I'm pretty sure it
> hasn't been PEP3118-r
Dag Sverre Seljebotn wrote:
> Darren Dale wrote:
>> On Tue, Sep 8, 2009 at 9:02 PM, David Cournapeau wrote:
>>> On Wed, Sep 9, 2009 at 9:37 AM, Darren Dale wrote:
Hi David,
> I already gave my own opinion on py3k, which can be summarized as:
> - it is a huge effort, and no core numpy/
On Wed, Sep 9, 2009 at 11:25 AM, Charles R
Harris wrote:
>
>
> On Wed, Sep 9, 2009 at 7:15 AM, Darren Dale wrote:
>>
>> On Tue, Sep 8, 2009 at 9:02 PM, David Cournapeau
>> wrote:
>> > On Wed, Sep 9, 2009 at 9:37 AM, Darren Dale wrote:
>> >> Hi David,
>> >
>> >>> I already gave my own opinion on py
Darren Dale wrote:
> On Tue, Sep 8, 2009 at 9:02 PM, David Cournapeau wrote:
>> On Wed, Sep 9, 2009 at 9:37 AM, Darren Dale wrote:
>>> Hi David,
I already gave my own opinion on py3k, which can be summarized as:
- it is a huge effort, and no core numpy/scipy developer has
expressed
Christopher Barker wrote:
> George Dahl wrote:
>> Sturla Molden molden.no> writes:
>>> Teraflops peak performance of modern GPUs is impressive. But NumPy
>>> cannot easily benefit from that.
>
>> I know that for my work, I can get around an order of a 50-fold speedup over
>> numpy using a pytho
On Wed, Sep 9, 2009 at 10:41 AM, Francesc Alted wrote:
>> Numexpr mainly supports functions that are meant to be used element-wise,
>> so the operation/element ratio is normally 1 (or close to 1). In these
>> scenarios is where improved memory access is much more important than CPU
>> (or, for th
On Wed, Sep 9, 2009 at 7:15 AM, Darren Dale wrote:
> On Tue, Sep 8, 2009 at 9:02 PM, David Cournapeau
> wrote:
> > On Wed, Sep 9, 2009 at 9:37 AM, Darren Dale wrote:
> >> Hi David,
> >
> >>> I already gave my own opinion on py3k, which can be summarized as:
> >>> - it is a huge effort, and no c
On Wed, Sep 9, 2009 at 06:25, John [H2O] wrote:
>
> Hello,
>
> I've started to rely more and more on f2py to create simple modules
> utilizing Fortran for efficiency. This is a great tool to have within
> Python!
>
> A problem, however, is that unlike python modules, the reload() function
> does no
On Wed, Sep 9, 2009 at 07:15, Darren Dale wrote:
> Another topic concerning documentation is API compatibility. The
> python devs have requested projects not use the 2-3 transition as an
> excuse to change their APIs, but numpy is maybe a special case. I'm
> thinking about PEP3118. Is numpy going
A Wednesday 09 September 2009 11:26:06 Francesc Alted escrigué:
> A Tuesday 08 September 2009 23:21:53 Christopher Barker escrigué:
> > Also, perhaps a GPU-aware numexpr could be helpful which I think is the
> > kind of thing that Sturla was refering to when she wrote:
> >
> > "Incidentally, this
Received from Francesc Alted on Wed, Sep 09, 2009 at 05:18:48AM EDT:
(snip)
> The point here is that matrix-matrix multiplications (or, in general,
> functions with a large operation/element ratio) are a *tiny* part of all the
> possible operations between arrays that NumPy supports. This is w
I forgot...just in case:
rsalva...@cactus:~$ python --version
Python 2.5.2
python-scipy: version 0.6.0
On Wed, Sep 9, 2009 at 2:36 PM, Ruben Salvador wrote:
> Your results are what I expected...but. This code is called from my main
> program, and what I have in there (output array already crea
Your results are what I expected...but. This code is called from my main
program, and what I have in there (output array already created for both
cases) is:
print "lambd", lambd
print "np.shape(a)", np.shape(a)
print "np.shape(r)", np.shape(r)
print "np.shape(offspr)", np.shape(offspr)
t = clock()
On Tue, Sep 8, 2009 at 9:02 PM, David Cournapeau wrote:
> On Wed, Sep 9, 2009 at 9:37 AM, Darren Dale wrote:
>> Hi David,
>
>>> I already gave my own opinion on py3k, which can be summarized as:
>>> - it is a huge effort, and no core numpy/scipy developer has
>>> expressed the urge to transition t
I am sorry but it doesn't make much sense.
How do you measure the performance?
Are you sure you include the creation of the "c" output array in the time spent
(which is outside the for loop but should be considered anyway)?
Here are my results...
In [84]: a = np.random.rand(8,26)
In [85]: b = n
Hello,
I've started to rely more and more on f2py to create simple modules
utilizing Fortran for efficiency. This is a great tool to have within
Python!
A problem, however, is that unlike python modules, the reload() function
does not seem to update the f2py modules within ipython (which I use
e
Wed, 09 Sep 2009 13:08:22 +0200, Ruben Salvador wrote:
> Perfect! Thank you very much :D
>
> It's not obvious, though...I think I should read more deeply into
> Python/NumPy...but for the use I'm giving to it...
>
> Anyway, I thought the pythonic way would be faster, but after trying
> with a siz
Perfect! Thank you very much :D
It's not obvious, though...I think I should read more deeply into
Python/NumPy...but for the use I'm giving to it...
Anyway, I thought the pythonic way would be faster, but after trying with a
size 8 instead of 8...the for loop is faster!
Pythonic time ==> 0.3
Hi Ruben
One dimensional arrays can be thought of as rows. If you want a column, you
need to append a dimension.
>>> d = a + b[:,None]
which is equivalent to
>>> d = a + b[:,np.newaxis]
Best,
Luca
___
NumPy-Discussion mailing list
NumPy-Discussion@sc
Hi there!
I'm sure I'm missing something, but I am not able of doing a simple sum of
two arrays with different dimensions. I have a 2D array and a 1D array
np.shape(a) (8, 26)
np.shape(b) (8,)
and I want to sum each *row* of 'a' with the equivalent *row* of 'b' (this
is, summing each 1D row arra
the way I do my rotations is this:
tmat = rotation matrix
vec = stack of row vectors
rotated_vecs = np.dot(tmat, vec.T).T
On Mon, Sep 7, 2009 at 6:53 PM, T J wrote:
> On Mon, Sep 7, 2009 at 3:43 PM, T J wrote:
>> Or perhaps I am just being dense.
>>
>
> Yes. I just tried to reinvent standard
A Wednesday 09 September 2009 10:48:48 Francesc Alted escrigué:
> OTOH, having the possibility to manage compressed data buffers
> transparently in NumPy would help here, but not there yet ;-)
Now that I think about it, in case the data is compressible, Daniel could try
to define a PyTables' comp
A Tuesday 08 September 2009 23:21:53 Christopher Barker escrigué:
> Also, perhaps a GPU-aware numexpr could be helpful which I think is the
> kind of thing that Sturla was refering to when she wrote:
>
> "Incidentally, this will also make it easier to leverage on modern GPUs."
Numexpr mainly sup
A Tuesday 08 September 2009 21:19:05 George Dahl escrigué:
> Sturla Molden molden.no> writes:
> > 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, b
A Wednesday 09 September 2009 07:22:33 David Cournapeau escrigué:
> On Wed, Sep 9, 2009 at 2:10 PM, Sebastian Haase wrote:
> > Hi,
> > you can probably use PyTables for this. Even though it's meant to
> > save/load data to/from disk (in HDF5 format) as far as I understand,
> > it can be used to mak
32 matches
Mail list logo
