On Wed, Mar 28, 2012 at 1:57 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:

On Wed, Mar 28, 2012 at 9:31 PM, Tim Cera <tim@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 functions be collected into a 'pad' namespace or put raw into np.lib?

Do I really care about this? Not really since it isn't a utility issue, but I contend that it would look better to pull these functions into their own namespace.

+1 one for a separate 'pad' or 'padding' namespace. Adding 10 functions to the main numpy namespace feels like too much.

I think there is also a question of using a prefix pad_xxx for the function names as opposed to pad.xxx. Chuck

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 numpy.pad import *     a = np.arange(5)     # then you would have a confusing     b = mean(a, 2)

exactly why no one should *ever* do import *! pad.mean is not more typing than pad_mean so there in NO reason to use the latter, except to have a C style, rather than python namespaces.... ANd what if someone DOES want to override mean?: from np.pad import mean and now they can do mean(something) and it's explicite what they mean to do. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R            (206) 526-6959   voice 7600 Sand Point Way NE   (206) 526-6329   fax Seattle, WA  98115       (206) 526-6317   main reception Chris.Barker@noaa.gov

On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant <travis@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 could be confused with calculating the mean of a padded array.   So, it seems like the function names need to be called something more than just "mean, median, etc." Something like padwith_mean, padwith_median, etc. actually makes more sense.   Or pad.with_mean, pad.with_median.   The with_ in this case is not really a "namespace" it's an indication of functionality.

Perhaps it should be pad(..., mode="mean") , mode="" is only a few more characters than _with_, and this would make it much easier to write functions whose API looks like: wavelet_decompose(..., pad_mode=....) Also it would solve the namespace question :-). -- Nathaniel

On Thu, Mar 29, 2012 at 5:45 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:

On Thu, Mar 29, 2012 at 10:38 AM, Nathaniel Smith <njs@pobox.com> wrote:

...

On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant <travis@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 could be confused with calculating the mean of a padded array.   So, it seems like the function names need to be called something more than just "mean, median, etc." Something like padwith_mean, padwith_median, etc. actually makes more sense.   Or pad.with_mean, pad.with_median.   The with_ in this case is not really a "namespace" it's an indication of functionality.

Perhaps it should be  pad(..., mode="mean")

, mode="" is only a few more characters than _with_, and this would make it much easier to write functions whose API looks like:    wavelet_decompose(..., pad_mode=....)

Also it would solve the namespace question :-).

I like this idea. I'd leave the current functions in the module for those who want to import a particular padding type, but import the pad(..., mode="xxx") into the numpy namespace.

Your call, but that's about 500 lines of highly-redundant docstrings to maintain, just to save the occasional person from having to type one line: def pad_with_mean(*args, **kwargs): np.lib.pad(*args, mode="mean", **kwargs) The unified implementation really is just PADDERS = {"mean": _mean, "median": _median, ...} return _loop_across(array, pad_width, _PADDERS[mode], constant_values=constant_values, end_values=end_values) -- Nathaniel

Hello William, It's just a matter of importing numpy into IronPython. See also, http://enthought.com/repo/.iron/NumPySciPyforDotNet.pdf - Ilan On Thu, Mar 29, 2012 at 12:47 PM, William Johnston <williamj@tenbase2.com> wrote:

Hello,

Can numpy for .NET be used in a DLR C# application?

Regards, William Johnston

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Hello, My email server went down. Did anyone respond to this post? Thanks, William Johnston -----Original Message----- From: William Johnston Sent: Thursday, March 29, 2012 5:59 PM To: Discussion of Numerical Python Subject: \*\*\*\*\*SPAM\*\*\*\*\* Re: [Numpy-discussion] \*\*\*\*\*SPAM\*\*\*\*\* Re: Numpy forIronPython 2.7 DLR app? Ilan: Thanks for your post. I can import from the command-line and IronPython console, but not from a C# DLR app (using embedded python scripts.) Any suggestions? Regards, William Johnston -----Original Message----- From: Ilan Schnell Sent: Thursday, March 29, 2012 3:11 PM To: Discussion of Numerical Python Subject: \*\*\*\*\*SPAM\*\*\*\*\* Re: [Numpy-discussion] Numpy for IronPython 2.7 DLR app? Hello William, It's just a matter of importing numpy into IronPython. See also, http://enthought.com/repo/.iron/NumPySciPyforDotNet.pdf - Ilan On Thu, Mar 29, 2012 at 12:47 PM, William Johnston <williamj@tenbase2.com> wrote:

