Re: [Numpy-discussion] In-place operations

El dt 12 de 09 del 2006 a les 13:28 -0600, en/na Travis Oliphant va escriure: > >[BTW, numpy.empty seems twice as slower in my machine. Why? > > > > > Timer("a=numpy.empty(1,dtype=numpy.complex128)", "import > > > >numpy").repeat(3,1) > >[0.37033700942993164, 0.31780

Re: [Numpy-discussion] In-place operations

Hi, one word in advance, instead of optimizing it is advisable to seek for a way to refactorize the algorithm using smaller arrays, since this kind of optimization almost certainly reduces readability. If you do it, comment well. ;-) If you have very large arrays and want to do some arithmetic

[Numpy-discussion] PHAlxcRMA

Hi   QUIT OVE t RPA e YIN a G FOR YOU e R P o HAR z MAC j Y   S u AV k E u p p to 50 w % wi v th http://www.prlawoec.com- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with

[Numpy-discussion] numpy-1.0b5 can't find ATLAS

Hello, when I try to build numpy-1.0b5 it doesn't find my ATLAS libraries. I had to build hem from scratch (version 3.7.17) and the compile went well. I have installed them under /scratch/python2.4/atlas furthermore, I have blas and lapack installed under /scatch/python2.4/lib I adjusted

[Numpy-discussion] Avoiding array-scalar arithmetic?

Hi all, I'm migrating an application from Numeric to numpy, and I've run into a significant application slowdown related to arithmetic on array-scalars. The inner loop of the application is integrating a nonlinear set of differential equations using odeint, with the rhs a dynamically-generated

Re: [Numpy-discussion] Avoiding array-scalar arithmetic?

Ryan Gutenkunst wrote: > Hi all, > > I'm migrating an application from Numeric to numpy, and I've run into a > significant application slowdown related to arithmetic on array-scalars. > > Yeah, that is a common thing. There are two factors: 1) array indexing and 2) array scalar math. I do

[Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

I'd like to make the first release-candidate of NumPy 1.0 this weekend. Any additions wanting to make the first official release candidate should be checked in by then. -Travis - Using Tomcat but need to do more? Need to s

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

Hello all I just ran NumPy and SciPy through Valgrind, and everything looks clean on that the NumPy side. Some other things that could be fixed for RC1: - GCC 4.1.1 warning in ufuncobject.c: numpy/core/src/ufuncobject.c: In function âPyUFunc_RegisterLoopForTypeâ: numpy/core/src/ufuncobject.c:32

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

Hi! I would like to hear about three tickets I submitted some time ago: Ticket #230 a**2 not executed as a*a if a.dtype = int32 is this easy to fix ? Ticket #229 numpy.random.poisson(0) should return 0 I hope there is agreement that the edge-case of 0 should/could be handled without rais

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

Sebastian Haase wrote: > Hi! > I would like to hear about three tickets I submitted some time ago: > > Ticket #230 a**2 not executed as a*a if a.dtype = int32 > is this easy to fix ? > > Fixed. Now, all arrays with a**2 are executed as a*a (float arrays are still executed as square(a) (is

[Numpy-discussion] iscomplex on strings

Hi, I was surprised by this - but maybe I shouldn't have been: In [7]:iscomplex('a') Out[7]:True In [8]:iscomplex(u'a') Out[8]:True Best, Matthew - Using Tomcat but need to do more? Need to support web services, security?

Re: [Numpy-discussion] Problem with concatenate and object arrays

Hi, > For example, if you do array([a,b,c]).shape(), the answer is normally > (3,) unless a b and c happen to all be lists of the same length, at > which point your array could have a much more complicated shape... but > as the person who wrote "array([a,b,c])" it's tempting to assume that > the r

Re: [Numpy-discussion] Problem with concatenate and object arrays

On 9/13/06, Matthew Brett <[EMAIL PROTECTED]> wrote: Hi,> For example, if you do array([a,b,c]).shape(), the answer is normally> (3,) unless a b and c happen to all be lists of the same length, at> which point your array could have a much more complicated shape... but > as the person who wrote "arr

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

On 9/13/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: I'd like to make the first release-candidate of NumPy 1.0 this weekend.Any additions wanting to make the first official release candidateshould be checked in by then.There are a few cleanups and added functionality I have in mind but nothing th

Re: [Numpy-discussion] In-place operations

On 9/13/06, Francesc Altet <[EMAIL PROTECTED]> wrote: El dt 12 de 09 del 2006 a les 13:28 -0600, en/na Travis Oliphant vaescriure:> >[BTW, numpy.empty seems twice as slower in my machine. Why?> >> >> Timer("a=numpy.empty (1,dtype=numpy.complex128)", "import> > > >numpy").repeat(3,10

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

Travis Oliphant wrote: >> Ticket #188 dtype should have nicer str representation >> Is this one now officially dead ? >> ">but str() should rather return 'int32 (little endian)' >> > It's not necessarily dead, the problem is complexity of implementation > and more clarity about h

Re: [Numpy-discussion] [Numpy-tickets] [NumPy] #235: r_, c_, hstack, vstack, column_stack should be made more consistent

Travis, what is the "new string directives as the first element of the item tuple" !? I always liked the idea of having a "shortest possible" way for creating (or concatenating) rows with "r_" *and* columns with "c_" ! Why did the "c_" have to be removed !? Thanks, Sebastan NumPy wrote: >

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

Charles R Harris wrote: > > > On 9/13/06, *Travis Oliphant* <[EMAIL PROTECTED] > > wrote: > > I'd like to make the first release-candidate of NumPy 1.0 this > weekend. > > Any additions wanting to make the first official release candidate > should be check

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

Sebastian Haase wrote: > Travis Oliphant wrote: > > >> It's not necessarily dead, the problem is complexity of implementation >> and more clarity about how all dtypes are supposed to be printed, not >> just this particular example. A patch would be very helpful here. If >> desired it could

Re: [Numpy-discussion] [Numpy-tickets] [NumPy] #235: r_, c_, hstack, vstack, column_stack should be made more consistent

Sebastian Haase wrote: > Travis, > what is the "new string directives as the first element of the item > tuple" !? > These have been there for a while, but I recently added a couple of capabilities. > I always liked the idea of having a "shortest possible" way for creating > (or concatena

Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend

Travis Oliphant wrote: > I'd like to make the first release-candidate of NumPy 1.0 this weekend. > > Any additions wanting to make the first official release candidate > should be checked in by then. > > -Travis > > > - > Usin