On Mon, Apr 2, 2012 at 7:14 PM, Tim Cera t...@cerazone.net wrote:
I think the suggestion is pad(a, 5, mode='mean'), which would be
consistent with common numpy signatures. The mode keyword should probably
have a default, something commonly used. I'd suggest 'mean', Nathaniel
suggests 'zero',
The idea of using constants instead of strings throughout NumPy is an
interesting one, but should be pushed to another thread and not hold up this
particular PR.
I like the suggestion of Nathaniel. Let's get the PR committed with a
single-function interface. I like having the array as the
On Mon, Apr 2, 2012 at 12:09 PM, Travis Oliphant tra...@continuum.iowrote:
The idea of using constants instead of strings throughout NumPy is an
interesting one, but should be pushed to another thread and not hold up
this particular PR.
I like the suggestion of Nathaniel. Let's get the PR
On Mon, Apr 2, 2012 at 10:36 AM, Tim Cera t...@cerazone.net wrote:
On Mon, Apr 2, 2012 at 12:09 PM, Travis Oliphant tra...@continuum.iowrote:
The idea of using constants instead of strings throughout NumPy is an
interesting one, but should be pushed to another thread and not hold up
this
I like the strings, maybe that is not the best, but yes I would like to defer
that discussion. Having the string representation does allow 'pad()' to make
some checks on inputs to the built in functions.
About whether to have pad('mean', a, 5) or pad(a, 'mean', 5) - I don't
care. It
I think the suggestion is pad(a, 5, mode='mean'), which would be
consistent with common numpy signatures. The mode keyword should probably
have a default, something commonly used. I'd suggest 'mean', Nathaniel
suggests 'zero', I think either would be fine.
I can't type fast enough. :-) I
On the one hand it is nice to be explicit. On the other hand it is nice to
have keyword arguments.
In this case it is very true that pad(a) would not be very clear. Most clear,
though, would be: pad(a, width=5, mode='mean'). You could use keyword
arguments with None as the default and
1) The use of string constants to identify NumPy processes. It would
seem better to use library defined constants (ufuncs?) for better
future-proofing, maintenance, etc.
I don't see how this would help with future-proofing or maintenance --
can you elaborate?
If this were C, I'd agree;
I like where this is going.
Driven by a desire to avoid a million different methods on a single
class, we've done something similar in our library.
So instead of
thing.mean()
thing.max(...)
etc.
we have:
thing.scrunch(MEAN, ...)
thing.scrunch(MAX, ...)
etc.
Where the
On Fri, Mar 30, 2012 at 8:35 AM, Richard Hattersley
rhatters...@gmail.com wrote:
I like where this is going.
Driven by a desire to avoid a million different methods on a single
class, we've done something similar in our library.
So instead of
thing.mean()
thing.max(...)
etc.
we
On Thu, Mar 29, 2012 at 6:53 PM, Tim Cera t...@cerazone.net wrote:
If instead you passed in a function:
def padwithzeros(vector, pad_width, iaxis, **kwargs):
bvector = np.zeros(pad_width[0])
avector = np.zeros(pad_width[1])
return bvector, avector
b =
On Fri, Mar 30, 2012 at 5:41 AM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Mar 29, 2012 at 6:53 PM, Tim Cera t...@cerazone.net wrote:
If instead you passed in a function:
def padwithzeros(vector, pad_width, iaxis, **kwargs):
bvector = np.zeros(pad_width[0])
On Fri, Mar 30, 2012 at 1:22 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Mar 30, 2012 at 5:41 AM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Mar 29, 2012 at 6:53 PM, Tim Cera t...@cerazone.net wrote:
If instead you passed in a function:
def padwithzeros(vector,
I rearranged your questions.
Why is this function allocating new arrays that will just be
copied into the big array and then discarded, instead of filling in
the big array directly? (Again, this is a speed issue.)
My example in the e-mail was incorrect (sorry about that). The way it
actually
My suggestion is:
Step 1: Change the current PR so that it has only one user-exposed
function, something like pad(..., mode=foo), and commit that.
Everyone seems to pretty much like that interface, implementing it
would take 1 hour of work, and then the basic functionality would be
landed
On Fri, Mar 30, 2012 at 2:20 PM, Tim Cera t...@cerazone.net wrote:
My suggestion is:
Step 1: Change the current PR so that it has only one user-exposed
function, something like pad(..., mode=foo), and commit that.
Everyone seems to pretty much like that interface, implementing it
would take 1
On Wed, Mar 28, 2012 at 6:08 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
I think there is also a question of using a prefix pad_xxx for the
function names as opposed to pad.xxx.
If I had it as pad.mean, pad.median, ...etc. then someone could
from numpy.pad import *
a =
On Thu, Mar 29, 2012 at 7:55 AM, Tim Cera
I think there is also a question of using a prefix pad_xxx for the
function names as opposed to pad.xxx.
Namespaces are one honking great idea -- let's do more of those!
If I had it as pad.mean, pad.median, ...etc. then someone could
from
While namespaces are a really good idea, I'm not a big fan of both module
namespaces and underscore namespaces. It seems pretty redundant to me to have
pad.pad_mean.
On the other hand, one could argue that pad.mean could be confused with
calculating the mean of a padded array. So, it
On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant tra...@continuum.io wrote:
While namespaces are a really good idea, I'm not a big fan of both module
namespaces and underscore namespaces. It seems pretty redundant to me to
have pad.pad_mean.
On the other hand, one could argue that pad.mean
On Thu, Mar 29, 2012 at 10:38 AM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant tra...@continuum.io
wrote:
While namespaces are a really good idea, I'm not a big fan of both
module
namespaces and underscore namespaces. It seems pretty redundant to
On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant tra...@continuum.io wrote:
While namespaces are a really good idea, I'm not a big fan of both module
namespaces and underscore namespaces. It seems pretty redundant to me to
On Thu, Mar 29, 2012 at 5:45 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Thu, Mar 29, 2012 at 10:38 AM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant tra...@continuum.io
wrote:
While namespaces are a really good idea, I'm not a big fan
On Mar 29, 2012, at 11:52 AM, Nathaniel Smith wrote:
On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant tra...@continuum.io wrote:
While namespaces are a really good idea, I'm not a big fan of both module
namespaces and
I was hoping pad would get finished some day. Maybe 1.9?
Alright - I do like the idea of passing a function to pad, with a bunch of
pre-made functions in place.
Maybe something like:
a = np.arange(10)
b = pad('mean', a, 2, stat_length=3)
where if the first argument is a string, use
On Thu, Mar 29, 2012 at 11:53 AM, Tim Cera t...@cerazone.net wrote:
I was hoping pad would get finished some day. Maybe 1.9?
Well, you *did* ask ;-)
Alright - I do like the idea of passing a function to pad, with a bunch of
pre-made functions in place.
Maybe something like:
a =
On Mar 29, 2012, at 12:53 PM, Tim Cera wrote:
I was hoping pad would get finished some day. Maybe 1.9?
You have been a great sport about this process. I think it will result in
something quite nice.
Alright - I do like the idea of passing a function to pad, with a bunch of
I have been developing a set of pad functions to pad arrays in different
ways. Really close to having it accepted into numpy, but I want to revisit
an implementation issue that I have become worried about. Should these
functions be collected into a 'pad' namespace or put raw into np.lib?
Do I
On Wed, Mar 28, 2012 at 9:31 PM, Tim Cera t...@cerazone.net wrote:
I have been developing a set of pad functions to pad arrays in different
ways. Really close to having it accepted into numpy, but I want to revisit
an implementation issue that I have become worried about. Should these
On Wed, Mar 28, 2012 at 1:57 PM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Wed, Mar 28, 2012 at 9:31 PM, Tim Cera t...@cerazone.net wrote:
I have been developing a set of pad functions to pad arrays in different
ways. Really close to having it accepted into numpy, but I want to
30 matches
Mail list logo
