Re: [Numpy-discussion] NumPy Feature Request: Function to wrap angles to range [ 0, 2*pi] or [ -pi, pi ]

How would this proposed function compare to using the modulo operator, like 'arr % (2*pi)'? On Mon, Nov 23, 2020, 16:13 Thomas wrote: > Hi, > > I have a proposal for a feature and I hope this is the right place to post > this. > > The idea is to have a function to map any input angle to the

Re: [Numpy-discussion] New DTypes: Are scalars a central concept in NumPy or not?

Off the cuff, my intuition is that dtypes will want to be able to define how scalar indexing works, and let it return objects other than arrays. So e.g.: - some dtypes might just return a zero-d array - some dtypes might want to return some arbitrary domain-appropriate type, like a datetime dtype

Re: [Numpy-discussion] manylinux upgrade for numpy wheels

Pretty sure the 2010 and 2014 images both have much newer compilers than that. There are still a lot of users on CentOS 6, so I'd still stick to 2010 for now on x86_64 at least. We could potentially start adding 2014 wheels for the other platforms where we currently don't ship wheels – gotta be

Re: [Numpy-discussion] UFunc out argument not forcing high precision loop?

It is pretty weird that these two statements don't necessarily produce the same result: someufunc(*inputs, out=out_arr) out_arr[...] = someufunc(*inputs) On Fri, Sep 27, 2019, 15:02 Sebastian Berg wrote: > On Fri, 2019-09-27 at 11:50 -0700, Sebastian Berg wrote: > > Hi all, > > > > Looking at

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

On Sun, Sep 8, 2019 at 8:40 AM Ralf Gommers wrote: > > > > On Sun, Sep 8, 2019 at 12:54 AM Nathaniel Smith wrote: >> >> On Fri, Sep 6, 2019 at 11:53 AM Ralf Gommers wrote: >> > On Fri, Sep 6, 2019 at 12:53 AM Nathaniel Smith wrote: >> >>

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

On Sun, Sep 8, 2019 at 1:04 AM Hameer Abbasi wrote: > > On 08.09.19 09:53, Nathaniel Smith wrote: >> OTOH, __array_function__ doesn't allow this kind of simplification: if >> we were using __array_function__ for ufuncs, every library would have >> to special-case every

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

On Fri, Sep 6, 2019 at 11:53 AM Ralf Gommers wrote: > On Fri, Sep 6, 2019 at 12:53 AM Nathaniel Smith wrote: >> On Tue, Sep 3, 2019 at 2:04 AM Hameer Abbasi >> wrote: >> > The fact that we're having to design more and more protocols for a lot >> > of very simil

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

On Sat, Sep 7, 2019 at 5:08 PM Ralf Gommers wrote: > > On Sat, Sep 7, 2019 at 4:16 PM Nathaniel Smith wrote: >> >> On Fri, Sep 6, 2019 at 11:04 PM Ralf Gommers wrote: >> > Vendoring means "include the code". So no dependency on an external >>

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

On Fri, Sep 6, 2019 at 11:04 PM Ralf Gommers wrote: > Vendoring means "include the code". So no dependency on an external package. > If we don't vendor, it's going to be either unused, or end up as a dependency > for the whole SciPy/PyData stack. If we vendor it then it also ends up as a

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

