On Sun, Jul 15, 2012 at 2:40 PM, Charles R Harris
wrote:
> I was thinking of adding quickselect, but if you have made a start ... go
> for it.
This is territory where I personally am fearful to tread - I'm no
developer, but I am an awfully good alpha/beta tester! I can go back
to the archives and
Hi,
A couple of years ago there was a flurry of work partially at my
instigation at SciPy 2009 to build a better median function based on a
select algorithm rather than a sort algorithm. It seemed that it had
progressed quite far, but the code in lib/function_base.py still uses
a sort. Has the sel
> On 08/06/12 14:14, Neal Becker wrote:
>> The fact that this proposed numpy behavior would not match python list
>> behavior
>> holds little weight for me. I would still favor this change, unless it added
>> significant overhead. My opinion, of course.
As a "Joe User", I think using the [-2:2]
Hi,
On Fri, Aug 21, 2009 at 11:33 AM, Matthew Brett wrote:
> Nicolas investigated algorithms that find the lower (or upper) median
> value. The lower median is the median iff there are an odd number of
> entries in our list, or the lower of the central values in the sort,
> when there are an even
I presented this during a lightning talk at the scipy conference
yesterday, so again, at the risk of painting myself as a flaming
idiot:
-
Wanted: A Better/Faster median() Function
numpy implementation uses simple sorting algorithm:
Sort all the data using the .sort() method
R
On Wed, Nov 12, 2008 at 2:09 PM, David Huard <[EMAIL PROTECTED]> wrote:
>
> Mike, before patching, please take a look at the tickets related to
> histogram on the numpy trac. Previously, histogram returned only used the
> left bin edges and it caused a lot of problems with outliers and
> normalizat
On Wed, Nov 12, 2008 at 4:30 AM, Scott Sinclair <[EMAIL PROTECTED]> wrote:
>> "Mike Ressler" <[EMAIL PROTECTED]> 11/12/08 1:19 AM
>> I did an update to a Fedora 9 workstation yesterday that included
>> updating numpy to 1.2.0 and matplotlib 0.98.3 (pyth
I did an update to a Fedora 9 workstation yesterday that included
updating numpy to 1.2.0 and matplotlib 0.98.3 (python version is
2.5.1). This seems to have played havoc with some of the histogram
plotting we do. I was aware of the histogram changes in 1.2.0, but
something doesn't seem to have wor
On Mon, May 12, 2008 at 5:41 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Joris De Ridder wrote:
> > As Mike, I'm a bit sceptic about the whole idea. The current way
> > doesn't seem broken, so why fix it?
>
> If the recent events do not show that something went wrong, I don't know
> what
On Sun, May 11, 2008 at 7:59 PM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to know how people feel about going toward a time-based
> release process for numpy (and scipy).
-1
I'm just a common user, but please, no. The big Linux distros do this
and it drives me n
Thanks, Robert, for the quick response.
On 9/11/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> There are operations you can express with this form that you couldn't if the
> behavior that you expected were the case whereas you can get the result you
> want
> relatively straightforwardly.
>
> In [6]
The following seems to be a wart: is it expected?
Set up a 10x10 array and some indexing arrays:
a=arange(100)
a.shape=(10,10)
q=array([0,2,4,6,8])
r=array([0,5])
Suppose I want to extract only the "even" numbered rows from a - then
print a[q,:]
Every fifth column:
print a[:,r]
Only the
What versions of python and numpy are you using?
On 6/18/07, Sturla Molden <[EMAIL PROTECTED]> wrote:
> Problem 3: No 64 bit support on Windows or Linux:
>
> On Linux, large files must be memory mapped using mmap64 (or mmap2 if 4k
> boundaries are acceptable). On Windows, CreateFileMapping/MapView
Bumped into the following in numpy-1.0.2 and 1.0.3 (of course :-) on
both 32-bit and 64-bit linux boxes:
>>> import numpy as nm
>>> a=nm.zeros(100,dtype='Int32')-3
>>> nm.median(a)
-3.0
>>> a=nm.zeros(100,dtype='Int16')-3
>>> nm.median(a)
Warning: overflow encountered in short_
On 2/21/07, Alexander Michael <[EMAIL PROTECTED]> wrote:
> ... T is to large to fit in memory, so I need to
> load up H, perform my calculations, pop the oldest N x P slice and
> push the newest N x P slice into the data cube. What's the best way to
> do this that will maintain fast computations al
15 matches
Mail list logo
