![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi All, As usual, the top of the PR stack is getting all the attention. As a start on cleaning up the old PRs, I'd like to suggest that all the maintainers look at their (long) pending PRs and decide which they want to keep, close those they don't want to pursue, and rebase the others. Might also help if they would post here the PRs that they think we should finish up. Chuck
![](https://secure.gravatar.com/avatar/d9ac9213ada4a807322f99081296784b.jpg?s=120&d=mm&r=g)
On Tue, 25 Sep 2018 09:51:13 -0600, Charles R Harris wrote:
PR 4808 [0] asks whether `np.pad` should have a default mode. The proposal is to make the defaul `constant`, with a value of 0. This is common in many signal processing applications. Nathaniel requested that we ask the list before committing. Best regards, Stéfan [0] https://github.com/numpy/numpy/pull/4808
![](https://secure.gravatar.com/avatar/7840b7a3579d2a7065d5c0aa804b5b92.jpg?s=120&d=mm&r=g)
As a user, I found np.pad relatively complex to get up and running (with all of the string parameters and different formats of the parameters). Some defaults would be good to just prime the pump, so to speak, when users are tinkering in e.g., and interactive session. -Paul On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt <stefanv@berkeley.edu> wrote:
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Chuck, Over at astropy we have a bot that sends a warning to PRs that have not received any commits for 5 months [1] and closes them if nothing happens in the next month, asking to open an issue instead. Despite my apprehensions, I found this worked quite well, drawing back attention to forgotten PRs (and forcing one to consider if they best remain forgotten). Would there be interest in such a scheme? All the best, Marten p.s. We don't do anything with issues. [1] Text of the astropy-bot warning: Hi humans [image: wave] - this pull request hasn't had any new commits for approximately 5 months. *I plan to close this in a month if the pull request doesn't have any new commits by then.* In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary. If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock. You may also consider sending a reminder e-mail about it to the astropy-dev mailing list <http://groups.google.com/group/astropy-dev> . *If you believe I commented on this pull request incorrectly, please report this here <https://github.com/astropy/astropy-bot/issues>.*
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Tue, Sep 25, 2018 at 5:35 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
My $2c: I've had this "bot experience" happen to me once (for a pip contribution), and that left a *really* bad taste. Reading the message below, that would do the same. E.g. no one bothered to review my PR in 5 months, and now you're asking me to rebase? If that's asked for, them much better if a human does it. Other thought: there were a number of people uncomfortable with the pep8 bot we used to have. This one would be more intrusive. Cheers, Ralf
![](https://secure.gravatar.com/avatar/f246a75a3ed39b6b92079ae0fa9e5852.jpg?s=120&d=mm&r=g)
On 26 Sep 2018, at 5:12 am, Ralf Gommers <ralf.gommers@gmail.com> wrote: My $2c: I've had this "bot experience" happen to me once (for a pip contribution), and that left a *really* bad taste.
I’m going to second Ralf’s comments here. These bots are a great idea if your number one goal is to reduce the number of open PRs at the cost of everything else — including happy contributors.
![](https://secure.gravatar.com/avatar/18a30ce6d84de6ce5c11ce006d10f616.jpg?s=120&d=mm&r=g)
On Tue, 25 Sep 2018 at 21:14, Ralf Gommers <ralf.gommers@gmail.com> wrote:
I think Tensorflow does it better. Their butler-bot nags the core developer assigned to the PR or issue if the report isn't marked as awaiting information or suggestions pending. I think this is much nicer for external contributors. On the other hand, TF has paid staff to take care of this, here it would be up to you guys if you feel up to being nagged by robots. Exact text: Nagging Assignee @rohan100jain <https://github.com/rohan100jain>: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly. https://github.com/tensorflow/tensorflow/issues/22180
![](https://secure.gravatar.com/avatar/6f1e0a1c41913d3a2cc3cfe6b7260e91.jpg?s=120&d=mm&r=g)
I think that PRs 7804 and 10855 can be merged (or closed; closure either way). 7804: ENH: Added atleast_nd This has been ready to go for a while. It was deemed superfluous at one point, but then experienced a revival, which ended up stagnating. 10855: ENH: Adding a count parameter to np.unpackbits Has been ready for a while now as well. There is a possible modification to the interface that may need to be made (not allowing negative indices), but it's passing everything and good to go as-is, in my opinion. Regards, - Joe On Tue, Sep 25, 2018 at 11:52 AM Charles R Harris <charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/71832763447894e7c7f3f64bfd19c13f.jpg?s=120&d=mm&r=g)
On 09/25/2018 11:51 AM, Charles R Harris wrote:
PR 6377 [0] fixes up alignment bugs which cause complex64/128 to be incorrectly aligned, which in turn causes further bugs. Eg, "np.dtype('c8').alignment" is 8 but should be 4 on most systems. The PR is in a finished state, modulo reviews. If anyone has access to sparc/aarch systems it would be great to test it, though. Cheers, Allan [0] https://github.com/numpy/numpy/pull/6377
![](https://secure.gravatar.com/avatar/5e44e61af952612c3c45385b62806c67.jpg?s=120&d=mm&r=g)
PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical gufuncs such as " all equal". The functionality has been mentioned quite a few times on this list. Many implementations are in the PR and they are decent IMHO. The hard part is the API and current ufunc code. Initially I thought they would be top level functions, ie np.all_equal, but there appears to be general consensus that they should be ufunc methods, ie np.equal.all. Its not clear to me at least how that should be done. Adding all, any, and first methods to all ufuncs seems bad. Some sort of monkeypatch hack also seems bad. Rewriting the ufunc code to make the methods specific to each ufunc, likely breaking the abi/api, is a big effort. Suggestions welcome. Thank you. On Tue, Sep 25, 2018 at 6:56 PM Allan Haldane <allanhaldane@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <harrigan.matthew@gmail.com> wrote:
Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I suppose the argument in favor is decreasing the number of function names, which also has its proponents. What is the gain here in making them stand alone functions, more speed, possible SIMD speedups, etc.? <snip> Chuck
![](https://secure.gravatar.com/avatar/5e44e61af952612c3c45385b62806c67.jpg?s=120&d=mm&r=g)
Speed, and to a lesser extent memory. The biggest advantage is it allows short circuiting with ridiculous speedups for certain cases. It also removes intermediate arrays/bandwidth. There is some SIMD speedup but thats a relatively small benefit. On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Matthew, With the decision not to support broadcasting in ufunc signatures, I think a ufunc route for generally useful all_equal has become hard at the present time. So, as it it seems the only useful route is indeed a separate function... (perhaps in the end we can use stackable ufuncs, which operate in chunks - I have a prototype but it doesn't do reductions yet, so not directly relevant). All the best, Marten On Tue, Sep 25, 2018 at 8:25 PM Matthew Harrigan <harrigan.matthew@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/5e44e61af952612c3c45385b62806c67.jpg?s=120&d=mm&r=g)
Marten, I think a ufunc route is pretty straightforward assuming there is a higher level function. It would be something like this: def wrapper_for_all_equal(x, y): return np.private_ufunc_all_equal(*np.broadcast_arrays(x, y)) The largest outstanding issue I see are what the api should be. There was concern about adding too many functions to the already crowded numpy namespace. On Tue, Sep 25, 2018 at 9:25 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/d9ac9213ada4a807322f99081296784b.jpg?s=120&d=mm&r=g)
On Tue, 25 Sep 2018 09:51:13 -0600, Charles R Harris wrote:
PR 4808 [0] asks whether `np.pad` should have a default mode. The proposal is to make the defaul `constant`, with a value of 0. This is common in many signal processing applications. Nathaniel requested that we ask the list before committing. Best regards, Stéfan [0] https://github.com/numpy/numpy/pull/4808
![](https://secure.gravatar.com/avatar/7840b7a3579d2a7065d5c0aa804b5b92.jpg?s=120&d=mm&r=g)
As a user, I found np.pad relatively complex to get up and running (with all of the string parameters and different formats of the parameters). Some defaults would be good to just prime the pump, so to speak, when users are tinkering in e.g., and interactive session. -Paul On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt <stefanv@berkeley.edu> wrote:
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Chuck, Over at astropy we have a bot that sends a warning to PRs that have not received any commits for 5 months [1] and closes them if nothing happens in the next month, asking to open an issue instead. Despite my apprehensions, I found this worked quite well, drawing back attention to forgotten PRs (and forcing one to consider if they best remain forgotten). Would there be interest in such a scheme? All the best, Marten p.s. We don't do anything with issues. [1] Text of the astropy-bot warning: Hi humans [image: wave] - this pull request hasn't had any new commits for approximately 5 months. *I plan to close this in a month if the pull request doesn't have any new commits by then.* In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary. If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock. You may also consider sending a reminder e-mail about it to the astropy-dev mailing list <http://groups.google.com/group/astropy-dev> . *If you believe I commented on this pull request incorrectly, please report this here <https://github.com/astropy/astropy-bot/issues>.*
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Tue, Sep 25, 2018 at 5:35 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
My $2c: I've had this "bot experience" happen to me once (for a pip contribution), and that left a *really* bad taste. Reading the message below, that would do the same. E.g. no one bothered to review my PR in 5 months, and now you're asking me to rebase? If that's asked for, them much better if a human does it. Other thought: there were a number of people uncomfortable with the pep8 bot we used to have. This one would be more intrusive. Cheers, Ralf
![](https://secure.gravatar.com/avatar/f246a75a3ed39b6b92079ae0fa9e5852.jpg?s=120&d=mm&r=g)
On 26 Sep 2018, at 5:12 am, Ralf Gommers <ralf.gommers@gmail.com> wrote: My $2c: I've had this "bot experience" happen to me once (for a pip contribution), and that left a *really* bad taste.
I’m going to second Ralf’s comments here. These bots are a great idea if your number one goal is to reduce the number of open PRs at the cost of everything else — including happy contributors.
![](https://secure.gravatar.com/avatar/18a30ce6d84de6ce5c11ce006d10f616.jpg?s=120&d=mm&r=g)
On Tue, 25 Sep 2018 at 21:14, Ralf Gommers <ralf.gommers@gmail.com> wrote:
I think Tensorflow does it better. Their butler-bot nags the core developer assigned to the PR or issue if the report isn't marked as awaiting information or suggestions pending. I think this is much nicer for external contributors. On the other hand, TF has paid staff to take care of this, here it would be up to you guys if you feel up to being nagged by robots. Exact text: Nagging Assignee @rohan100jain <https://github.com/rohan100jain>: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly. https://github.com/tensorflow/tensorflow/issues/22180
![](https://secure.gravatar.com/avatar/6f1e0a1c41913d3a2cc3cfe6b7260e91.jpg?s=120&d=mm&r=g)
I think that PRs 7804 and 10855 can be merged (or closed; closure either way). 7804: ENH: Added atleast_nd This has been ready to go for a while. It was deemed superfluous at one point, but then experienced a revival, which ended up stagnating. 10855: ENH: Adding a count parameter to np.unpackbits Has been ready for a while now as well. There is a possible modification to the interface that may need to be made (not allowing negative indices), but it's passing everything and good to go as-is, in my opinion. Regards, - Joe On Tue, Sep 25, 2018 at 11:52 AM Charles R Harris <charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/71832763447894e7c7f3f64bfd19c13f.jpg?s=120&d=mm&r=g)
On 09/25/2018 11:51 AM, Charles R Harris wrote:
PR 6377 [0] fixes up alignment bugs which cause complex64/128 to be incorrectly aligned, which in turn causes further bugs. Eg, "np.dtype('c8').alignment" is 8 but should be 4 on most systems. The PR is in a finished state, modulo reviews. If anyone has access to sparc/aarch systems it would be great to test it, though. Cheers, Allan [0] https://github.com/numpy/numpy/pull/6377
![](https://secure.gravatar.com/avatar/5e44e61af952612c3c45385b62806c67.jpg?s=120&d=mm&r=g)
PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical gufuncs such as " all equal". The functionality has been mentioned quite a few times on this list. Many implementations are in the PR and they are decent IMHO. The hard part is the API and current ufunc code. Initially I thought they would be top level functions, ie np.all_equal, but there appears to be general consensus that they should be ufunc methods, ie np.equal.all. Its not clear to me at least how that should be done. Adding all, any, and first methods to all ufuncs seems bad. Some sort of monkeypatch hack also seems bad. Rewriting the ufunc code to make the methods specific to each ufunc, likely breaking the abi/api, is a big effort. Suggestions welcome. Thank you. On Tue, Sep 25, 2018 at 6:56 PM Allan Haldane <allanhaldane@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <harrigan.matthew@gmail.com> wrote:
Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I suppose the argument in favor is decreasing the number of function names, which also has its proponents. What is the gain here in making them stand alone functions, more speed, possible SIMD speedups, etc.? <snip> Chuck
![](https://secure.gravatar.com/avatar/5e44e61af952612c3c45385b62806c67.jpg?s=120&d=mm&r=g)
Speed, and to a lesser extent memory. The biggest advantage is it allows short circuiting with ridiculous speedups for certain cases. It also removes intermediate arrays/bandwidth. There is some SIMD speedup but thats a relatively small benefit. On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Matthew, With the decision not to support broadcasting in ufunc signatures, I think a ufunc route for generally useful all_equal has become hard at the present time. So, as it it seems the only useful route is indeed a separate function... (perhaps in the end we can use stackable ufuncs, which operate in chunks - I have a prototype but it doesn't do reductions yet, so not directly relevant). All the best, Marten On Tue, Sep 25, 2018 at 8:25 PM Matthew Harrigan <harrigan.matthew@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/5e44e61af952612c3c45385b62806c67.jpg?s=120&d=mm&r=g)
Marten, I think a ufunc route is pretty straightforward assuming there is a higher level function. It would be something like this: def wrapper_for_all_equal(x, y): return np.private_ufunc_all_equal(*np.broadcast_arrays(x, y)) The largest outstanding issue I see are what the api should be. There was concern about adding too many functions to the already crowded numpy namespace. On Tue, Sep 25, 2018 at 9:25 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
participants (12)
-
Allan Haldane
-
Charles R Harris
-
Daπid
-
Joseph Fox-Rabinovitz
-
Juan Nunez-Iglesias
-
Marten van Kerkwijk
-
Matthew Harrigan
-
Paul Hobson
-
Ralf Gommers
-
Robert Kern
-
Stefan van der Walt
-
Stephan Hoyer