Hello,

Can numpy for .NET be used in a DLR C# application?

Regards, William Johnston

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith <njs@pobox.com> wrote:

On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant <travis@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 could be confused with calculating the mean of a padded array.   So, it seems like the function names need to be called something more than just "mean, median, etc." Something like padwith_mean, padwith_median, etc. actually makes more sense.   Or pad.with_mean, pad.with_median.   The with_ in this case is not really a "namespace" it's an indication of functionality.

Perhaps it should be  pad(..., mode="mean")

, mode="" is only a few more characters than _with_, and this would make it much easier to write functions whose API looks like:    wavelet_decompose(..., pad_mode=....)

Also it would solve the namespace question :-).

-- Nathaniel

...And on looking at the pull request for a bit, it would let us combine 10 distinct single-line functions that (with highly redundant docstrings) take up ~600 lines of code. The interfaces are *almost* identical; the exceptions are: -- "reflect" and "symmetric" take and "even"/"odd" argument -- "pad_constant" takes an argument specifying the constant to pad with -- "pad_linear_ramp" takes an argument specifying the end value of the linear ramp The first two can be easily handled by just combining it into the mode, so we have "reflect", "reflect_odd", "symmetric", "symmetric_odd", so that just leaves two mode-specific arguments. I wouldn't feel bad about leaving those in as unused arguments for most modes. We might even want to combine them into a single argument -- normally I'm against such "simplifications", but the semantics really are quite similar. And final advantage: we could later extend this interface to also support mode=user_specified_callable for custom padding modes, since this is basically how the underlying code already works. (Though I'm not quite sure the interface for the individual pad mode functions like _mean and _median is the one we'd want to expose to users.) -- Nathaniel

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 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[0]) avector = np.zeros(pad_width[1]) return bvector, avector b = pad(padwithzeros, a, 2) Would that have some goodness? Kindest regards, Tim

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[0]) avector = np.zeros(pad_width[1]) return bvector, avector

b = pad(padwithzeros, a, 2)

Would that have some goodness?

+1 -Travis

On Fri, Mar 30, 2012 at 8:35 AM, Richard Hattersley <rhattersley@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 have:   thing.scrunch(MEAN, ...)   thing.scrunch(MAX, ...)   etc. 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:   thing.scrunch(MEAN, ...)   thing.squish(MEAN, ...)   thing.rolling_squish(MEAN, ...)

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.

I don't see how this would help with future-proofing or maintenance -- can you elaborate? If this were C, I'd agree; using an enum would have a number of benefits: -- easier to work with than strings (== and switch work, no memory management hassles) -- compiler will notice if you accidentally misspell the enum name -- since you always in effect 'import *', getting access to additional constants doesn't require any extra effort But in Python none of these advantages apply, so I find it more convenient to just use strings. Note also that we couldn't use ufuncs here, because we're specifying a rather unusual sort of operation -- there is no ufunc for padding with a linear ramp etc. Using "mean" as the example is misleading in this respect -- it's not really the same as np.mean.

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?

The mode="foo" interface style is actually used in other places, e.g., np.linalg.qr. -- Nathaniel

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 first argument to that function (it is more consistent). They keyword can be called mode or method Tim, what do you think of that? Further developments can happen in a separate PR. -Travis On Mar 31, 2012, at 3:07 PM, Richard Hattersley wrote:

...

...

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; using an enum would have a number of benefits: -- easier to work with than strings (== and switch work, no memory management hassles) -- compiler will notice if you accidentally misspell the enum name -- since you always in effect 'import *', getting access to additional constants doesn't require any extra effort But in Python none of these advantages apply, so I find it more convenient to just use strings.