On Fri, Sep 6, 2019 at 2:45 PM Ralf Gommers wrote: > There may be another very concrete one (that's not yet in the NEP): allowing > other libraries that consume ndarrays to use overrides. An example is > numpy.fft: currently both mkl_fft and pyfftw monkeypatch NumPy, something we > don't like

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

On Mon, Sep 2, 2019 at 2:15 AM Hameer Abbasi wrote: > Me, Ralf Gommers and Peter Bell (both cc’d) have come up with a proposal on > how to solve the array creation and duck array problems. The solution is > outlined in NEP-31, currently in the form of a PR, [1] Thanks for putting this

Re: [Numpy-discussion] Allowing Dependabot access to the numpy repo

AFAICT all these services work by creating branches inside your repo and then making a PR from that – they don't make their own forks. (Which makes some sense when you consider they would need tens of thousands of forked epos for all the projects they work with.) I don't think there's any need to

Re: [Numpy-discussion] New release note strategy after branching 1.17.

On Wed, Jun 12, 2019 at 12:58 PM Marten van Kerkwijk wrote: > > Overall, in favour of splitting the large files, but I don't like that the > notes stop being under version control (e.g., a follow-up PR slightly changes > things, how does the note gets edited/reverted?). > > Has there been any

Re: [Numpy-discussion] New release note strategy after branching 1.17.

It might be worth considering a tool like 'towncrier'. It's automation to support the workflow where PRs that make changes also include their release notes, so when the release comes you've already done all the work and just have to hit the button. On Wed, Jun 12, 2019, 07:59 Sebastian Berg

Re: [Numpy-discussion] Moving forward with value based casting

I haven't read all the thread super carefully, so I might have missed something, but I think we might want to look at this together with the special rule for scalar casting. IIUC, the basic end-user problem that motivates all thi sis: when you have a simple Python constant whose exact dtype is

Re: [Numpy-discussion] defining a NumPy API standard?

On Sat, Jun 1, 2019 at 11:59 PM Ralf Gommers wrote: > On Sun, Jun 2, 2019 at 12:35 AM Nathaniel Smith wrote: >> >> On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers wrote: >> > I think this is potentially useful, but *far* more prescriptive and >> > deta

Re: [Numpy-discussion] defining a NumPy API standard?

On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers wrote: > I think this is potentially useful, but *far* more prescriptive and detailed > than I had in mind. Both you and Nathaniel seem to have not understood what I > mean by "out of scope", so I think that's my fault in not being explicit > enough.

Re: [Numpy-discussion] defining a NumPy API standard?

On Sat, Jun 1, 2019, 09:13 Ralf Gommers wrote: > > > On Sat, Jun 1, 2019 at 11:32 AM Nathaniel Smith wrote: > >> It's possible I'm not getting what you're thinking, but from what you >> describe in your email I think it's a bad idea. >> > > Hi Nathaniel, I t

Re: [Numpy-discussion] defining a NumPy API standard?

On Sat, Jun 1, 2019, 05:23 Hameer Abbasi wrote: > I think this hits the crux of the issue... There *is* a huge coordination > problem. Users want to move their code from NumPy to Sparse or Dask all the > time, but it’s not trivial to do. And libraries like sparse and Dask want > to follow a

Re: [Numpy-discussion] defining a NumPy API standard?

It's possible I'm not getting what you're thinking, but from what you describe in your email I think it's a bad idea. Standards take a tremendous amount of work (no really, an absurdly massively huge amount of work, more than you can imagine if you haven't done it). And they don't do what people

Re: [Numpy-discussion] Release vs development testing.

On Mon, May 13, 2019, 10:26 Charles R Harris wrote: > I just checked that current wheels show the warnings when `numpy.test()` > is run with latest pytest. However, moving the `pytest.ini` file into the > `numpy` directory is tricky, as we need to tell pytest where to find the > installed file

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Sun, Apr 28, 2019 at 1:38 PM Marten van Kerkwijk wrote: > > Hi Nathaniel, > > I'm a bit confused why` np.concatenate([1, 2], [3, 4])` would be a problem. > In the current model, all (numpy) functions fall back to > `ndarray.__array_function__`, which does know what to do with anything that

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Sun, Apr 28, 2019, 02:22 Ralf Gommers wrote: > One other thought: the proposal in this thread is about skipping the > override mechanism for numpy functions. NEP 18 reserves the freedom to swap > out __array_function__ with __array_ufunc__ if we make something a ufunc. > So

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Sun, Apr 28, 2019, 08:41 Marten van Kerkwijk wrote: > Hi Ralf, > > Thanks for the comments and summary slides. I think you're > over-interpreting my wish to break people's code! I certainly believe - and > think we all agree - that we remain as committed as ever to ensure that > ``` >

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Sat, Apr 27, 2019 at 7:46 PM Stephan Hoyer wrote: > Worst, "__wrapped__" would be difficult to search for, because it already > means something in Python (referring to functools.wrapped). At least > "__numpy_implementation__" and "__skipping_array_function__" are both unique > tokens

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Sat, Apr 27, 2019 at 4:38 PM Hameer Abbasi wrote: > Of course, here’s my proposal: > > We leave NEP-18 as-is for now, and instead of writing separate protocols > for coercion, dtypes and ufuncs (which will be needed somewhere down the > line), we have a discussion about uarray and see if it

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Thu, Apr 25, 2019 at 1:30 PM Hameer Abbasi wrote: > Although, in general, I agree with Stephan’s design goals, I agree with > Marten that the number of protocols are getting larger and may get out of > hand if not handled properly. There’s even one Marten forgot to mention: >

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Thu, Apr 25, 2019 at 10:10 AM Stephan Hoyer wrote: > > On Wed, Apr 24, 2019 at 9:56 PM Nathaniel Smith wrote: >> >> When you say "numpy array specific" and >> "__numpy_(nd)array_implementation__", that sounds to me like you're >> trying to

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Wed, Apr 24, 2019 at 9:45 PM Stephan Hoyer wrote: > With "__numpy_implementation__" I was hoping to evoke "the implementation > used by numpy.ndarray.__array_function__" and "the implementation for NumPy > arrays" rather than "the implementation found in the NumPy library." So it > would

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Mon, Apr 22, 2019 at 11:13 PM Stephan Hoyer wrote: > >> On Mon, Apr 22, 2019 at 9:26 PM Nathaniel Smith wrote: >>> >>> Your last email didn't really clarify anything for me. I get that >>> np.func.__numpy_implementation__ is intended to have the sema

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer wrote: > > On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith wrote: >> >> What's the difference between >> >> np.concatenate.__numpy_implementation__(...) >> >> and >> >> np.ndarray.__array_func

Re: [Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

What's the difference between np.concatenate.__numpy_implementation__(...) and np.ndarray.__array_function__(np.concatenate, ...) ? More generally, I guess I'm not quite clear on how to think about what the "no dispatch" version does, because obviously it doesn't make sense to have *no*

Re: [Numpy-discussion] Behaviour of copy for structured dtypes with gaps

My concern would be that to implement (2), I think .copy() has to either special-case certain dtypes, or else we have to add some kind of "simplify for copy" operation to the dtype protocol. These both add architectural complexity, so maybe it's better to avoid it unless we have a compelling

Re: [Numpy-discussion] Does numpy depend upon a Fortran library?

Yeah, the libgfortran dependency is expected. The question is why this should cause any problems. The wheel building infrastructure goes to great lengths to make sure that the dynamic libraries in the wheels shouldn't interfere with other packages. The original complaint in this thread is very

Re: [Numpy-discussion] asarray/anyarray; matrix/subclass

On Fri, Nov 9, 2018 at 4:59 PM, Stephan Hoyer wrote: > On Fri, Nov 9, 2018 at 6:46 PM Nathaniel Smith wrote: >> >> But matrix isn't the only problem with asanyarray. np.ma also violates >> Liskov. No doubt there are other problematic ndarray subclasses out >> there too

Re: [Numpy-discussion] asarray/anyarray; matrix/subclass

But matrix isn't the only problem with asanyarray. np.ma also violates Liskov. No doubt there are other problematic ndarray subclasses out there too... If we were going to try to reuse asanyarray through some deprecation mechanism, I think we'd need to deprecate allowing asanyarray to return

Re: [Numpy-discussion] Problem with libgfortran installed with pip install numpy

On Wed, Sep 5, 2018 at 4:37 PM, David Grote wrote: > > Hi - I have recently come across this problem. On my mac, I build a Fortran > code, producing a shared object, that I import into Python along with numpy. > This had been working fine until recently when I started seeing sag faults > deep

Re: [Numpy-discussion] Attribute hiding APIs for PyArrayObject

It's probably helpful to know that Py_LIMITED_API is a kinda-experimental thing that was added in CPython 3.2 (see PEP 384) and remains almost 100% unused. It has never been a popular or influential thing (for better or worse). -n On Tue, Oct 30, 2018 at 6:41 PM, Eric Wieser wrote: > In NumPy

Re: [Numpy-discussion] asanyarray vs. asarray

On Fri, Oct 19, 2018 at 6:23 PM, Marten van Kerkwijk wrote: > Hi All, > > It seems there are two extreme possibilities for general functions: > 1. Put `asarray` everywhere. The main benefit that I can see is that even if > people put in list instead of arrays, one is guaranteed to have shape, >

Re: [Numpy-discussion] asanyarray vs. asarray

On Fri, Oct 19, 2018 at 7:00 PM, Charles R Harris wrote: > > On Fri, Oct 19, 2018 at 7:50 PM Eric Wieser > wrote: >> >> Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if >> they cause problems perhaps that should be seen as a sign that ndarray >> subclassing should be

Re: [Numpy-discussion] asanyarray vs. asarray

On Fri, Oct 19, 2018 at 3:28 PM, Ralf Gommers wrote: > > > On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi > wrote: > >> Hi! >> >> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer >> wrote: >> I don't think it makes much sense to change NumPy's existing usage of >> asarray() to asanyarray()

Re: [Numpy-discussion] A minor milestone

On Fri, Sep 7, 2018 at 6:33 PM, Charles R Harris wrote: > Thanks for the link. It would be nice to improve the Windows numbers, Linux > is still very dominant. I suppose that might be an artifact of the systems > used by developers as opposed to end users. It would be a different open > source

Re: [Numpy-discussion] A minor milestone

On Fri, Sep 7, 2018 at 1:19 AM, Hans Dembinski wrote: > >> On 7. Sep 2018, at 06:33, Nathaniel Smith wrote: >> >> Looking at https://pypistats.org/packages/numpy , it appears that >> August 24 was the last day when numpy had more Python 2 downloads than >&g

[Numpy-discussion] A minor milestone

Looking at https://pypistats.org/packages/numpy , it appears that August 24 was the last day when numpy had more Python 2 downloads than Python 3 downloads (maybe ever?). -n -- Nathaniel J. Smith -- https://vorpus.org ___ NumPy-Discussion mailing list

Re: [Numpy-discussion] rescuing missing data documents

(authors Matthew Brett, Nathaniel > Smith), > 2. https://gist.github.com/njsmith/1068264 (author Nathaniel Smith), > as well as another summary: > https://github.com/njsmith/numpy/wiki/NA-discussion-status > > I'd like to see the NEPs rescued, and the summary moved from the numpy

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

On Wed, Aug 29, 2018, 02:44 Matti Picus wrote: > On 29/08/18 10:37, Nathaniel Smith wrote: > > it's easy to imagine scenarios where the > > people being broken aren't the ones who had a chance to read the docs > > – e.g. if a major package starts relying on __array_function

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

On Fri, Aug 24, 2018 at 4:00 PM, Stephan Hoyer wrote: > On Fri, Aug 24, 2018 at 3:14 PM Nathaniel Smith wrote: >> >> Yeah, the reason warnings are normally recommended is because >> normally, you want to make it easy to silence. But this is the rare >> case where I

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

On Fri, Aug 24, 2018 at 1:46 PM, Stephan Hoyer wrote: > On Fri, Aug 24, 2018 at 1:36 AM Hameer Abbasi > wrote: >> >> >> On Fri, Aug 24, 2018 at 9:38 AM Nathaniel Smith wrote: >>> >>> On Thu, Aug 23, 2018 at 9:02 AM, wrote: >>> > I migh

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

On Fri, Aug 24, 2018, 09:07 Hameer Abbasi wrote: > > > On Fri, Aug 24, 2018 at 5:55 PM Stephan Hoyer wrote: > >> On Thu, Aug 23, 2018 at 1:06 PM Hameer Abbasi >> wrote: >> >>> I might add that if it’s a mandatory part of the protocol, then not all >>> things will work. For example, if XArray

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

On Thu, Aug 23, 2018 at 9:02 AM, wrote: > I might add that most duck array authors are highly unlikely to be newcomers > to the Python space. We should just put a big warning there while enabling > and that’ll be enough to scare away most devs from doing it by default. That's a reasonable

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

On Tue, Aug 21, 2018 at 6:12 PM, Stephan Hoyer wrote: > On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote: >> >> >> My suggestion: at numpy import time, check for an envvar, like say >> >> NUMPY_EXPERIMENTAL_ARRAY_FUNCTION=1. If it's not set, then all the &g

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

On Tue, Aug 21, 2018 at 9:39 AM, Stephan Hoyer wrote: > On Tue, Aug 21, 2018 at 12:21 AM Nathaniel Smith wrote: >> >> On Wed, Aug 15, 2018 at 9:45 AM, Stephan Hoyer wrote: >> > This avoids a classic subclassing problem that has plagued NumPy for >> > years, &

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

On Wed, Aug 15, 2018 at 9:45 AM, Stephan Hoyer wrote: > RE: accidental differences in behavior: > > I actually think that the __array_function__ approach is *less* prone to > accidental differences in behavior, because we require implementing every > function directly (or it raises an error). > >

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

On Mon, Aug 13, 2018 at 2:44 AM, Nathaniel Smith wrote: > So this is like... an extreme version of technical debt. You're making > a deal with the devil for wealth and fame, and then eventually the > bill becomes due. It's hard for me to say categorically that this is a > bad idea –

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

Hey all, So I've finally read through NEP 18 (__array_function__). Sorry again for the delay! It's an impressive piece of work! Thanks to the many authors; there's clearly been a lot of thought put into this. # The trade-off between comprehensive APIs versus clean APIs At a high-level, what

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

I'm sorry, I've been trying to find the time to read what you ended up with, and haven't managed yet – could I get a few days extension? :-) -n On Wed, Aug 1, 2018 at 5:27 PM, Stephan Hoyer wrote: > I propose to accept NEP-18, "A dispatch mechanism for NumPy’s high level > array functions": >

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

On Thu, Aug 2, 2018 at 10:07 AM, Antoine Pitrou wrote: > What if someone is wearing a religious symbol? > > If one is concerned about horrible beliefs or opinions, there are a > good deal of them in many religious ("holy") books (*), yet CoCs are > generally meant to prohibit discrimination based

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

On Wed, Aug 1, 2018 at 8:34 PM, Ryan May wrote: > So I hear all the arguments about people feeling unsafe due to some truly > despicable, discriminatory behavior, and I want absolutely no parts of > protecting that. However, I also recognize that we in the U.S. are in a > particularly divisive

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

On Wed, Aug 1, 2018 at 8:37 AM, Ralf Gommers wrote: > > On Wed, Aug 1, 2018 at 8:12 AM, Nathan Goldbaum > wrote: >> >> On Wed, Aug 1, 2018 at 9:49 AM, Ralf Gommers >> wrote: >>> >>> >>> >>> On Wed, Aug 1, 2018 at 12:20 AM, Nathan Goldbaum >>> wrote: I realize this was probably

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

On Sun, Jul 22, 2018 at 12:28 PM, Ralf Gommers wrote: > On Sat, Jul 21, 2018 at 7:15 PM, Nathaniel Smith wrote: >> Speaking of examples: I hate to say this because in general I think >> using examples is a great idea. But... I think you should delete most >> of these

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

On Sat, Jul 21, 2018 at 5:46 PM, Hameer Abbasi wrote: > The possibility of another major version change (possibly the same one) > where we re-write all portions that were agreed upon (via NEPs) to be > re-written, with a longer LTS release (3 years? 5?). > > I’m thinking this one could be similar

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

On Sat, Jul 21, 2018 at 4:48 PM, Ralf Gommers wrote: > Hi all, > > Here is a first draft of a NEP on backwards compatibility and deprecation > policy. This I think mostly formalized what we've done for the last couple > of years, however I'm sure opinions and wish lists will differ here. Oh

Re: [Numpy-discussion] we held an impromptu dtype brainstorming sesison at SciPy

A few quick things that jumped out at me: - I think the discussion of __array_ufunc__ on dtypes is confused. Dtypes already have a generic mechanism for overriding ufuncs (the ufunc loop dispatch mechanism), it's separate from __array_ufunc__ (so in theory you could e.g. have a user-defined array

[Numpy-discussion] NEP 22 — Duck typing for NumPy arrays – high level overview

Hi all, Here's a NEP that Stephan and I wrote (actually a few months ago, but then I was super slow, thank you Stephan for your patience). It tries to lay out a high-level overview of where we're trying to go with all this duck array stuff, and some general guidelines that we've gradually come

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

On Sat, Jun 30, 2018 at 6:51 AM, Marten van Kerkwijk wrote: > Hi All, > > In case it was missed because people have tuned out of the thread: Matti and > I proposed last Tuesday to accept NEP 20 (on coming Tuesday, as per NEP 0), > which introduces notation for generalized ufuncs allowing fixed,

Re: [Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

On Fri, Jun 29, 2018 at 3:28 PM, Marten van Kerkwijk wrote: > Agreed on accepting the NEP! But it is not the first proposal to accept > under the new rules - that goes to the broadcasting NEP (though perhaps I > wasn't sufficiently explicit in stating that I was starting a > count-down...). --

Re: [Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

, 2018 at 3:18 PM, Nathaniel Smith wrote: > Hi all, > > I propose that we accept NEP 15: Merging multiarray and umath: > > http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html > > The core part of this proposal was uncontroversial. The main point of > discussi

[Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

Hi all, I propose that we accept NEP 15: Merging multiarray and umath: http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html The core part of this proposal was uncontroversial. The main point of discussion was whether it was OK to deprecate set_numeric_ops, or whether it had some

Re: [Numpy-discussion] NEP: Random Number Generator Policy

On Sun, Jun 10, 2018 at 11:53 PM, Ralf Gommers wrote: > > On Sun, Jun 10, 2018 at 11:15 PM, Robert Kern wrote: >> >> The intention of this code is to shuffle two same-length sequences in the >> same way. So now if I write my code well to call np.random.seed() once at >> the start of my program,

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

On Thu, May 31, 2018 at 4:20 AM, Marten van Kerkwijk wrote: > 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 >

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

On Wed, May 30, 2018 at 11:14 AM, Marten van Kerkwijk wrote: > 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]

Re: [Numpy-discussion] matmul as a ufunc

On Mon, May 28, 2018, 20:41 Stephan Hoyer wrote: > On Mon, May 28, 2018 at 7:36 PM Eric Wieser > wrote: > >> which ensure that it is still well defined (as the identity) on 1d >> arrays. >> >> This strikes me as a bad idea. There’s already enough confusion from >> beginners that array_1d.T is a

Re: [Numpy-discussion] matmul as a ufunc

On Mon, May 28, 2018 at 4:26 PM, Stephan Hoyer wrote: > On Mon, May 21, 2018 at 5:42 PM Matti Picus wrote: >> >> - create a wrapper that can convince the ufunc mechanism to call >> __array_ufunc__ even on functions that are not true ufuncs > > > I am somewhat opposed to this approach, because

Re: [Numpy-discussion] Efficiency of Numpy wheels and simple way to benchmark Numpy installation?

Performance is an incredibly multi-dimensional thing. Modern computers are incredibly complex, with layers of interacting caches, different microarchitectural features (do you have AVX2? does your cpu's branch predictor interact in a funny way with your workload?), compiler optimizations that vary

Re: [Numpy-discussion] Turn numpy.ones_like into a ufunc

I would like to see a plan for how we're going to handle zeroes_like, empty_like, ones_like, and full_like before we start making changes to any of them. On Fri, May 18, 2018, 05:33 Matthew Rocklin wrote: > Hi All, > > I would like to see the numpy.ones_like function operate

Re: [Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

Even knowing that, it's still confusing that round(np.float64(0.0)) isn't the same as round(0.0). The reason is a Python 2 / Python 3 thing: in Python 2, round returns a float, while on Python 3, it returns an integer – but numpy still uses the python 2 behavior everywhere. I'm not sure if it's

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

On Sat, Mar 10, 2018 at 4:27 AM, Matthew Rocklin wrote: > I'm very glad to see this discussion. > > I think that coming up with a single definition of array-like may be > difficult, and that we might end up wanting to embrace duck typing instead. > > It seems to me that

Re: [Numpy-discussion] PR to add a function to calculate histogram edges without calculating the histogram

relevant when `density` is passed to the individual > histogram invocations. Does matplotlib handle that correctly for stacked > histograms? > > On Thu, Mar 15, 2018, 20:14 Nathaniel Smith <n...@pobox.com> wrote: > >> Instead of an nobs argument, maybe we should have a version

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

On Mar 12, 2018 12:02, "Charles R Harris" wrote: If we accept this NEP, I'd like to get it done soon, preferably and the next few months, so that it is finished before we drop Python 2.7 support. That will make maintenance of the NumPy long term support release

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

On Thu, Mar 8, 2018 at 5:51 PM, Juan Nunez-Iglesias wrote: >> Finally for the name, what about `asduckarray`? Thought perhaps that could >> be a source of confusion, and given the gradation of duck array like types. > > I suggest that the name should *not* use programmer

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

On Fri, Mar 9, 2018 at 11:51 AM, Stefan van der Walt wrote: > On Fri, 09 Mar 2018 17:00:43 +, Stephan Hoyer wrote: >> I'll note that we basically used GitHub for revising __array_ufunc__ NEP, >> and I think that worked out better for everyone involved. The discussion >>

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

On Thu, Mar 8, 2018 at 10:26 PM, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk >> <m.h.vankerkw...@gmail.com> wrote:

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

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk wrote: > Hi Nathaniel, > > Overall, hugely in favour! For detailed comments, it would be good to > have a link to a PR; could you put that up? Well, there's a PR here: https://github.com/numpy/numpy/pull/10706 But,

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

Hi all, Here's a more substantive NEP: trying to define how to define a standard way for functions to say that they can accept any "duck array". Biggest open question for me: the name "asabstractarray" kinda sucks (for reasons described in the NEP), and I'd love to have something better. Any

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

On Thu, Mar 8, 2018 at 12:47 AM, Eric Wieser wrote: > This means that ndarray needs to know about ufuncs – so instead of a clean > layering, we have a circular dependency. > > Perhaps we should split ndarray into a base_ndarray class with no arithmetic > support (add,

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

Hi all, Well, this is something that we've discussed for a while and I think generally has consensus already, but I figured I'd write it down anyway to make sure. There's a rendered version here:

Re: [Numpy-discussion] Moving NumPy's PRNG Forward

On Fri, Jan 19, 2018 at 6:55 AM, Robert Kern wrote: [...] > There seems to be a lot of pent-up motivation to improve on the random > number generation, in particular the distributions, that has been blocked by > our policy. I think we've lost a few potential first-time

Re: [Numpy-discussion] [SciPy-Dev] RFC: comments to BLAS committee from numpy/scipy devs

On Tue, Jan 9, 2018 at 12:53 PM, Tyler Reddy wrote: > One common issue in computational geometry is the need to operate rapidly on > arrays with "heterogeneous shapes." > > So, an array that has rows with different numbers of columns -- shape (1,3) > for the first

Re: [Numpy-discussion] [SciPy-Dev] RFC: comments to BLAS committee from numpy/scipy devs

On Tue, Jan 9, 2018 at 3:40 AM, Ilhan Polat wrote: > I couldn't find an item to place this but I think ilaenv and also calling > the function twice (one with lwork=-1 and reading the optimal block size and > the call the function again properly with lwork=) in LAPACK needs

[Numpy-discussion] RFC: comments to BLAS committee from numpy/scipy devs

Hi all, As mentioned earlier [1][2], there's work underway to revise and update the BLAS standard -- e.g. we might get support for strided arrays and lose xerbla! There's a draft at [3]. They're interested in feedback from users, so I've written up a first draft of comments about what we would

Re: [Numpy-discussion] NumPy 1.14.0 release

On Sun, Jan 7, 2018 at 12:59 PM, Allan Haldane wrote: > On 01/07/2018 12:37 PM, Ralf Gommers wrote: >> >> >> >> On Sun, Jan 7, 2018 at 2:00 PM, Charles R Harris >> > wrote: >> >> Hi All, >> >> On behalf

Re: [Numpy-discussion] Another grant update, & numpy job ad is up!

On Dec 22, 2017 8:35 AM, "Charles R Harris" <charlesr.har...@gmail.com> wrote: On Thu, Dec 21, 2017 at 6:38 PM, Nathaniel Smith <n...@pobox.com> wrote: > Hi all, > > Two exciting bits of news: > > 1) We just posted the announcement of a second gran

Re: [Numpy-discussion] building numpy with python3.7

On Fri, Dec 15, 2017 at 2:42 AM, Hannes Breytenbach wrote: > > I don't think this is a cython version issue - cloned the latest version from > git yesterday... > > python3.7 -c "import cython; print(cython.__version__)" > 0.28a0 It is a cython version issue:

Re: [Numpy-discussion] Which rule makes x[np.newaxis, :] and x[np.newaxis] equivalent?

On Tue, Dec 12, 2017 at 12:02 AM, Joe wrote: > Hi, > > question says it all. I looked through the basic and advanced indexing, > but I could not find the rule that is applied to make > x[np.newaxis,:] and x[np.newaxis] the same. I think it's the general rule that all

Re: [Numpy-discussion] NEP process update

On Tue, Dec 5, 2017 at 5:32 PM, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Wed, Dec 6, 2017 at 1:49 PM, Nathaniel Smith <n...@pobox.com> wrote: >> - NEPs are really part of the development process, not an output for >> end-users -- they're c

Re: [Numpy-discussion] NEP process update

On Tue, Dec 5, 2017 at 4:12 PM, Ralf Gommers wrote: > On Wed, Dec 6, 2017 at 12:31 PM, Jarrod Millman > wrote: >> Assuming that sounds good, my tentative next steps are: >> >> - I'll draft a purpose and process NEP based on PEP 1 and a few other >>

Re: [Numpy-discussion] Type annotations for NumPy

On Tue, Dec 5, 2017 at 10:04 AM, Stephan Hoyer wrote: > This discussion has died down, but I don't want to lose momentum . > > It sounds like there is at least strong interest from a subset of our > community in type annotations. Are there any objections to the first part of >

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

On Thu, Nov 30, 2017 at 11:39 AM, Charles R Harris wrote: > > > On Thu, Nov 30, 2017 at 11:43 AM, Ralf Gommers > wrote: >> I'd suggest any release in the next couple of years is fine,but the one >> where we drop Python 2 support is probably the

Re: [Numpy-discussion] Type annotations for NumPy

On Sat, Nov 25, 2017 at 3:09 PM, Juan Nunez-Iglesias wrote: > This is a complete outsider’s perspective but > > (a) it would be good if NumPy type annotations could include an “array_like” > type that allows lists, tuples, etc. I'm sure this will exist. > (b) I’ve always

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

On Nov 13, 2017 12:03, "Gael Varoquaux" wrote: On Mon, Nov 13, 2017 at 10:26:31AM -0800, Matthias Bussonnier wrote: > This behavior is "new" (Nov/Dec 2016). [snip] > It _does_ require to have a version of pip which is not decades old Just to check that I am not

  1   2   >