Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Thu, May 31, 2018 at 5:50 PM, Matti Picus wrote: > At the recent NumPy sprint at BIDS (thanks to those who made the trip) we > spent some time brainstorming about a roadmap for NumPy, in the spirit of > similar work that was done for Jupyter. The idea is that a document with > wide community

Re: [Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

Hi Nathaniel, On Matt's prompting, I added release notes to the frozen/flexible PR [1]; see text attached below. Having done that, I felt the examples actually justified the frozen dimensions quite well. Given that you're the who expressed most doubts about them, could you have a look? Ideally,

Re: [Numpy-discussion] Python 3 compatible examples

+1 On Fri, Jun 1, 2018 at 1:43 PM, Juan Nunez-Iglesias wrote: > > On Sat, Jun 2, 2018, at 6:22 AM, Pauli Virtanen wrote: >> For Scipy, we converted the examples in the documentation to Python 3, >> and have essentially ignored Python 2 compatibility. So far, I remember >> no complaints about it.

Re: [Numpy-discussion] Python 3 compatible examples

On Sat, Jun 2, 2018, at 6:22 AM, Pauli Virtanen wrote: > For Scipy, we converted the examples in the documentation to Python 3, > and have essentially ignored Python 2 compatibility. So far, I remember > no complaints about it. I vote for what Pauli said.

Re: [Numpy-discussion] Python 3 compatible examples

pe, 2018-06-01 kello 14:17 -0600, Charles R Harris kirjoitti: > This post is prompted by this PR /11222>. > It would be good to come up with a timeline and plan for rewriting > the > examples to be Python 3 compatible. When we do so, we should also > make it

[Numpy-discussion] Python 3 compatible examples

Hi All, This post is prompted by this PR . It would be good to come up with a timeline and plan for rewriting the examples to be Python 3 compatible. When we do so, we should also make it assumed that `from __future__ import print_function` has been

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Fri, Jun 1, 2018 at 9:57 AM, Stefan van der Walt wrote: > Hi Ralf, > > On Thu, 31 May 2018 21:57:06 -0700, Ralf Gommers wrote: > > - "internal refactorings": MaskedArray yes, but the other ones no. > > numpy.distutils and f2py are very hard to test, a big refactor pretty > much > > guarantees

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

While we are in the crazy wish-list: having dtypes that are universal enough for pandas to use them and export their columns with them would be my crazy wish. I hope that it would help adding more uniform support for things like categorical variables in the pydata ecosystem. Gaël

Re: [Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

Stephan, good point about use cases. I think its still an odd fit. For example I think np.array_equal(np.zeros((3,3)), np.zeros((2,2))) or np.array_equal([1], ['foo']) would be difficult or impossible to replicate with a potential all_equal gufunc On Thu, May 31, 2018 at 2:00 PM, Stephan Hoyer

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

I would love to see gufuncs become more general. Specifically I would like an optional prologue and epilogue function. The prologue could potentially 1) inspect parameterized dtypes 2) kwargs 3) set non-trivial output array sizes 4) initialize data structures 5) defer processing to other

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Fri, Jun 1, 2018 at 9:46 AM, Chris Barker wrote: > numpy is also quite a bit slower than raw python for math with (very) > small arrays: > doing a bit more experimentation, the advantage is with pure python for over 10 elements (I got bored...). but I noticed that the time for numpy

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

Hi Ralf, On Thu, 31 May 2018 21:57:06 -0700, Ralf Gommers wrote: > - "internal refactorings": MaskedArray yes, but the other ones no. > numpy.distutils and f2py are very hard to test, a big refactor pretty much > guarantees breakage. there's also not much need for refactoring, because > those

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Fri, Jun 1, 2018 at 4:43 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > one thing that always slightly annoyed me is that numpy math is way > slower for scalars than python math > numpy is also quite a bit slower than raw python for math with (very) small arrays: In [31]: %

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Fri, Jun 1, 2018, 11:27 Todd wrote: > > > On Thu, May 31, 2018, 19:50 Matti Picus wrote: > >> At the recent NumPy sprint at BIDS (thanks to those who made the trip) >> we spent some time brainstorming about a roadmap for NumPy, in the >> spirit of similar work that was done for Jupyter. The

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

On Thu, May 31, 2018, 19:50 Matti Picus wrote: > At the recent NumPy sprint at BIDS (thanks to those who made the trip) > we spent some time brainstorming about a roadmap for NumPy, in the > spirit of similar work that was done for Jupyter. The idea is that a > document with wide community

[Numpy-discussion] Change in default behavior of np.polyfit

Hi, in [1] the scaling factor for the covariance matrix of `np.polyfit` was discussed. The conclusion was, that it is non-standard and a patch might be in order to correct this. Pull request [2] changes the factor from chisq(popt)/(M-N-2) to chisq(popt)/(M-N) (with M=number of point, N=number of

Re: [Numpy-discussion] A roadmap for NumPy - longer term planning

Hi Matti, Thanks for sharing the roadmap. Overall, it looks very nice. A practical question is on whether you want input via the mailing list, or should one just edit the wiki and add questions or so? As the roadmap mentioned interaction with python proper (and a possible PEP): one thing that