Re: [Numpy-discussion] Fixing inconsistent behaviour of reduceat()

Discussion on-going at the above issue, but perhaps worth mentioning more broadly the alternative of adding a slice argument (or start, stop, step arguments) to ufunc.reduce, which would mean we can just deprecate reduceat altogether, as most use of it would just be add.reduce(array,

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

Hi All, I doubt I'm really the last one thinking ndarray subclassing is a good idea, but as that was stated, I feel I should at least pipe in. It seems to me there is both a perceived problem -- with the two subclasses that numpy provides -- `matrix` and `MaskedArray` -- both being problematic in

Re: [Numpy-discussion] proposed changes to array printing in 1.14

To add to Allan's message: point (2), the printing of 0-d arrays, is the one that is the most important in the sense that it rectifies a really strange situation, where the printing cannot be logically controlled by the same mechanism that controls >=1-d arrays (see PR). While point 3 can also be

Re: [Numpy-discussion] NumPy v1.13.0rc1 released.

Hi All, Do indeed try __array_ufunc__! It should make many things work much better and possibly faster than was possible with __array_prepare__ and __array_wrap__ (for astropy's Quantity, an ndarray subclass than I maintain, it gets us a factor of almost 2 in speed for operations where scaling

Re: [Numpy-discussion] Future of ufuncs

Hi Chuck, Like Sebastian, I wonder a little about what level you are talking about. Presumably, it is the actual implementation of the ufunc? I.e., this is not about the upper logic that decides which `__array_ufunc__` to call, etc. If so, I agree with you that it would seem to make most sense

Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

Moving to a subpackage may indeed make more sense, though it might not help as much with getting rid of the hacks inside other parts of numpy to keep matrix working. In that respect it seems a bit different at least from weave. Then again, independently of whether we remove or release a separate

Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

On Thu, Nov 30, 2017 at 2:51 PM, Stefan van der Walt wrote: > On Thu, Nov 30, 2017, at 10:13, josef.p...@gmail.com wrote: > > recarrays are another half-hearted feature in numpy that is mostly > obsolete with pandas and pandas_like DataFrames in other > packages. > > > I'm

Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

Hi Ralf, Sorry not to have recalled the previous thread. Your point about not doing things in the python 2->3 move makes sense; handy for me is no reason to give users an incentive not to move to python3 because their matrix-dependent code breaks. It does sound like, given the use of sparse, a

Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

Hi Nathaniel, Thanks for the concrete suggestion: see https://github.com/numpy/numpy/pull/10142 I think this is useful independent of exactly how the eventual move to a new package would work; next step might be to collect all matrix tests in the `libmatrix` sub-module. All the best, Marten

Re: [Numpy-discussion] Type annotations for NumPy

Hi Stephan, A question of perhaps broader scope than what you were asking for, and more out of curiosity than anything else, but can one mix type annotations with others? E.g., in astropy, we have a decorator that looks for units in the annotations (not dissimilar from dtype, I guess). Could one

Re: [Numpy-discussion] Deprecate matrices in 1.15 and remove in 1.17?

Hi Chris, I'm easily convinced - yes, your argument makes sense too. Fortunately, at some level it doesn't affect what we do now. For 1.15 it should at least have a PendingDeprecationWarning. Since putting that in place means that all tests involving matrices now fail by default, it also becomes

Re: [Numpy-discussion] masked_values behaviour

Definitely a big! The underlying problem is: ``` In [23]: np.abs(np.int16(-32768)) Out[23]: -32768 ``` This is not great, but perhaps consistent with the logic that abs should return a value of the same dtype. It could be solved inside `masked_values` by using `np.abs(value, dtype=xnew.dtype)`

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Yes, I like the idea of, effectively, creating an ABC for ndarray - with which one can register. -- Marten ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Hi Ben, You just summarized excellently why I'm on a quest to change `asarray` to `asanyarray` within numy (or at least add a `subok` keyword for things like `broadcast_arrays`)! Obviously, this covers only ndarray subclasses, not duck types, though I guess in principle one could use the ABC

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Hi Josef, astropy's Quantity is well developed and would give similar results to pint; all those results make sense if one wants to have consistent units. A general library code will actually do the right thing as long as it just uses normal mathematical operations with ufuncs - and as long as

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Hi Josef, Indeed, for some applications one would like to have different units for different parts of an array. And that means that, at present, the quantity implementations that we have are no good at storing, say, a covariance matrix involving parameters with different units, where thus each

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

My 2¢ here is that all code should feel free to assume certain type of input, as long as it is documented properly, but there is no reason to enforce that by, e.g., putting `asarray` everywhere. Then, for some pieces ducktypes and subclasses will just work like magic, and uses you might never have

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 5:09 PM, Benjamin Root wrote: > Duck typing is great and all for classes that implement some or all of the > ndarray interface but remember what the main reason for asarray() and > asanyarray(): to automatically promote lists and tuples and other >

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

I guess my argument boils down to it being better to state that a function only accepts arrays and happily let it break on, e.g., matrix, than use `asarray` to make a matrix into an array even though it really isn't. I do like the dtype ideas, but think I'd agree they're likely to come with their

Re: [Numpy-discussion] Proposal of timeline for dropping Python 2.7 support

In astropy we had a similar discussion about version numbers, and decided to make 2.0 the LTS that still supports python 2.7 and 3.0 the first that does not. If we're discussing jumping a major number, we could do the same for numpy. (Admittedly, it made a bit more sense with the numbering

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Hi Benjamin, For the shapes and reshaping, I wrote an ShapedLikeNDArray mixin/ABC for astropy, which may be a useful starting point as it also provides a way to implement the methods ndarray uses to reshape and get elements: see

Re: [Numpy-discussion] NEP process update

Would be great to have structure, and especially a template - ideally, the latter is enough for someone to create a NEP, i.e., has lots of in-template documentation. One thing I'd recommend thinking a little about is to what extend a NEP is "frozen" after acceptance. In astropy we've seen

Re: [Numpy-discussion] sinc always returns double precision

It is actually a bit more subtle (annoyingly so), the reason you get a float64 is that you pass in a scalar, and for scalars, the dtype of `pi` indeed "wins", as there is little reason to possibly loose precision. If you pass in an array instead, then you do get `float32`: ```

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

Hi All, I agree with comments above that deprecating/removing MaskedArray is premature; we certainly depend on it in astropy (which is indeed what got me started to contribute to numpy -- it was quite buggy!). I also think that, unlike Matrix, it is far from a neglected part of numpy. Eric

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Hi Stephan, I think we're getting to the stage where an updated text would be useful. For that, you may want to consider an actual implementation of, e.g., a very simple function like `np.reshape` as well as a more complicated one like `np.concatenate`, and in particular how the implementation

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

> and in particular how the implementation finds out where its own instances >> are located. >> > > I think we've discussed this before, but I don't think this is feasible to > solve in general given the diversity of wrapped APIs. If you want to find > the arguments in which a class' own instances

Re: [Numpy-discussion] A little about XND

Hi Stefan, That looks quite nice and expressive. In the context of a discussion we have been having about describing `matmul/@` and possibly broadcastable dimensions, I think from your description it sounds like one would describe `@` with multiple functions (the multiple dispatch we have been

Re: [Numpy-discussion] A little about XND

Interesting. If nothing else, it would be a nice way to mark our internal functions, including the loops. It also should not be difficult to have (g)ufunc signatures exported in that way, combining `signature` and `types`. In more detail, I see the grammar clearly allows fixed dimensions in a way

Re: [Numpy-discussion] A little about XND

Hi Stefan, Just to clarify: the ? we propose in the NEP is really for matmul - it indicates a true missing dimension (i.e., the array cannot have outer broadcast dimensions as well). For inner loop broadcasting, I'm proposing a "|1" post-fix, which means a dimension could also be missing, but can

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

On Tue, Jun 12, 2018 at 2:35 AM, Eric Wieser wrote: > Frozen dimensions: > > I started with just making every 3-vector and 3x3-matrix structured arrays > with the relevant single sub-array entry > > I was actually suggesting omitting the structured dtype (ie, field names) > altogether, and just

Re: [Numpy-discussion] Updated 1.15.0 release notes

Request for a -rc seconded (although this time we should be fine for astropy, as things are working well with -dev). -- Marten ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Dropping Python 3.4 support for NumPy 1.16

It seems everyone is in favour - anybody in for making a PR reducing the travis testing accordingly? (It seems a bit of overkill more generally - would be good to reduce the kWhr footprint a little...) -- Marten ___ NumPy-Discussion mailing list

Re: [Numpy-discussion] Updated 1.15.0 release notes

Indeed, we do something similar in astropy, with a pre-release failure being considered breakage (rather than ignorable as for -dev): https://github.com/astropy/astropy/blob/master/.travis.yml#L142 ​-- Marten ___ NumPy-Discussion mailing list

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

Hi All, The discussion on the gufunc signature enhancements seems to have stalled a bit, but while it was going I've tried to update the NEP correspondingly. The NEP is now merged, so can viewed more easily, at http://www.numpy.org/neps/nep-0020-gufunc-signature-enhancement.html My own quite

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

Hi All, Following on a PR combining the ability to provide fixed and flexible dimensions [1] (useful for, e.g., 3-vector input with a signature like `(3),(3)->(3)`, and for `matmul`, resp.; based on earlier PRs by Jaime [2] and Matt (Picus) [3]), I've now made a PR with a further enhancement,

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

Hi Stephan, Matt, My `n|1` was indeed meant to be read as `n or 1`, but with the (implicit) understanding that any array can have as many ones pre-pended as needed. The signature `(n?),(n?)->()` is now set aside for flexible dimensions: this would allow the constant, but not the trailing shape

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

Hi Nathaniel, I think the case for frozen dimensions is much more solid that just `cross1d` - there are many operations that work on size-3 vectors. Indeed, as I noted in the PR, I have just been wrapping a Standards-of-Astronomy library in gufuncs, and many of its functions require size-3

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

p.s. While my test case of `cube_equal` in the PR is perhaps not super-realistic, I don't know if one really wants to do multiple dispatch on something like "(o|1,n|1,m|1),(o|1,n|1,m|1)->()"... -- Marten ___ NumPy-Discussion mailing list

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

p.p.s. Your multiple dispatch signature for broadcasted dimensions is actually not quite right: should be (n|1),(n|1)->() ===> (n),(n)->() | (n),(1)->() | (1),(n)->() | (n),() -> () | (),(n)->() This is becoming quite verbose... (and perhaps become somewhat slow). Though arguably one could

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

Hi Allan, Seeing it written out like that, I quite like the multiple dispatch signature: perhaps verbose, but clear. It does mean a different way of changing the ufunc structure, but I actually think it has the advantage of being possible without extending the structure (though that might still

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Hi Stephan, Thanks for posting. Overall, this is great! My more general comment is one of speed: for *normal* operation performance should be impacted as minimally as possible. I think this is a serious issue and feel strongly it *has* to be possible to avoid all arguments being checked for the

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

On Sun, Jun 3, 2018 at 2:00 PM, Hameer Abbasi wrote: > The rules for dispatch with ``__array_function__`` match those for > ``__array_ufunc__`` (see > `NEP-13 `_). > In particular: > > - NumPy will gather implementations of

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

> > In most cases, I suspect that the overhead of a function call and checking > several arguments for "__array_function__" will be negligible, like the > situation for __array_ufunc__. I'm not strongly opposed to either of your > proposed solutions, but I do think it would be a little strange to

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

This in certainly true in general, but given the complete flexibility of __array_function__ there's no way we can make every check convenient. The best we can do is make it easy to handle the common cases, where the argument position does not matter. I think those cases may not be as common as

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Although I'm still not 100% convinced by NotImplementedButCoercible, I do like the idea that this is the default for items that do not implement `__array_function__`. And it might help avoid trying to find oneself in a possibly long list. -- Marten ___

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] 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

Re: [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API

Hi Stephan, On `NotImplementedButCoercible`: don't forget that even a preliminary implementation of `__array_function__` has always the choice of coercing its own instances to ndarray and re-calling the function; that is really no different from (though probably a bit slower than) what would

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

Hi Sebastian, This is getting a bit far off-topic (which is whether it is a good idea to allow the ability to set frozen dimensions and broadcasting), but on `all_equal`, I definitely see the point that a method might be better, but that needs work: to expand the normal ufunc mechanism to allow

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

> Incidentally, once we make reduce/accumuate/... into "associated gufuncs", I > propose completely removing the "method" argument of __array_ufunc__, since > it is no longer needed and adds a lot > of complexity which implementors of an __array_ufunc__ are forced to > account for. For Quantity

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

Hi All, Matti asked me to make a PR accepting my own NEP - https://github.com/numpy/numpy/pull/11429 Any objections? As noted in my earlier summary of the discussion, in principle we can choose to accept only parts, although I think it became clear that the most contentious is also the one

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

cluded below. > > Best, > Stephan > > === > A dispatch mechanism for NumPy's high level array functions > === > > :Author: Stephan Hoyer > :Author: Matthew Rocklin > :Author: Marten van Kerkwijk > :Au

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

Hi Hameer, I think the override on `dtype` would work - after all, the override is checked before anything is done, so one can just pass in `self` if one wishes (or some helper class that contains both `self` and any desired further information. But, as you note, it would not cover everything,

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

Hi Hameer, It is. The point of the proposed feature was to handle array generation > mechanisms, that don't take an array as input in the standard NumPy API. > Giving them a reference handles both the dispatch and the decision about > which implementation to call. > Sorry, I had clearly

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

, this will allow Matti to finish his work on making matmul a gufunc. See http://www.numpy.org/neps/nep-0020-gufunc-signature-enhancement.html All the best, Marten -- Forwarded message -- From: Marten van Kerkwijk Date: Tue, Jun 26, 2018 at 2:25 PM Subject: Re: [Numpy-discussion] Allowing

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

On Fri, Jun 29, 2018 at 9:54 PM, Eric Wieser wrote: > Good catch, > > I think the latter failing is because np.add.reduce ends up calling > np.ufunc.reduce.__get__(np.add), and builtin_function.__get__ doesn’t > appear to do any caching. I suppose caching bound methods would just be a > waste of

Re: [Numpy-discussion] Extending ufunc signature syntax for matmul, frozen dimensions

Just for completeness: there are *four* gufuncs (matmat, matvec, vecmat, and vecvec). I remain torn about the best way forward. The main argument against using them inside matmul is that in order to decide which of the four to use, matmul has to have access to the `shape` of the arguments. This

Re: [Numpy-discussion] Extending ufunc signature syntax for matmul, frozen dimensions

On Wed, May 2, 2018 at 6:24 AM, Hameer Abbasi wrote: > There is always the option of any downstream object overriding matmul, and I > fail to see which objects won't have a shape. - Hameer I think we should not decide too readily on what is "reasonable" to expect for a

Re: [Numpy-discussion] Extending ufunc signature syntax for matmul, frozen dimensions

Hi Matti, In the original implementation of what was then __numpy_ufunc__, we had overrides for both `np.dot` and `np.matmul` that worked exactly as your option (2), but we decided in the end that those really are not true ufuncs and we should not include ufunc mimics in the mix as someone using

Re: [Numpy-discussion] Extending ufunc signature syntax for matmul, frozen dimensions

Hi Matti, This sounds great. For completeness, you omitted the vector-vector case for matmul '(k),(k)->()' - but the suggested new signature for `matmul` would cover that case as well, so not a problem. All the best, Marten ___ NumPy-Discussion

Re: [Numpy-discussion] Extending ufunc signature syntax for matmul, frozen dimensions

I thought a bit further about this proposal: a disadvantage for matmul specifically is that is does not solve the need for `matvec`, `vecmat`, and `vecvec` gufuncs. That said, it might make sense to implement those as "pseudo-ufuncs" that just add a 1 in the right place and call `matmul`... --

[Numpy-discussion] axis and keepdims arguments for generalized ufuncs

Hi All, When introducing the ``axes`` argument for generalized ufuncs, the plan was to eventually also add ``axis`` and ``keepdims`` for reduction-like gufuncs. I have now attempted to do so in https://github.com/numpy/numpy/pull/11018 It is not completely feature-compatible with reductions in

Re: [Numpy-discussion] numpy grant update

Hi Nathaniel, Thanks for the link. The plans sounds great! You'll not be surprised to hear I'm particularly interested in the units aspect (and, no, I don't mind at all if we can stop subclassing ndarray...). Is the idea that there will be a general way for allow a dtype to define how to convert

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Hi Nathan, Happy to hear that it works well for yt! In astropy's Quantity as well, it greatly simplifies the code, and has made many operations about two times faster (which is why I pushed so hard to get __array_ufunc__ done...). But for now we're stuck with supporting __array_prepare__ and

Re: [Numpy-discussion] PowerPC machine available from OSUOSL

Doing CI on a different architecture, especially big-endian, would seem very useful. (Indeed, I'll look into it for my own project, of reading radio baseband data -- we run it on a BGQ, so more constant checking would be good to have). But it may be that we're a bit too big for CI, and that it is

Re: [Numpy-discussion] Multiple-field indexing: view vs copy in 1.14+

On Thu, Jan 25, 2018 at 1:16 PM, Stefan van der Walt <stef...@berkeley.edu> wrote: > On Mon, 22 Jan 2018 10:11:08 -0500, Marten van Kerkwijk wrote: >> >> I think on the consistency argument is perhaps the most important: >> views are very powerful and in many ways one *c

Re: [Numpy-discussion] Adoption of a Code of Conduct

My ideal version would be substantially shorter, maybe just quote the golden rule, but I am happy with the suggestion to just adapt this text. I particularly appreciate the lack of absolutism in the text, and the acknowledgement that it is possible to have a bad day even while not distracting from

Re: [Numpy-discussion] Adoption of a Code of Conduct

I think a legalistic focus on the letter rather than the spirit of the code of conduct is not that helpful (and probably what makes if feel US centric - funny how court systems end up shaping countries). My preference would be to keep exactly the scipy version, so that at least for these two

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

> >> I don't really understand the 'types' frozenset. The NEP says "it will > >> be used by most __array_function__ methods, which otherwise would need > >> to extract this information themselves"... but they still need to > >> extract the information themselves, because they still have to examine

Re: [Numpy-discussion] Possible Deprecation of np.ediff1d

On Mon, Aug 27, 2018 at 10:05 PM Stephan Hoyer wrote: - It appears in astropy, dask, pandas, pint, scipy and TensorFlow. > The only reason it appears in astropy is because of tests that Quantity works correctly with it; we do not actually use it... So that's at least a few hits that do not

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

HI All, On the backwards compatibility: from an astropy perspective, I would expect that the introduction of `__array_function__` implies a guarantee that the *functionality* it provides will remain, i.e., that it will continue to be possible to override, say, concatenate. It is not a big deal if

Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP

> > > Rather, we might state that "At some point in the future, the NumPy > development team may no longer interested in maintaining workarounds for > specific subclasses, because other interfaces for extending NumPy are > believed to be more maintainable/preferred." > > That sentence I think

Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP

> >- We enforce good practices in our code. For example, we will > explicitly disallow subclassing from ndarray, we get rid of scalars, we > fix > the type system. > > > Given my other reply, probably no surprise that I strongly disagree with the idea of disallowing subclasses.

Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP

Hi Ralf, Maybe as a concrete example of something that has been discussed, for which your proposed text makes (I think) clear what should or should not be done: Many of us hate that `np.array` (like, sadly, many other numpy parts) auto-converts anything not obviously array-like to dtype=object,

Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP

Agreed that changes better be gradual, and that we do not have the manpower to do otherwise (I was slightly shocked to see that my 94 commits in the last two years make me the fourth most prolific contributor in that period... And that is from the couple of hours a week I use while procrastinating

Re: [Numpy-discussion] backwards compatibility and deprecation policy NEP

Hi Ralf, >> Overall, this looks good. But I think the subclassing section is somewhat >> misleading in suggesting `ndarray` is not well designed to be subclassed. >> At least, for neither my work on Quantity nor that on MaskedArray, I've >> found that the design of `ndarray` itself was a

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

Absolutely fine to have to deal with future chances - my main point is that by accepting the NEP, I think numpy is committing to provide some way to override whatever functions __array_function__ is introduced for, i.e., we cannot reasonably go back to not providing any way to override such a

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

On Wed, Aug 29, 2018 at 9:53 AM Matthew Rocklin wrote: > > On the backwards compatibility: from an astropy perspective, I would > expect that the introduction of `__array_function__` implies a guarantee > that the *functionality* it provides will remain, > > My guess is that you wouldn't have

Re: [Numpy-discussion] ARMv8 / shippable addition to CI

Might make most sense as part of a cron job rather than on every PR. -- Marten On Wed, Sep 5, 2018 at 8:59 PM Ralf Gommers wrote: > > > On Wed, Sep 5, 2018 at 3:15 PM Tyler Reddy > wrote: > >> Hi, >> >> Stefan & Matti wanted me to check on the mailing list about about adding >> ARMv8 (free /

Re: [Numpy-discussion] NumPy 1.15.0rc2 released.

gh-11467. commit c3381b3b6865b967720de7d3b75ca534672bfc2e Author: Marten van Kerkwijk Date: Fri Jun 29 10:09:46 2018 -0400 BENCH: belated addition of lcm, gcd to ufunc benchmark. commit c03d3240873bc7ad1796b7cd5e3705577aa57ac0 Author: Charles Harris Date: Thu Jun 28 19:23:39 2018 -0600

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

On Tue, Jul 3, 2018 at 12:11 PM, Stephan Hoyer wrote: > On Tue, Jul 3, 2018 at 7:13 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> Overall, would one way to move forward be to merge the first PR (flexible >> and frozen) and defer the broadcastable di

Re: [Numpy-discussion] Multiple-field indexing: view vs copy in 1.14+

Hi Allan, I think on the consistency argument is perhaps the most important: views are very powerful and in many ways one *counts* on them happening, especially in working with large arrays. They really should be used everywhere it is possible. In this respect, I think one has to weigh breakage

Re: [Numpy-discussion] NumPy 1.14.2 release

Hi Chuck, Astropy tests indeed all pass again against master, without the work-arounds for 1.14.1. Thanks, of course also to Allan for the fix, Marten ___ NumPy-Discussion mailing list NumPy-Discussion@python.org

Re: [Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

Hi Nathaniel, astropy is an example of a project that does essentially all discussion of its "Astropy Proposals for Enhancement" on github. I actually like the numpy approach of sending anything to the mailing list that deserves community input (which includes NEP by their very nature). I don't

Re: [Numpy-discussion] New NEP: merging multiarray and umath

Hi Nathanial, I looked through the revised text at https://github.com/numpy/numpy/pull/10704 and think it covers things well; any improvements on the organisation I can think of would seem to start with doing the merge anyway (e.g., I quite like Eric Wieser's suggested base ndarray class; the

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

We may be getting a bit distracted by the naming -- though I'll throw out `asarraymimic` as another non-programmer-lingo option that doesn't reuse `arraylike` and might describe what the duck array is attempting to do more closely. But more to the point: I think in essence, we're trying to create

Re: [Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

Apparently, where and how to discuss enhancement proposals was recently a topic on the python mailing list as well -- see the write-up at LWN: https://lwn.net/SubscriberLink/749200/4343911ee71e35cf/ The conclusion seems to be that one should switch to mailman3... -- Marten

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 4:52 AM, Gregor Thalhammer wrote: > > Hi, > > long time ago I wrote a wrapper to to use optimised and parallelized math > functions from Intels vector math library > geggo/uvml: Provide vectorized math function (MKL) for numpy > > I found it

Re: [Numpy-discussion] New NEP: merging multiarray and umath

I think part of the problem is that ufuncs actually have two parts: a generic interface, which turns all its arguments into ndarray (or calls `__array_ufunc__`) and an ndarray-specific implementation of the given function (partially, just the iterator, partially the inner loop). The latter could

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Yes, a tuple of types would make more sense, given `isinstance` -- string abbreviations for those could be there for convenience. -- Marten On Sat, Mar 17, 2018 at 8:25 PM, Eric Wieser wrote: > I would have thought that a simple tuple of types would be more

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

On Wed, Jun 27, 2018 at 3:50 PM, Stephan Hoyer wrote: > So perhaps it's worth "future proofing" the interface by passing `obj` and > `method` to __array_function__ rather than only `func`. It is slower to > call a func via func.__call__ than func, but only very marginally (~100 ns > in my

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

> I did a little more digging, and turned up the __self__ and __func__ > attributes of bound methods: > https://stackoverflow.com/questions/4679592/how-to-find- > instance-of-a-bound-method-in-python > > So we might need another decorator function, but it seems that the current > interface would

Re: [Numpy-discussion] asanyarray vs. asarray

There are exceptions for `matrix` in quite a few places, and there now is warning for `maxtrix` - it might not be bad to use `asanyarray` and add an exception for `maxtrix`. Indeed, I quite like the suggestion by Eric Wieser to just add the exception to `asanyarray` itself - that way when matrix

Re: [Numpy-discussion] asanyarray vs. asarray

e have or want such a concept as "soft support". We intend >> to not break anything that now has asanyarray, i.e. it's supported and >> ideally we have regression tests for all such functions. For anything we >> transition over from asarray to asanyarray, PRs should come with new tests.

[Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

Hi All, While thinking about implementations using __array_function__, I wondered whether the "types" argument passed on is not defined too narrowly. Currently, it only contains the types of arguments that provide __array_ufunc__, but wouldn't it make more sense to provide the unique types of

[Numpy-discussion] Implementations of ndarray.__array_function__ (and ndarray.__array_ufunc__)

Hi again, Another thought about __array_function__, this time about the implementation for ndarray. In it, we currently check whether any of the types define a (different) __array_function__, and, if so, give up. This seems too strict: I think that, at least in principle, subclasses should be

Re: [Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

More specifically: Should we change this? It is quite trivially done, but perhaps I am missing >> a reason for omitting the non-override types. >> > > Realistically, without these other changes in NumPy, how would this > improve code using __array_function__? From a general purpose dispatching >

Re: [Numpy-discussion] Implementations of ndarray.__array_function__ (and ndarray.__array_ufunc__)

On Sun, Nov 4, 2018 at 8:57 PM Stephan Hoyer wrote: > On Sun, Nov 4, 2018 at 8:45 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> Does the above make sense? I realize that the same would be true for >> `__array_ufunc__`, though there the situation

Re: [Numpy-discussion] Should unique types of all arguments be passed on in __array_function__?

Hi Stephan, Another part of your reply worth considering, though slightly off topic for the question here, of what to pass on in `types`: On Sun, Nov 4, 2018 at 7:51 PM Stephan Hoyer wrote: > On Sun, Nov 4, 2018 at 8:03 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> w

Re: [Numpy-discussion] out parameter for np.fromfile

Hi Mark, Having an `out` might make sense. With present numpy, if you are really dealing with a file or file-like object, you might consider using `np.memmap` to access the data more directly. If it is something that looks more like a buffer, `np.frombuffer` may be useful (that doesn't copy data,

  1   2   >