Re: [Numpy-discussion] PR Cleanup

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.

Re: [Numpy-discussion] PR Cleanup

On Tue, 25 Sep 2018 at 21:14, Ralf Gommers wrote: > > > On Tue, Sep 25, 2018 at 5:35 PM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> 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 i

Re: [Numpy-discussion] PR Cleanup

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

Re: [Numpy-discussion] PR Cleanup

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

Re: [Numpy-discussion] PR Cleanup

On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan wrote: > PR 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 har

Re: [Numpy-discussion] PR Cleanup

Would it be possible to have an opt-in for that bot? On Tue, Sep 25, 2018 at 8:01 PM Juan Nunez-Iglesias wrote: > > On 26 Sep 2018, at 5:12 am, Ralf Gommers 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’

Re: [Numpy-discussion] PR Cleanup

PR 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 the

Re: [Numpy-discussion] PR Cleanup

> On 26 Sep 2018, at 5:12 am, Ralf Gommers 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

Re: [Numpy-discussion] PR Cleanup

On 09/25/2018 11:51 AM, Charles R Harris wrote: > 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 t

Re: [Numpy-discussion] PR Cleanup

On Tue, Sep 25, 2018 at 5:35 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > 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 in

Re: [Numpy-discussion] PR Cleanup

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

Re: [Numpy-discussion] PR Cleanup

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 forgott

Re: [Numpy-discussion] PR Cleanup

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

Re: [Numpy-discussion] PR Cleanup

On Tue, Sep 25, 2018 at 11:08 AM Robert Kern wrote: > On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt > 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

Re: [Numpy-discussion] PR Cleanup

On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt 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. > +1 for that proposal. -- Robert Kern _

Re: [Numpy-discussion] PR Cleanup

On Tue, Sep 25, 2018 at 9:58 AM Stefan van der Walt wrote: > On Tue, 25 Sep 2018 09:51:13 -0600, Charles R Harris wrote: > > 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

Re: [Numpy-discussion] PR Cleanup

On Tue, 25 Sep 2018 09:51:13 -0600, Charles R Harris wrote: > 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 th

[Numpy-discussion] PR Cleanup

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