The inefficiency comes in the generic iteration and construction of int
objects needed by the builtin sum function. Using the native numarray sum
method on each row is much much faster, summing over the axis directly even
faster still:
t1=time.time()
highEnough=myMat>0.6
greaterPerLine=[x.sum()
As soon as I posted that I realized it's due to the type conversions from True
to 1. For some reason, this
---
myMat=scipy.randn(500,500)
t1=time.time()
highEnough=(myMat>0.6)+0
greaterPerLine=[sum(x) for x in highEnough]
elapsed1=time.time()-t1
print("method 1 took %f seconds"%elapsed1)
---
rem
Hi Everyone,
I'm new to numpy, and I'm finding it hard to predict what is fast in
python/numpy and what is slow. The following seems puzzling: I am doing the
same thing an ugly way and a cleaner way. But the ugly map/lambda/filter
expression is 15x faster than using numpy's internals.
Can anyon
On 3/10/07, Robert Kern <[EMAIL PROTECTED]> wrote:
Jouni K. Seppänen wrote:
> I think that either the docstring (and the book) should be corrected
> to mention the assumption, or the code should be made to work in the
> arbitrary case.
This is the current docstring:
In [2]: setmember1d?
Type:
Sebastian Haase wrote:
> Sorry for being so dense - what do the numbers mean ?
> S.H.
>
Sorry for being unclear. The numbers are the number of responses for
the category. There were 7 total responses for NumPy, all at the
college/university level, and 3 respondents cited physics/astronomy as
Sorry for being so dense - what do the numbers mean ?
S.H.
On 3/10/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote:
> Thanks to all who responded to my question about teaching array
> programming. I've compiled a brief summary of the responses.
>
> NumPy
> =
> * Subject
> - Physics/Astronom
Hi,
Myself and a friend of mine were surprised that we did not get emailed
when someone commented on a bug reports we made on the numpy or scipy
TRAC bug tracker system.
(I started at some point adding an explicit CC entry for myself :-( )
I just googled for this, an I found that in a
trac.ini
Thanks to all who responded to my question about teaching array
programming. I've compiled a brief summary of the responses.
NumPy
=
* Subject
- Physics/Astronomy 3
- Biotechnology 1
- Engineering 2
- Microeconomics 1
* Level
- College/University 7
J
=
* Subject
- Math 1
Mark P. Miller wrote:
> Robert: Just a thought on this topic:
>
> Would it be possible for the Scipy folks to add a new module based
> solely off your old mtrand code (pre-broadcast)? I have to say that the
> mtrand code from numpy 0.9.8 has some excellent advantages over the core
> python ra
Jouni K. Seppänen wrote:
> I think that either the docstring (and the book) should be corrected
> to mention the assumption, or the code should be made to work in the
> arbitrary case.
This is the current docstring:
In [2]: setmember1d?
Type: function
Base Class:
Namespace: I
On 3/9/07, David M. Cooke <[EMAIL PROTECTED]> wrote:
On Fri, 9 Mar 2007 16:11:28 +
[EMAIL PROTECTED] wrote:
> Hi,
>
> I've done a patch for allowing compiling the last version of numexpr
with
> the MSVC Toolkit 2003 compiler on Windows platforms. You can fetch it
> from:
>
> http://www.pyta
On 10 Mar 2007 16:57:30 +, Alexander Schmolck <[EMAIL PROTECTED]>
wrote:
"Simon Wood" <[EMAIL PROTECTED]> writes:
> To all,
> I came across an old thread in the archives in which Alexander Schmolck
gave
> an example of a Matlab like matrix formatter he authored for Python. Is
this
> formatt
Robert: Just a thought on this topic:
Would it be possible for the Scipy folks to add a new module based
solely off your old mtrand code (pre-broadcast)? I have to say that the
mtrand code from numpy 0.9.8 has some excellent advantages over the core
python random number generators.
This woul
"Simon Wood" <[EMAIL PROTECTED]> writes:
> To all,
> I came across an old thread in the archives in which Alexander Schmolck gave
> an example of a Matlab like matrix formatter he authored for Python. Is this
> formatter still available some where?
Yup. I've still got it as part of a matrix clas
Hi,
According to an earlier posting on this list, the elements of the
first argument to setmember1d are assumed to be unique:
http://thread.gmane.org/gmane.comp.python.numeric.general/13251/focus=13307
The docstring for setmember1d does not state this:
| Definition: numpy.setmember1d(ar1, a
15 matches
Mail list logo
