Hello all,
The short version: For a given NxN array, is there an efficient way to use a
moving window to collect a summary statistic on a chunk of the array, and
insert it into another array?
The long version: I am trying to resample an image loaded with GDAL into an NxN
array. Note that this
On Wed, Jul 21, 2010 at 8:24 PM, Charles R Harris
wrote:
>
> On Wed, Jul 21, 2010 at 5:44 PM, Keith Goodman wrote:
>> Can someone confirm that the copy in np.linalg.lstsq
>>
>> bstar[:b.shape[0],:n_rhs] = b.copy()
>>
>> is not needed? I'm assuming that ndarray.__setitem__ never gives a
>> view o
On Wed, Jul 21, 2010 at 5:44 PM, Keith Goodman wrote:
> On Wed, Jul 21, 2010 at 4:35 PM, Skipper Seabold
> wrote:
> > On Tue, Jul 20, 2010 at 10:24 PM, Keith Goodman
> wrote:
> >> Good point. Looks like we can get rid of 2 copies! I didn't get rid of
> >> the second copy but I did cut things do
I hope I won't get identified as a spam bot :-). While I have not resolved
the problem itself, this is an issue that I cannot reproduce on our
cluster. I wanted to get back with some actual timings from the real
hardware we are going to be using and some details about the matrices, so
as not to cha
Hello everyone,
First of all, let me apologize for my earlier message; I made the mistake
of trying to indent my code using SquirrelMail's horrible interface -- and
pressing Tab and Space resulted in sending my (incomplete) e-mail to the
list. Cursed be Opera's keyboard shortcuts now :-).
I'm cur
Hello everyone,
I'm currently planning to use a Python-based infrastructure for our HPC
project.
I've previously used NumPy and SciPy for basic scientific computing tasks,
but
performance hasn't been quite an issue for me until now. At the moment I'm
not too
sure as to what to do next though, and
On Wed, Jul 21, 2010 at 4:35 PM, Skipper Seabold wrote:
> On Tue, Jul 20, 2010 at 10:24 PM, Keith Goodman wrote:
>> Good point. Looks like we can get rid of 2 copies! I didn't get rid of
>> the second copy but I did cut things down just to see what the timing
>> was like. I also threw out the abi
On Wed, Jul 21, 2010 at 7:25 PM, David Warde-Farley wrote:
> On 2010-07-20, at 10:16 PM, Skipper Seabold wrote:
>
>> Out of curiosity, is there an explicit way to check if these share memory?
>
>
> You could do the exact calculations (I think) but this isn't actually
> implemented in NumPy, thoug
On Tue, Jul 20, 2010 at 10:24 PM, Keith Goodman wrote:
> Good point. Looks like we can get rid of 2 copies! I didn't get rid of
> the second copy but I did cut things down just to see what the timing
> was like. I also threw out the ability to handle complex numbers (only
> saves an if iscomplex s
On 2010-07-20, at 10:16 PM, Skipper Seabold wrote:
> Out of curiosity, is there an explicit way to check if these share memory?
You could do the exact calculations (I think) but this isn't actually
implemented in NumPy, though np.may_share_memory is a conservative test for it
that will err on
On Wed, Jul 21, 2010 at 5:48 PM, Keith Goodman wrote:
> On Wed, Jul 21, 2010 at 2:32 PM, Rob Speer wrote:
>> I agree with the idea that axis labels must be strings.
>>
>> Yes, this is the opposite of my position on tick labels ("names"), but
>> there's a reason: ticks are often defined by whateve
Take it as a reminder: when reporting an error or problem, even if it
doesn't seem relevant, always provide version number. :-)
DG
On Wed, Jul 21, 2010 at 12:50 PM, Mark Bakker wrote:
> I am using 1.3.0.
> Glad to hear it is correct in 1.4.0
> Sorry for bothering you with an old version, but I
On Wed, Jul 21, 2010 at 2:32 PM, Rob Speer wrote:
> I agree with the idea that axis labels must be strings.
>
> Yes, this is the opposite of my position on tick labels ("names"), but
> there's a reason: ticks are often defined by whatever data you happen
> to be working with, but axis labels will
Make that +2.
--Josh
On Wed, Jul 21, 2010 at 1:38 PM, Skipper Seabold wrote:
> On Wed, Jul 21, 2010 at 5:32 PM, Rob Speer wrote:
>> I agree with the idea that axis labels must be strings.
>>
>> Yes, this is the opposite of my position on tick labels ("names"), but
>> there's a reason: ticks are
On Wed, Jul 21, 2010 at 5:32 PM, Rob Speer wrote:
> I agree with the idea that axis labels must be strings.
>
> Yes, this is the opposite of my position on tick labels ("names"), but
> there's a reason: ticks are often defined by whatever data you happen
> to be working with, but axis labels will
I agree with the idea that axis labels must be strings.
Yes, this is the opposite of my position on tick labels ("names"), but
there's a reason: ticks are often defined by whatever data you happen
to be working with, but axis labels will in the vast majority of
situations be defined by the program
My code had a bug:
idx_by_name = dict((n,i) for i,n in enumerate(d.dtype.names))
On Wed, Jul 21, 2010 at 4:49 PM, Pauli Virtanen wrote:
> Wed, 21 Jul 2010 16:22:37 -0400, wheres pythonmonks wrote:
>> However: is there an automatic way to convert a named index to a
>> position?
>
> It's not rea
Wed, 21 Jul 2010 16:22:37 -0400, wheres pythonmonks wrote:
> However: is there an automatic way to convert a named index to a
> position?
It's not really a named index -- it's a field name. Since the fields of
an array element can be of different size, they cannot be referred to
with an array in
On Jul 21, 2010, at 4:35 PM, wheres pythonmonks wrote:
> What about:
>
> idx_by_name = dict(enumerate(d.dtype.names))
>
> Then I can look up the index of the columns I want before the loop,
> and then access by the index during the loop.
Sure. Why don't you try both approaches, time them and d
What about:
idx_by_name = dict(enumerate(d.dtype.names))
Then I can look up the index of the columns I want before the loop,
and then access by the index during the loop.
- W
On Wed, Jul 21, 2010 at 4:29 PM, Pierre GM wrote:
>
> On Jul 21, 2010, at 4:22 PM, wheres pythonmonks wrote:
>
>> How
On Jul 21, 2010, at 4:22 PM, wheres pythonmonks wrote:
> However: is there an automatic way to convert a named index to a position?
>
> What about looping over tuples of my recarray:
>
> for t in d:
>date = t['Date']
>
Why don't you use zip ?
>>> for (date, t) in (d['Date'], d)
T
However: is there an automatic way to convert a named index to a position?
What about looping over tuples of my recarray:
for t in d:
date = t['Date']
I guess that the above does have to lookup 'Date' each time.
But the following does not need the hash lookup for each tuple:
for t
I am using 1.3.0.
Glad to hear it is correct in 1.4.0
Sorry for bothering you with an old version, but I am very happy with this
feature!
Mark
> What version of numpy are you using? That docstring was updated in that
> fashion about 8 mo. ago (at least in the Wiki; I'm not sure exactly when it
>
Thank you very much better crack open a numpy reference manual
instead of relying on my python "intuition".
On Wed, Jul 21, 2010 at 3:44 PM, Pauli Virtanen wrote:
> Wed, 21 Jul 2010 15:12:14 -0400, wheres pythonmonks wrote:
>
>> I have an recarray -- the first column is date.
>>
>> I have th
Wed, 21 Jul 2010 15:12:14 -0400, wheres pythonmonks wrote:
> I have an recarray -- the first column is date.
>
> I have the following function to compute the number of unique dates in
> my data set:
>
>
> def byName(): return(len(list(set(d['Date'])) ))
What this code does is:
1. d['Date']
On Wed, Jul 21, 2010 at 15:12, wheres pythonmonks
wrote:
> I have an recarray -- the first column is date.
>
> I have the following function to compute the number of unique dates in
> my data set:
>
>
> def byName(): return(len(list(set(d['Date'])) ))
>
> Question: is the string 'Date' looked up
On Wed, Jul 21, 2010 at 1:00 PM, Keith Goodman wrote:
> On Wed, Jul 21, 2010 at 11:41 AM, Vincent Davis
> wrote:
>> On Wed, Jul 21, 2010 at 11:08 AM, Keith Goodman wrote:
>>> On Wed, Jul 21, 2010 at 9:56 AM, John Salvatier
>>> wrote:
I don't really know much about this topic, but what abou
I have an recarray -- the first column is date.
I have the following function to compute the number of unique dates in
my data set:
def byName(): return(len(list(set(d['Date'])) ))
Question: is the string 'Date' looked up at each iteration? If so,
this is dumb, but explains my horrible perfor
On Wed, Jul 21, 2010 at 11:41 AM, Vincent Davis
wrote:
> On Wed, Jul 21, 2010 at 11:08 AM, Keith Goodman wrote:
>> On Wed, Jul 21, 2010 at 9:56 AM, John Salvatier
>> wrote:
>>> I don't really know much about this topic, but what about a flag at array
>>> creation time (or whenever you define lab
On Wed, Jul 21, 2010 at 11:08 AM, Keith Goodman wrote:
> On Wed, Jul 21, 2010 at 9:56 AM, John Salvatier
> wrote:
>> I don't really know much about this topic, but what about a flag at array
>> creation time (or whenever you define labels) that says whether valid
>> indexes will be treated as lab
On Wed, Jul 21, 2010 at 10:58 AM, M Trumpis wrote:
> Separately, regarding the permissible axis labels, I think we must not
> allow any enumerated axis labels (ie, ints and floats). I don't
> remember if there was a consensus about that yesterday. We don't have
> the flexibility in the ndarray AP
On Wed, Jul 21, 2010 at 10:08 AM, Keith Goodman wrote:
> On Wed, Jul 21, 2010 at 9:56 AM, John Salvatier
> wrote:
>> I don't really know much about this topic, but what about a flag at array
>> creation time (or whenever you define labels) that says whether valid
>> indexes will be treated as lab
On Wed, Jul 21, 2010 at 10:41 AM, Bruce Southey wrote:
> The current implemented option of allowing strings is the only practical
> option and I think that most other related languages also impose this
> constraint. Otherwise we will effectively break compatibility with Python
> and numpy because
On 07/21/2010 11:56 AM, John Salvatier wrote:
I don't really know much about this topic, but what about a flag at
array creation time (or whenever you define labels) that says whether
valid indexes will be treated as labels or indexes for that array?
On Wed, Jul 21, 2010 at 9:37 AM, Keith Good
On Wed, Jul 21, 2010 at 9:56 AM, John Salvatier
wrote:
> I don't really know much about this topic, but what about a flag at array
> creation time (or whenever you define labels) that says whether valid
> indexes will be treated as labels or indexes for that array?
It's an interesting idea. My gu
What version of numpy are you using? That docstring was updated in that
fashion about 8 mo. ago (at least in the Wiki; I'm not sure exactly when it
was merged, but it does appear that way in version 1.4.0).
DG
I am using linalg.solve to solve a system of linear equations. As I have to
> solve m
I don't really know much about this topic, but what about a flag at array
creation time (or whenever you define labels) that says whether valid
indexes will be treated as labels or indexes for that array?
On Wed, Jul 21, 2010 at 9:37 AM, Keith Goodman wrote:
> About a dozen people attended what
About a dozen people attended what was billed as a continuation of the
SciPy 2010 datarray BoF. We met at UC Berkeley on July 19 as part of
the py4science series.
A datarray is a subclass of a Numpy array that adds the ability to
label the axes and to label the elements along each axis.
We spent
Thanks, Pauli. import_array() is what I was missing.
Warren
Pauli Virtanen wrote:
> Tue, 20 Jul 2010 18:04:42 -0500, Warren Weckesser wrote:
> [clip]
>
>> I've made some progress, and now I'm getting a bus error. With the
>> following extension module, calling example.foo results in a bus
Hello list,
I am using linalg.solve to solve a system of linear equations.
As I have to solve multiple systems with the same matrix, but different
right-hand sides, I tried to make the right-hand side a matrix and that
works fine.
So the docstring should say:
Solve the equation ``a x = b`` fo
ke, 2010-07-21 kello 10:46 +0200, David Cournapeau kirjoitti:
[clip: assert nulps]
> I think we should go toward using those almost everywhere we need
> floating point comparison in testing,
I think we also need an assertion function that behaves like np.allclose
-- the ULPs are somewhat unintuiti
On Tue, Jul 20, 2010 at 3:31 AM, Ondrej Certik wrote:
> Hi,
>
> I was always using something like
>
> abs(x-y) < eps
>
> or
>
> (abs(x-y) < eps).all()
>
> but today I needed to also make sure this works for larger numbers,
> where I need to compare relative errors, so I found this:
>
> http://www.
Hi Keith!
On Mon, Jul 19, 2010 at 6:40 PM, Keith Goodman wrote:
> On Mon, Jul 19, 2010 at 6:31 PM, Ondrej Certik wrote:
>> Hi,
>>
>> I was always using something like
>>
>> abs(x-y) < eps
>>
>> or
>>
>> (abs(x-y) < eps).all()
>>
>> but today I needed to also make sure this works for larger numbe
Tue, 20 Jul 2010 18:04:42 -0500, Warren Weckesser wrote:
[clip]
> I've made some progress, and now I'm getting a bus error. With the
> following extension module, calling example.foo results in a bus error,
> regardless of the arguments given. The error occurs in the call to
> PyArg_ParseTuple.
Hi,
I find myself often looking for a numpy function that would behave like
an inverse compress. E.g. one that satisfies a.compress(mask) = b, given
b and mask, creating a. Or like a createFromMask function, which would
create an array with shape of a given boolean mask, and filling all
elemen
45 matches
Mail list logo
