Albert Strasheim wrote:
> Hello all
>
> I recently started looking at David Cournapeau's PyEM package, specifically
> his implementation of the K-Means algorithm. He implemented part of this
> algorithm with in pure Python version and also provided a Pyrex alternative
> that is significantly faster
Hello all
> -Original Message-
> From: Travis Oliphant [mailto:[EMAIL PROTECTED]
> Sent: 03 October 2006 03:51
> To: Discussion of Numerical Python; Albert Strasheim
> Subject: Re: ***[Possible UCE]*** Re: [Numpy-discussion] Vectorizing
> code, for loops, and all that
>
>
> >Meanwhile,
Hi,
I was wondering if there was any way to speed up the following code:
y = N.zeros((n, K))
for i in range(K):
y[:, i] = gauss_den(data, mu[i, :], va[i, :])
Where K is of order 1e1, n of order 1e5. Normally, gauss_den is a quite
expensive function, but the profiler tells me that t
Albert Strasheim wrote:
>>> [1] 12.97% of function time
>>> [2] 8.65% of functiont ime
>>> [3] 62.14% of function time
>>>
>>> If statistics from elsewhere in the code would be helpful, let me
>>> know,
>>>
>> and
>>
>>> I'll see if I can convince Quantify to cough it up.
>>>
>>>
I'm going to have to put off release of rc2 for Friday. I'm just too
busy right now. That might help us get some speed-ups into the
NOBUFFER_UFUNCLOOP code as well.
My speed-up ideas are:
1) Only keep track of 1 set of coordinates instead of self->nargs sets
(1 for each iterator).
2) Keep t
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\kenny>cd c:\lameness
C:\lameness>c:\Python24\python.exe templatewindow.py
a = [[ 1.00013175e+00 2.63483019e-05 1.6740e+00 5.22246363e-05
1.8735e+00 -2.77694969e-07 -1.307
Travis Oliphant wrote:
> Albert Strasheim wrote:
>
[1] 12.97% of function time
[2] 8.65% of functiont ime
[3] 62.14% of function time
If statistics from elsewhere in the code would be helpful, let me
know,
>>> and
>>>
>>>
[EMAIL PROTECTED] wrote:
>Microsoft Windows XP [Version 5.1.2600]
>(C) Copyright 1985-2001 Microsoft Corp.
>
>C:\Documents and Settings\kenny>cd c:\lameness
>
>C:\lameness>c:\Python24\python.exe templatewindow.py
>a = [[ 1.00013175e+00 2.63483019e-05 1.6740e+00 5.22246363e-05
>1.000
[EMAIL PROTECTED] wrote:
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> C:\Documents and Settings\kenny>cd c:\lameness
>
> C:\lameness>c:\Python24\python.exe templatewindow.py
> a = [[ 1.00013175e+00 2.63483019e-05 1.6740e+00 5.22246363e-05
>
David Cournapeau wrote:
> Hi,
>
> I was wondering if there was any way to speed up the following code:
>
> y = N.zeros((n, K))
> for i in range(K):
> y[:, i] = gauss_den(data, mu[i, :], va[i, :])
>
> Where K is of order 1e1, n of order 1e5. Normally, gauss_den is a quite
> expensive f
Hi,
I thought that numpy.isscalar was a good way of distinguising a numpy scalar
from a python scalar, but it seems not:
>>> numpy.isscalar(numpy.string_('3'))
True
>>> numpy.isscalar('3')
True
Is there an easy (and fast, if possible) way to check whether an object is a
numpy scalar or a pytho
Yeah thanks guys, I printed them out the size and realized what it was doing
then used a for loop to put it into the 1D array, but thanks Travis the way
you said makes it easier than the for loop.
-Kenny
-
Take Surveys. E
Hi,
a noticed the underscore in "numpy.string_" ...
I thought the underscores were removed in favour of handling the
"from numpy import *" separately via the __all__ variable.
Is this done only for *some* members of numpy ?
(sorry for hijacking your thread ...)
-Sebastian Haase
On Tuesday 03
Francesc Altet wrote:
> Hi,
>
> I thought that numpy.isscalar was a good way of distinguising a numpy scalar
> from a python scalar, but it seems not:
>
>
numpy.isscalar(numpy.string_('3'))
> True
>
numpy.isscalar('3')
> True
>
> Is there an easy (and fa
In article <[EMAIL PROTECTED]>, Todd Miller <[EMAIL PROTECTED]>
wrote:
> Russell E. Owen wrote:
> > Has anyone tried to build numarray or Numeric with python 2.5? Since the
> >
> numarray builds and runs fine for Python-2.5, but only as 32-bit.
> > type of array index was changed, I'm wond
Sebastian Haase wrote:
>Hi,
>a noticed the underscore in "numpy.string_" ...
>I thought the underscores were removed in favour of handling the
>"from numpy import *" separately via the __all__ variable.
>Is this done only for *some* members of numpy ?
>
>
Yeah. The underscores are still on th
Tim Hochberg wrote:
>Francesc Altet wrote:
>
>
>>Hi,
>>
>>I thought that numpy.isscalar was a good way of distinguising a numpy scalar
>>from a python scalar, but it seems not:
>>
>>
>>
>>
>numpy.isscalar(numpy.string_('3'))
>
>
>
>>True
>>
>>
>>
>>
excuse my laziness for not looking this up, I googled it but could not find
a solution.
matlab has a
isreal(array)
where if the array is full of real numbers the value returned is 1.
I'm translating matlab code and ran across
if ~isreal(array)
array = abs(array)
Is there a way to check to se
numpy.isreal(a) is a "top level" function (i.e., not a class member
function) in numpy; here's its help doc:
Help on function isreal in module numpy.lib.type_check:
isreal(x)
Return a boolean array where elements are True if that element
is real (has zero imaginary part)
For scal
PS: The Python built in function (i.e., you don't even need numpy for
this) abs(x) is "vectorized" (i.e., accepts a (nested) sequence, incl.
numpy array, argument) and overloaded to give the modulus (i.e.,
Pythagorean "length") of a complex number when such is its argument.
DG
Kenny Ortmann w
Kenny Ortmann wrote:
> excuse my laziness for not looking this up, I googled it but could not find
> a solution.
> matlab has a
> isreal(array)
> where if the array is full of real numbers the value returned is 1.
> I'm translating matlab code and ran across
>
> if ~isreal(array)
> array = abs
David L Goldsmith wrote:
> PS: The Python built in function (i.e., you don't even need numpy for
> this) abs(x) is "vectorized" (i.e., accepts a (nested) sequence, incl.
> numpy array, argument) and overloaded to give the modulus (i.e.,
> Pythagorean "length") of a complex number when such is i
Thanks Tim,
DG
Tim Hochberg wrote:
> David L Goldsmith wrote:
>
>> PS: The Python built in function (i.e., you don't even need numpy for
>> this) abs(x) is "vectorized" (i.e., accepts a (nested) sequence, incl.
>> numpy array, argument) and overloaded to give the modulus (i.e.,
>> Pythagor
> There may be a better way, but::
>
>alltrue(isreal(x))
>
> Would work. As would:
>
>not sometrue(x.imag)
>
> In the above test you are already negating the test, so you could just
> drop the not.
>> and if so is
>> there a way to extract the(a + ib) because the absolute value of a
>> co
Kenny Ortmann wrote:
>> There may be a better way, but::
>>
>>alltrue(isreal(x))
>>
>> Would work. As would:
>>
>>not sometrue(x.imag)
>>
>> In the above test you are already negating the test, so you could just
>> drop the not.
>>
>>> and if so is
>>> there a way to extract the(a + i
On 02/10/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Perhaps those inner 1-d loops could be optimized (using prefetch or
> something) to reduce the number of cache misses on the inner
> computation, and the concept of looping over the largest dimension
> (instead of the last dimension) should
On Monday 02 October 2006 23:53, Travis Oliphant wrote:
> This is a Python 2.5 issue (the new __index__ method) was incorrectly
> implemented and allowing a 1-d array to be interpreted as an index.
>
> This should be fixed in SVN.
Ok, thank you. I tried that but the version of python-svn is 2.6 a
On Tue, Oct 03, 2006 at 11:53:22AM +0200, Lars Bittrich wrote:
> On Monday 02 October 2006 23:53, Travis Oliphant wrote:
> > This is a Python 2.5 issue (the new __index__ method) was incorrectly
> > implemented and allowing a 1-d array to be interpreted as an index.
> > This should be fixed in SV
Has anyone implemented an easier or more efficient way to broadcast arrays to a
common shape at the Python level? I was hoping that the broadcast iterator would
actually provide the broadcasted arrays, but it does not.
I've attached my best pure-Python effort.
--
Robert Kern
"I have come to b
On 03/10/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> I had an idea regarding which axis to operate on first. Rather than
> operate on strictly the longest axis or strictly the innermost axis, a
> hybrid approach could be used. We would operate on the longest axis that
> would not result in the i
Hello all
I recently started looking at David Cournapeau's PyEM package,
specifically his implementation of the K-Means algorithm. He
implemented part of this algorithm with in pure Python version and
also provided a Pyrex alternative that is significantly faster (about
10 times with the data I te
On 03/10/06, Robert Kern <[EMAIL PROTECTED]> wrote:
> Has anyone implemented an easier or more efficient way to broadcast arrays to
> a
> common shape at the Python level? I was hoping that the broadcast iterator
> would
> actually provide the broadcasted arrays, but it does not.
How about vecto
Er, is this the PyEM in question?
It doesn't have much of a web presence...
http://www.ar.media.kyoto-u.ac.jp/members/david/
--bb
On 10/3/06, David Cournapeau <[EMAIL PROTECTED]> wrote:
> Albert Strasheim wrote:
> > Hello all
> >
> > I recently started looking at David Cournapeau's PyEM packag
Hello all
> -Original Message-
> From: Travis Oliphant [mailto:[EMAIL PROTECTED]
> Sent: 03 October 2006 03:51
> To: Discussion of Numerical Python; Albert Strasheim
> Subject: Re: ***[Possible UCE]*** Re: [Numpy-discussion] Vectorizing code,
> for loops, and all that
>
>
> >Meanwhile,
A. M. Archibald wrote:
> On 03/10/06, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Has anyone implemented an easier or more efficient way to broadcast arrays
>> to a
>> common shape at the Python level? I was hoping that the broadcast iterator
>> would
>> actually provide the broadcasted arrays, but
On 04/10/06, Robert Kern <[EMAIL PROTECTED]> wrote:
Yeah, a segfault would be problematic. Otherwise, it works and is in fact faster
than what I wrote.
It's a bit tricky to trigger but I think it was fixed in 1.0rc1 (in
changeset 3125, in fact:
http://projects.scipy.org/scipy/numpy/changeset/3
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 48 hours on the queue on
externalmx-1.sourceforge.net.
The message identifier is: 1GUFPK-0001wW-5k
The date of the message is:
37 matches
Mail list logo