Using constants provides for tab-completion and associated help text. The help text can be particularly useful if the choice of constant affects which extra keyword arguments can be specified.

And on a minor note, and far more subjectively (time for another bike-shedding reference!), there's the "cleanliness" of API. (e.g. Strings don't "feel" a good match. There are an infinite number of strings, but only a small number are valid. There's nothing machine-readable you can interrogate to find valid values.) Under the hood you'll have to use the string to do a lookup, but the constant can *be* the result of the lookup. Why re-invent the wheel when the language gives it to you for free?

...

Note also that we couldn't use ufuncs here, because we're specifying a rather unusual sort of operation -- there is no ufunc for padding with a linear ramp etc. Using "mean" as the example is misleading in this respect -- it's not really the same as np.mean.

...

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?

The mode="foo" interface style is actually used in other places, e.g., np.linalg.qr.

My mistake - I misinterpreted the API earlier, so we're talking at cross-purposes. My comment/question isn't really about pad & mode, but about numpy more generally. But it still stands - albeit somewhat hypothetically, since it's hard to imagine such a change taking place.

Richard _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Mon, Apr 2, 2012 at 10:36 AM, Tim Cera <tim@cerazone.net> wrote:

On Mon, Apr 2, 2012 at 12:09 PM, Travis Oliphant <travis@continuum.io>wrote:

...

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 first argument to that function (it is more consistent). They keyword can be called mode or method

Tim, what do you think of that? Further developments can happen in a separate PR.

Current pull request has a single pad function with the mode/method/whatever you call it as a string OR function as the first argument.

pad('mean', a, 5) pad('median', a, 7) pad(paddingfunction, a, 2) ...etc.

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 seems like we have two votes for the later form (Travis and Nathaniel) and unless others weigh in, I will make the change soonish.

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. Chuck

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 should say that I can't type faster than Travis since he has already responded.... Currently that '5' in the example above is the keyword argument 'pad_width' which defaults to 1. So really the only argument then is 'a'? Everything else is keywords? I missed that in the discussion and I am not sure that it is a good idea. In fact as I am typing this I am thinking that we should have pad_width as an argument. I hate to rely on this, because it tends to get overused, but 'Explicit is better than implicit.' 'pad(a)' would carry a lot of implicit baggage that would mean it would be very difficult to figure out what was going on if reading someone else's code. Someone unfamiliar with the pad routine must consult the documentation to figure out what 'pad(a)' meant whereas "pad(a, 'mean', 1)", regardless of the order of the arguments, would actually read pretty well. I defer to a 'consensus' - whatever that might mean, but I am actually thinking that the input array, mode/method, and the pad_width should be arguments. The order of the arguments - I don't care. I realize that this thread is around 26 messages long now, but if everyone who is interested in this could weigh in one more time about this one issue. To minimize discussion on the list, you can add a comment to the pull request at https://github.com/numpy/numpy/pull/242 Kindest regards, Tim

On Mon, Apr 2, 2012 at 7:14 PM, Tim Cera <tim@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', I think either would be fine.

I can't type fast enough.  :-)  I should say that I can't type faster than Travis since he has already responded....

Currently that '5' in the example above is the keyword argument 'pad_width' which defaults to 1.  So really the only argument then is 'a'?  Everything else is keywords?  I missed that in the discussion and I am not sure that it is a good idea. In fact as I am typing this I am thinking that we should have pad_width as an argument.  I hate to rely on this, because it tends to get overused, but 'Explicit is better than implicit.'

'pad(a)' would carry a lot of implicit baggage that would mean it would be very difficult to figure out what was going on if reading someone else's code.  Someone unfamiliar with the pad routine must consult the documentation to figure out what 'pad(a)' meant whereas "pad(a, 'mean', 1)", regardless of the order of the arguments, would actually read pretty well.

I defer to a 'consensus' - whatever that might mean, but I am actually thinking that the input array, mode/method, and the pad_width should be arguments.  The order of the arguments  - I don't care.

