[Numpy-discussion] Style for pad implementation in 'pad' namespace or functions under np.lib
Fri Mar 30 02:35:49 CDT 2012
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
Where the constants like MEAN and MAX encapsulate the process to be
performed - including a reference to a NumPy/user-defined aggregation
function, as well as some other transformation details.
We then found we could reuse the same constants in other operations:
So I have two minor concerns with the current proposal.
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.
2) Why does only "pad" use this style of interface? If it's a good
idea for "pad", perhaps it should be applied more generally?
numpy.aggregate(MEAN, ...), numpy.group(MEAN, ...), etc. anyone?
On 30 March 2012 02:55, Travis Oliphant <email@example.com> wrote:
> 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
> 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 one of the built in functions.
> If instead you passed in a function:
> def padwithzeros(vector, pad_width, iaxis, **kwargs):
> bvector = np.zeros(pad_width)
> avector = np.zeros(pad_width)
> return bvector, avector
> b = pad(padwithzeros, a, 2)
> Would that have some goodness?
> NumPy-Discussion mailing list
More information about the NumPy-Discussion