Jonathan,I had a patch for this that applied to numarray way back when. If folks feel there is a need, I could probably try to get it running on numpy. Bit of a learning curve (for me), though.Chuck
On 6/2/06, Jonathan Taylor <[EMAIL PROTECTED]> wrote:
I was wondering if there was an easy way to ge
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:
[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'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
t
Rob Hooft wrote:
> Christopher Barker wrote:
> | Did you time them? And yours only handles integers.
>
> Yes I did, check the attachment of my previous message for a python
> module to time the three,
Sorry about that, I don't notice that.
> with completely different results from yours
> (I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Barker wrote:
| Did you time them? And yours only handles integers.
Yes I did, check the attachment of my previous message for a python
module to time the three, with completely different results from yours
(I'm using Numeric). The attachm
Alan G Isaac wrote:
> On Fri, 02 Jun 2006, Robert Kern apparently wrote:
>
>>My point is that there is no need to change rand() and randn() to the "new"
>>interface. The "new" interface is already there: random.random() and
>>random.standard_normal().
>
> Yes of course; that has always been
>> On Fri, 02 Jun 2006, Robert Kern apparently wrote:
>>> Changing the API of rand() and randn() doesn't solve any
>>> problem. Removing them might.
> Alan G Isaac wrote:
>> I think this is too blunt an argument. For example,
>> use of the old interface might issue a deprecation warning.
>>
Alan G Isaac wrote:
> On Fri, 02 Jun 2006, Robert Kern apparently wrote:
>
>>Changing the API of rand() and randn() doesn't solve any
>>problem. Removing them might.
>
> I think this is too blunt an argument. For example,
> use of the old interface might issue a deprecation warning.
> This wo
On Fri, 2 Jun 2006 19:09:01 +0200
Joris De Ridder <[EMAIL PROTECTED]> wrote:
> Just to be sure, what exactly is affected when one uses the slower
> algorithms when neither BLAS or LAPACK is installed? For sure it
> will affect almost every function in numpy.linalg, as they use
> LAPACK_lite. And
On Fri, 2 Jun 2006 10:27:45 +0200
Joris De Ridder <[EMAIL PROTECTED]> wrote:
>[CB]: I was reacting to a post a while back that suggested
> pointing people [CB]: searching for numpy to the main scipy page,
> which I did not think was a [CB]: good idea.
>
> That would be my post :o)
>
> The rea
On Fri, 02 Jun 2006, Robert Kern apparently wrote:
> Changing the API of rand() and randn() doesn't solve any
> problem. Removing them might.
I think this is too blunt an argument. For example,
use of the old interface might issue a deprecation warning.
This would make it very likely that all
Alan G Isaac wrote:
> On Fri, 02 Jun 2006, Sven Schreiber apparently wrote:
>
>>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. ... Can anybody offer
>>an intuition/explanation?
>
>
Christopher Barker wrote:
> Robert Kern wrote:
>> x = repeat(x, ny)
>> y = concatenate([y] * nx)
>> points = transpose([x, y])
>
> Somehow I never think to use repeat. And why use repeat for x and
> concatenate for y?
I guess you could use repeat() on y[newaxis] and then flatten it.
y = repeat(
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
>>
On Fri, 02 Jun 2006, Sven Schreiber apparently wrote:
> 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. ... Can anybody offer
> an intuition/explanation?
Backward compatability, I bel
Eric Jonas wrote:
> Is there some way, either within numpy or at build-time, to verify
> you're using BLAS/LAPACK? Is there one we should be using?
>
>
Check to see if the id of numpy.dot is the same as
numpy.core.multiarray.dot
-Travis
___
Numpy
Is there some way, either within numpy or at build-time, to verify
you're using BLAS/LAPACK? Is there one we should be using?
...Eric
On Fri, 2006-06-02 at 11:19 -0600, Travis Oliphant wrote:
> Joris De Ridder wrote:
> > Just to be sure, what exactly is affected when one uses the
A Divendres 02 Juny 2006 19:07, Travis Oliphant va escriure:
> Robert Kern wrote:
> > Filip Wasilewski wrote:
> >> So the next question is what's the difference between matrixmultiply and
> >> dot in NumPy?
> >
> > matrixmultiply is a deprecated compatibility name. Always use dot. dot
> > will get
Joris De Ridder wrote:
> Just to be sure, what exactly is affected when one uses the slower
> algorithms when neither BLAS or LAPACK is installed? For sure it
> will affect almost every function in numpy.linalg, as they use
> LAPACK_lite. And I guess that in numpy.core the dot() function
> uses t
Just to be sure, what exactly is affected when one uses the slower
algorithms when neither BLAS or LAPACK is installed? For sure it
will affect almost every function in numpy.linalg, as they use
LAPACK_lite. And I guess that in numpy.core the dot() function
uses the lite numpy/core/blasdot/_dotb
Joris De Ridder wrote:
> On Friday 02 June 2006 14:58, Eric Jonas wrote:
>[EJ]: Hello! I've been using numeric for a while, and the recent list
> traffic
>[EJ]: prompted me to finally migrate all my old code. On a whim, we were
>[EJ]: benchmarking numpy vs numeric and have been lead to
Robert Kern wrote:
> Filip Wasilewski wrote:
>
>
>> So the next question is what's the difference between matrixmultiply and
>> dot in NumPy?
>>
>
> matrixmultiply is a deprecated compatibility name. Always use dot. dot will
> get
> replaced with the optimized dotblas implementation when a
Robert Kern wrote:
As I need Numeric and numarray compatibility at this point, it seems the
Ah. It might help if you said that up front.
Yes, it would, but that would mean accepting that I need to keep
backward compatibility -- I'm still hoping!
x = arange(minx, maxx+step, step) # oy.
y
Filip Wasilewski wrote:
> So the next question is what's the difference between matrixmultiply and
> dot in NumPy?
matrixmultiply is a deprecated compatibility name. Always use dot. dot will get
replaced with the optimized dotblas implementation when an optimized BLAS is
available. matrixmultiply
Sven Schreiber wrote:
> 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
[EMAIL PROTECTED] wrote:
> Hi,
>
> maybe is not what you meant, but presently I'm looking for a sparse
> eigenvalue solver. As far as I've understood the ARPACK bindings are
> still missing. This library is one of the most used, so I think it
> would be very useful to have integrated in numpy.
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 becau
favorable
numpy creates arrays much faster, fft seems a tad faster
a useful metric, I think, for O-scope and ADC apps
I get
0.0039054614015815738
0.0019759541205486885
0.023268623246481726
0.0023570392204637913
from the below on a PIII 600...
from time import *
n=4096
r = range(n)
#numpy
impor
Yes, using numpy.dot I get 250ms, numpy.matrixmultiply 11.8s.
while a sans-BLAS Numeric.matrixmultiply takes 12s.
The first 100 results from numpy.dot and numpy.matrixmultiply are identical
Use dot;)
--George.
On 02/06/06, Filip Wasilewski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It seems tha
Hi,
It seems that in Numeric the matrixmultiply is alias for dot function,
which "uses the BLAS optimized routines where possible", as the help()
says.
In NumPy (0.9.6, not upgraded yet to 0.9.8), the matrixmultiply is a
function of numpy.core.multiarray, while dot refers to
numpy.core._dotblas.
I meant "numeric is slower than numpy", that is, modern numpy (0.9.8)
appears to lose out majorly to numeric. This doesn't make much sense, so
I figured there was something wrong with my benchmark, or my numpy
install, and wanted to check if others had seen this sort of behavior.
On Friday 02 June 2006 14:58, Eric Jonas wrote:
[EJ]: Hello! I've been using numeric for a while, and the recent list traffic
[EJ]: prompted me to finally migrate all my old code. On a whim, we were
[EJ]: benchmarking numpy vs numeric and have been lead to the conclusion that
[EJ]: nu
Hello! I've been using numeric for a while, and the recent list traffic
prompted me to finally migrate all my old code. On a whim, we were
benchmarking numpy vs numeric and have been lead to the conclusion that
numpy is at least 50x slower; a 1000x1000 matmul takes 16 sec in numpy
but 300 ms in num
Hi,
maybe is not what you meant, but presently I'm looking for a sparse
eigenvalue solver. As far as I've understood the ARPACK bindings are
still missing. This library is one of the most used, so I think it
would be very useful to have integrated in numpy.
Riccardo
La gar
[CB]: I was reacting to a post a while back that suggested pointing people
[CB]: searching for numpy to the main scipy page, which I did not think was
a
[CB]: good idea.
That would be my post :o)
The reasons why I suggested this are
1) www.scipy.org is at the moment the most informa
36 matches
Mail list logo