I realize that this thread is around 26 messages long now, but if everyone who is interested in this could weigh in one more time about this one issue.  To minimize discussion on the list, you can add a comment to the pull request at https://github.com/numpy/numpy/pull/242

I guess I'll say def pad(arr, width, mode="constant", **kwargs): Or, if we don't want to have a default argument for mode (and maybe we don't -- my suggestion of giving it a default was partly based on the assumption that it was pretty obvious what the default should be!), then I'm indifferent between def pad(arr, width, mode, **kwargs): def pad(arr, mode, width, **kwargs): I definitely don't think width should have a default. -- Nathaniel

On Fri, Mar 30, 2012 at 5:41 AM, Nathaniel Smith <njs@pobox.com> wrote:

On Thu, Mar 29, 2012 at 6:53 PM, Tim Cera <tim@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 = pad(padwithzeros, a, 2)

Would that have some goodness?

I like the idea, but this interface feels undercooked to me. What is iaxis? (I couldn't figure that out from the docstrings in the pull request either.) If padding a matrix, do we need a way to do padding of all rows simultaneously? (Certainly that'd be just as easy for something like padwithzeros, and would let us avoid a python-level for loop.) 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.) If it's working with single rows at a time, then how will padwithconstant know which constant to pull out of kwargs["constant_value"] when it's an array?

That's why I thought you might want to submit this as a second pull request, rather than letting it hold up the whole thing.

Would you suggest committing the current PR and then adding this interface later? Chuck

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 and done.

This is all done in my working directory. Currently I have 'mode' as the first argument and not a keyword. Could you explain the utility of having it be a keyword, if that is indeed what you were advocating earlier? Step 2: Add the option to pass a user-defined function as the mode=

argument, since there's still uncertainty about the best way to do it and working through uncertainty adds time and risk that shouldn't hold up the parts that we do agree on.

This is done also. I don't do any checks. If it isn't a string, then I take it to be a function. The function signature is: myfunc(vector, pad_tuple, iaxis, kwds) and it has to return a rank 1 array the same length as the input `vector`

Even if we do want to keep around the pad_with_mean, pad_with_median etc. functions as additional user-exposed entry-points, I think the current names in the PR met with objections? (The current names are like "np.lib.pad.pad_mean".)

Names? Kindest regards, Tim

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 has always worked is exactly what you describe. If padding a matrix, do we need a way to do padding

of all rows simultaneously? (Certainly that'd be just as easy for something like padwithzeros, and would let us avoid a python-level for loop.)

The core of pad is apply_along_axis which passes a vector to a function. apply_along_axis will pass each 'row' into a function, then I use apply_along_axis again for each 'column' (which now includes padded values from each 'row') progressing through the axes. The function just works on a vector (rank 1 array). The vector that the function sees has to already have place holder pad values. That is why the function also needs the pad width to know which values to manipulate. So a working thought untested function would be something like: def padwithzeros(vector, pad_width, iaxis, **kwargs): vector[:pad_tuple[0]] = 0 vector[-pad_tuple[1]:] = 0 return vector b = pad(padwithzeros, a, 2) Note that iaxis isn't used! But wait... I like the idea, but this interface feels undercooked to me. What is

iaxis? (I couldn't figure that out from the docstrings in the pull request either.)

If it's working with single rows at a time, then how will padwithconstant know which constant to pull out of kwargs["constant_value"] when it's an array?

These questions actually go together. First, keywords like constant_values are the same for all rows in the axis - they are defined for the entire axis. Now iaxis. It is only needed inside the function to use the correct constant_values, end_values, or stat_length. For example something like... def padwithconstants(vector, pad_width, iaxis, **kwargs): vector[:pad_tuple[0]] = kwargs['constant_values'][iaxis][0] vector[-pad_tuple[1]:] = kwargs['constant_values'][iaxis][1] return vector constants = ((10,20), (30,40)) # 10 will be prepended to all rows (axis 0) # 20 will be appended to all rows (axis 0) # 30 b = pad(padwithconstants, a, 2, constant_values=constants) Kindest regards, Tim