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
On Sun, Jul 15, 2012 at 2:40 PM, Charles R Harris
charlesr.har...@gmail.com 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
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] syntax
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
Hi,
On Fri, Aug 21, 2009 at 11:33 AM, Matthew Brettmatthew.br...@gmail.com 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,
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 (python version is
They reported that the Fedora 9
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
normalization.
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 will
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 nuts.
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]:
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,
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_scalars
2768.0
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 along
13 matches
Mail list logo
