[Numpy-discussion] Re: NEP 56: array API standard support in the main numpy namespace

On Sun, Jan 7, 2024 at 8:08 AM Ralf Gommers wrote: > This NEP will supersede the following NEPs: > > - :ref:`NEP30` (never implemented) > - :ref:`NEP31` (never implemented) > - :ref:`NEP37` (never implemented; the ``__array_module__`` idea is > basically > the same as ``__array_namespace__``)

[Numpy-discussion] Re: Fixing definition of reduceat for Numpy 2.0?

On Fri, Dec 22, 2023 at 12:34 PM Martin Ling wrote: > Hi folks, > > I don't follow numpy development in much detail these days but I see > that there is a 2.0 release planned soon. > > Would this be an opportunity to change the behaviour of 'reduceat'? > > This issue has been open in some form

[Numpy-discussion] Re: Adding NumpyUnpickler to Numpy 1.26 and future Numpy 2.0

On Mon, Oct 9, 2023 at 2:29 PM Nathan wrote: > However, one thing we can do now is, for that one particular symbol that > we know is going to be in every pickle file and probably never elsewhere, > is intercept that one import and instead of generating a generic warning > about np.core being

[Numpy-discussion] Re: NEP 55 - Add a UTF-8 Variable-Width String DType to NumPy

On Wed, Aug 30, 2023 at 4:25 AM Ralf Gommers wrote: > > > On Tue, Aug 29, 2023 at 4:08 PM Nathan wrote: > >> The NEP was merged in draft form, see below. >> >> https://numpy.org/neps/nep-0055-string_dtype.html >> > > This is a really nice NEP, thanks Nathan! I see that questions and >

[Numpy-discussion] Re: Giving deprecation of e.g. `float(np.array([1]))` a shot (not 0-d)

On Thu, Apr 20, 2023 at 9:12 AM Sebastian Berg wrote: > Hi all, > > Unlike conversions of 0-d arrays via: > > float(np.array([1])) > > conversions of 1-D or higher dimensional arrays with a single element > are a bit strange: > > float(np.array([1])) > > And deprecating it has come up

[Numpy-discussion] Re: removing NUMPY_EXPERIMENTAL_ARRAY_FUNCTION env var

+1 for removing this environment variable. It was never intended to stick around this long. On Fri, Mar 10, 2023 at 6:48 AM Ralf Gommers wrote: > Hi all, > > In https://github.com/numpy/numpy/pull/23364 we touched on the > NUMPY_EXPERIMENTAL_ARRAY_FUNCTION environment variable. This was a >

[Numpy-discussion] Re: status of long double support and what to do about it

On Thu, Nov 17, 2022 at 5:29 PM Scott Ransom wrote: > A quick response from one of the leaders of a team that requires 80bit > extended precision for > astronomical work... > > "extended precision is pretty useless" unless you need it. And the > high-precision pulsar timing > community needs it.

[Numpy-discussion] Re: NEP 51: Changing the Representation of NumPy Scalars

On Mon, Oct 31, 2022 at 12:51 PM Aaron Meurer wrote: > I like this. NumPy scalar printing is confusing to new users, who > might think they are Python scalars. And even if you understand them, > it's always been annoying that you have to do further introspection to > see the dtype. I also like

[Numpy-discussion] Re: Representation of NumPy scalars

On Thu, Sep 8, 2022 at 3:41 AM Stefano Miccoli wrote: > On 8 Sep 2022, at 11:39, numpy-discussion-requ...@python.org wrote: > > TL;DR: NumPy scalars representation is e.g. `34.3` instead of > `float32(34.3)`. So the representation is missing the type > information. What are your thoughts on

[Numpy-discussion] Re: Exporting numpy arrays to binary JSON (BJData) for better portability

On Sat, Aug 27, 2022 at 9:17 AM Qianqian Fang wrote: > 2. a key belief > > of the NeuroJSON project is that "human readability" is the single most > important factor to decide the longevity of both codes and data. The >

[Numpy-discussion] Re: Proposal: Indexing by callables

On Sat, Jul 30, 2022 at 5:51 PM Matteo Santamaria wrote: > Hi all, > > > > I’d like to open a discussion on supporting callables within > `np.ndarray.__getitem__`. The intent is to make long function-chaining > expressions more ergonomic by removing the need for an intermediary, > temporary

[Numpy-discussion] Re: copy="never" discussion and no deprecation cycle?

On Mon, Jul 5, 2021 at 11:19 AM Stefan van der Walt wrote: > The reason why Gagandeep started working on this is so we can have the > never-copy behavior in the `numpy.array_api` namespace. For the `asarray` > function there, the `copy` keyword is still boolean, with description: > > Whether

[Numpy-discussion] Re: Speeding up isin1d and adding a "method" or similar

I think this is a great idea! I don't see any downsides here. As for the method name, I would lean towards calling it "kind" and using a default value of None for automatic selection, for consistency with np.sort. On Thu, Jun 16, 2022 at 6:14 AM Sebastian Berg wrote: > Hi all, > > there is a

[Numpy-discussion] Re: Dropping the pdf documentation.

On Sun, May 22, 2022 at 3:52 PM Rohit Goswami wrote: > Being very hard to read should not be reason enough to stop generating > them. In places with little to no internet connectivity often the PDF > documentation is invaluable. > The HTML docs can also be downloaded for offline use. Perhaps

[Numpy-discussion] Re: Dropping the pdf documentation.

+1 let’s drop the PDF docs. They are already very hard to read. On Sun, May 22, 2022 at 1:06 PM Charles R Harris wrote: > Hi All, > > This is a proposal to drop the generation of pdf documentation and only > generate the html version. This is a one way change due to the difficulty >

[Numpy-discussion] Re: Exposing `from_dlpack` to the main namespace

On Tue, Mar 8, 2022 at 8:27 AM Stefan van der Walt wrote: > In other places in the ecosystem, like pandas and xarray, `from_x` and > friends live as static methods on their respective classes. Any reason not > to add this as `numpy.array.from_dlpack`? We may also want to consider > adding all

[Numpy-discussion] Re: [Job] NumPy Open Source Developer at NVIDIA

Hi Inessa -- could you share the original job description? It looks like it got lost from your message :) On Wed, Mar 2, 2022 at 12:28 PM Inessa Pawson wrote: > Hi, Mike! > This is wonderful news! NumPy could certainly use more help. > > Cheers, > Inessa > > Inessa Pawson > Contributor

[Numpy-discussion] Re: Writing an array subclass in a compiled language with proper dispatch

There are no C-level APIs for __array_function__ or __array_ufunc__, so yes, at a high-level Python methods will be invoked by NumPy. That said, NumPy's logic for handling __array_function__ and __array_ufunc__ methods is written in highly optimized C. If you wrote your own __array_function__ and

[Numpy-discussion] Re: Fwd: ndarray should offer __format__ that can adjust precision

On Fri, Dec 3, 2021 at 12:07 PM Sebastian Berg wrote: > This discussion has recently surfaced again and I am wondering what the > stance on it is for people? > > The PR is: https://github.com/numpy/numpy/pull/19550 > > I.e. that things like "f{arr:.2f}" would be enabled in certain cases, >

[Numpy-discussion] Re: Proposal - Making ndarray object JSON serializable via standardized JData annotations

Hi Qianqian, What is your concrete proposal for NumPy here? Are you suggesting new methods or functions like to_json/from_json in NumPy itself? As far as I can tell, reading/writing in your custom JSON format already works with your jdata library. Best, Stephan On Thu, Nov 25, 2021 at 2:35 PM

[Numpy-discussion] Re: Putting in `np.ma.ndenumerate` MaskedArray specific ndenumerate

I think a separate ndenumerate() in the masked array namespace would make a lot of sense. This is much less risky than changing np.ndenumerate(). On Wed, Nov 17, 2021 at 11:54 AM Andras Deak wrote: > On Wed, Nov 17, 2021 at 8:35 PM Sebastian Berg > wrote: > >> On Wed, 2021-11-17 at 19:49

[Numpy-discussion] Re: Idea: adding `ndarray.isin` for consistency with pandas

Thanks for the suggestion. It isn't a hard rule, but the ndarray namespace is already very large and cluttered, so generally we have avoided adding new methods in recent years. (This policy might be worth codifying in a NEP.) On Mon, Oct 11, 2021 at 7:35 AM Max Ghenis wrote: > `numpy.isin` is

[Numpy-discussion] Re: spam on the mailing lists

it. I think GitHub discussions is a perfectly fine web-based platform and definitely an improvement over a mailing list, but do like Discourse a little better. It's literally one click for a user to sign up to post on Discourse if they already have a GitHub account. > On Fri, Oct 1, 2021 a

[Numpy-discussion] Re: spam on the mailing lists

On Fri, Oct 1, 2021 at 8:55 AM Matthew Brett wrote: > Only to say that: > > * I used to have a very firm preference for mail, because I'm pretty > happy with Gmail as a mail interface, and I didn't want to have > another channel I had to monitor, but > * I've spent more time on Discourse over

[Numpy-discussion] Re: spam on the mailing lists

On Wed, Sep 29, 2021 at 7:55 PM Juan Nunez-Iglesias wrote: > On scikit-image, we've moderated *subscriptions*, and only subscribers can > post without being moderated, but still spam gets through, because it's > hard to vet whether an email address is "genuine", so sometimes we allow > the

Re: [Numpy-discussion] deprecating float(x) for ndim > 0

On Wed, Sep 15, 2021 at 5:18 AM Nico Schlömer wrote: > Hi everyone, > > This is seeking input on PR [1] which I've worked on with @eric-wieser > and @seberg. It deprecates > ``` > float(x) > ``` > if `x` is an array of ndim > 0. (It works with all arrays of size 1 > right now.) This aligns the

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

On Thu, Jun 24, 2021 at 1:03 AM Ralf Gommers wrote: > I agree with this. Enums are nice _in theory_, but once you start using > them you quickly figure out they're clunky, plus the all-caps looks bad > (I'd consider ignoring that style recommendation). For API design they > don't make all that

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

On Thu, Jun 17, 2021 at 1:29 PM Matti Picus wrote: > On 16/6/21 11:00 pm, Sebastian Berg wrote: > > > Hi all, > > > > (sorry for the length, details/discussion below) > > > > On the triage call, there seemed a preference to just try to skip the > > deprecation and introduce `copy="never"`,

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

On Wed, Jun 16, 2021 at 1:01 PM Sebastian Berg wrote: > 2. We introduce `copy="never"`, `copy="if_needed"` and `copy="always"` >as strings (all other strings will be a `TypeError`): > >* Problem: `copy="never"` currently means `copy=True` (the opposite) >Which means new

Re: [Numpy-discussion] ANN: MyGrad 2.0 - Drop-in autodiff for NumPy

On Sun, Apr 18, 2021 at 9:11 AM Ryan Soklaski wrote: > MyGrad is not meant to "compete" with the likes of PyTorch and JAX, which > are fantastically-fast and powerful autodiff libraries. Rather, its > emphasis is on being lightweight and seamless to use in NumPy-centric > workflows. > Thanks

Re: [Numpy-discussion] Is there a defined way to "unpad" an array, and if not, should there be?

On Mon, Apr 12, 2021 at 5:12 PM Jeff Gostick wrote: > I guess I should have clarified that I was inquiring about proposing a > 'feature request'. The github site suggested I open a discussion on this > list first. There are several ways to effectively unpad an array as has > been pointed out,

Re: [Numpy-discussion] Is there a defined way to "unpad" an array, and if not, should there be?

The easy way to unpad an array is by indexing with slices, e.g., x[20:-4] to undo a padding of [(20, 4)]. Just be careful about unpadding "zero" elements on the right hand side, because Python interprets an ending slice of zero differently -- you need to write something like x[20:] to undo padding

Re: [Numpy-discussion] NumPy logo merchandise

I love your mittens! NumPy really should be in the NumFOCUS store, but it currently isn't: https://shop.spreadshirt.com/numfocus/all I'll make some inquiries to see if we can sort that out :). On Thu, Mar 4, 2021 at 2:43 PM wrote: > Hello. I was looking for a T-shirt with Numpy logo but

Re: [Numpy-discussion] NEP 48: Spending NumPy Project funds

On Mon, Feb 22, 2021 at 4:08 AM Pearu Peterson wrote: > Hi, > > See GH discussion starting at > https://github.com/numpy/numpy/pull/18454#discussion_r579967791 for the > raised issue that is now moved here. > > Re "Compensating fairly" section: > > The NEP proposes location-dependent contracts

Re: [Numpy-discussion] ENH: Proposal to add atleast_nd function

On Wed, Feb 17, 2021 at 2:37 AM Ralf Gommers wrote: > > > On Wed, Feb 17, 2021 at 12:26 AM Stefan van der Walt > wrote: > >> On Tue, Feb 16, 2021, at 07:49, Joseph Fox-Rabinovitz wrote: >> >> I'm getting a generally lukewarm not negative response. Should we put it >> to a vote? >> >> >> Things

Re: [Numpy-discussion] What to do about structured string dtype and string regression?

On Tue, Feb 16, 2021 at 3:13 PM Sebastian Berg wrote: > Hi all, > > In https://github.com/numpy/numpy/issues/18407 it was reported that > there is a regression for `np.array()` and friends in NumPy 1.20 for > code such as: > > np.array(["1234"], dtype=("U1", 4)) > # NumPy 1.20:

Re: [Numpy-discussion] ENH: Proposal to add atleast_nd function

tomatic conversion is convenient (and endemic within the SciPy ecosystem), but is also a common source of bugs. On Thu, Feb 11, 2021 at 1:56 AM Stephan Hoyer wrote: > >> On Wed, Feb 10, 2021 at 9:48 PM Juan Nunez-Iglesias >> wrote: >> >>> I totally agree with the namespac

Re: [Numpy-discussion] ENH: Proposal to add atleast_nd function

On Wed, Feb 10, 2021 at 9:48 PM Juan Nunez-Iglesias wrote: > I totally agree with the namespace clutter concern, but honestly, I would > use `atleast_nd` with its `pos` argument (I might rename it to `position`, > `axis`, or `axis_position`) any day over `at_least{1,2,3}d`, for which I > had no

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

On Tue, Jan 26, 2021 at 12:45 AM Stefan van der Walt wrote: > On Tue, Jan 26, 2021, at 00:25, Ralf Gommers wrote: > > The update PR was merged after a lot more review on GitHub. I propose we > change the status of this NEP to Accepted. We'll merge a PR to do so unless > there are objections

Re: [Numpy-discussion] Addition of new distributions: Polya-gamma

Thanks for putting together this clean implementation! My concern is that Polya-Gamma is not popular enough to warrant inclusion in NumPy, which tries very hard to limit scope these days. For example, Polya-Gamma isn’t implemented in scioy.stats and doesn’t have a Wikipedia page, both of which

Re: [Numpy-discussion] Feature request: Alternative representation for arrays with many dimensions

On Wed, Dec 9, 2020 at 2:24 PM Fang Zhang wrote: > By default, the __repr__ and __str__ functions of NumPy arrays summarize > long arrays (i.e. omit all items but a few at beginning and end of each > dimension), which is a good thing because when debugging, programmers can > call print() on

Re: [Numpy-discussion] np.{bool,float,int} deprecation

On Wed, Dec 9, 2020 at 1:07 PM Aaron Meurer wrote: > On Wed, Dec 9, 2020 at 9:41 AM Sebastian Berg > wrote: > > > > On Mon, 2020-12-07 at 14:18 -0700, Aaron Meurer wrote: > > > Regarding np.bool specifically, if you want to deprecate this, you > > > might want to discuss this with us at the

Re: [Numpy-discussion] Rules for argument parsing/forwarding in __array_function__ and __array_ufunc__

On Wed, Dec 2, 2020 at 3:39 PM Sebastian Berg wrote: > 1. If an argument is invalid in NumPy it is considered and error. >For example: > >np.log(arr, my_weird_argument=True) > >is always an error even if the `__array_function__` implementation >of `arr` would support it. >

Re: [Numpy-discussion] np.{bool,float,int} deprecation

On Sat, Dec 5, 2020 at 9:24 PM Mark Harfouche wrote: > If the answer is to deprecate > > np.int(1) == int(1) > > then one can add a warning to the __init__ of the np.int class, but > continue to subclass the python int class. > > It just doesn’t seem worthwhile to to stop people from using

Re: [Numpy-discussion] datetime64: Remove deprecation warning when constructing with timezone

I can try to dig up the old discussions, but datetime64 used to implement both (1) and (3), and this was updated in a very intentional way. Datetime64 now works like Python's own time-zone naive datetime.datetime objects. The documentation referencing "Z" should be updated -- datetime64 can be in

Re: [Numpy-discussion] Add sliding_window_view method to numpy

On Thu, Nov 5, 2020 at 11:16 AM Ralf Gommers wrote: > > > On Thu, Nov 5, 2020 at 4:56 PM Sebastian Berg > wrote: > >> Hi all, >> >> just a brief note that I merged this proposal: >> >> https://github.com/numpy/numpy/pull/17394 >> >> adding `np.sliding_window_view` into the 1.20 release of

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

wed the NEP similarly: > > https://github.com/networkx/networkx/issues/4027 > > Of all the packages, it makes sense for NumPy to behave most > conservatively with depreciations. The NEP suggests allowable support > periods, but as far as I recall does not enforce minima

Re: [Numpy-discussion] Ndarray static typing: Order of generic types

On Wed, Oct 28, 2020 at 2:44 PM bas van beek wrote: > Hey all, > > > > With the recent merging of numpy/numpy#16759 > we’re at the point where ` > ndarray` can be made generic w.r.t. its dtype and shape. > > An open question which yet remains is to

Re: [Numpy-discussion] new function: broadcast_shapes

On Thu, Oct 15, 2020 at 11:46 AM Warren Weckesser < warren.weckes...@gmail.com> wrote: > On 10/15/20, Madhulika Jain Chambers wrote: > > Hello all, > > > > I opened a PR to add a function which returns the broadcasted shape from > a > > given set of shapes: > >

Re: [Numpy-discussion] Einops cross-linking from einsum

On Sat, Sep 26, 2020 at 10:53 PM Alex Rogozhnikov < alex.rogozhni...@yandex.ru> wrote: > Hello all, > > I'm developer of einops - python package for readable and reliable tensor > operations. > Einops handles different types of tensors (including numpy, pytorch, jax, > tensorflow and others) and

Re: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments

On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini wrote: > Dear all, > > > > > > I would like to know your opinion on how to address a specific need of > > > the new PEP 637: > > > > > > https://github.com/python/peps/blob/master/pep-0637.txt > > > > > > Such PEP would make a syntax like the

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

On Thu, Aug 13, 2020 at 5:22 AM Ralf Gommers wrote: > Thanks for raising these concerns Ilhan and Juan, and for answering Peter. > Let me give my perspective as well. > > To start with, this is not specifically about Peter's NEP and PR. NEP 35 > simply follows the pattern set by previous PRs,

Re: [Numpy-discussion] Add Chebyshev (cosine) transforms implemented via FFTs

On Tue, Aug 4, 2020 at 6:10 PM Charles R Harris wrote: > > > On Tue, Aug 4, 2020 at 4:55 AM Ralf Gommers > wrote: > >> >> >> On Tue, Aug 4, 2020 at 1:49 AM Chris Vavaliaris >> wrote: >> >>> PR #16999: https://github.com/numpy/numpy/pull/16999 >>> >>> Hello all, >>> this PR adds the two 1D

Re: [Numpy-discussion] Augment unique method

should be a separate change from np.unique(). You can certainly do this currently in NumPy but it's a bit of work: https://stackoverflow.com/questions/18915378/rounding-to-significant-figures-in-numpy > > > *From:* NumPy-Discussion gmail....@python.org> *On Behalf Of *Stephan Hoyer &g

Re: [Numpy-discussion] Augment unique method

On Thu, Jul 16, 2020 at 11:41 AM Roman Yurchak wrote: > One issue with adding a tolerance to np.unique for floats is say you have > [0, 0.1, 0.2, 0.3, 0.4, 0.5] with atol=0.15 > > Should this return a single element or multiple ones? One once side each > consecutive float is closer than the

Re: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy

On Wed, Jul 1, 2020 at 12:23 PM Sebastian Berg wrote: > This is a WIP, but allows nicely to try out how the new API > could/should look like, and see the potential impact to code. The > current choice is for: > > np.sort(arr, keys=(arr.real, arr.image)) > > for example. `keys` is like the

Re: [Numpy-discussion] divmod(1.0, 0.0) bug

On Fri, May 8, 2020 at 4:10 PM Brock Mendel wrote: > FWIW in pandas we post-process floordiv (and divmod) ops to get the > "Expected Result" behavior from the OP. > > > On Fri, May 8, 2020 at 11:56 AM Anirudh Subramanian > wrote: > >> Hi all, >> >> There has been a discussion about divmod (1.0,

Re: [Numpy-discussion] Deprecate Promotion of numbers to strings?

On Thu, Apr 30, 2020 at 10:32 AM Sebastian Berg wrote: > Hi all, > > in https://github.com/numpy/numpy/pull/15925 I propose to deprecate > promotion of strings and numbers. I have to double check whether this > has a large effect on pandas, but it currently seems to me that it will > be

Re: [Numpy-discussion] Proposal: add `force=` or `copy=` kwarg to `__array__` interface

On Sat, Apr 25, 2020 at 10:40 AM Ralf Gommers wrote: > > > On Fri, Apr 24, 2020 at 12:35 PM Eric Wieser > wrote: > >> Perhaps worth mentioning that we've discussed this sort of API before, in >> https://github.com/numpy/numpy/pull/11897. >> >> Under that proposal, the api would be something

Re: [Numpy-discussion] Feelings about type aliases in NumPy

On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg wrote: > On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote: > > On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote: > > > But, Stephan pointed out that it might be confusing to users for > > > objects to only exist at typing time, so we

Re: [Numpy-discussion] Proposal: add `force=` or `copy=` kwarg to `__array__` interface

On Fri, Apr 24, 2020 at 6:31 AM Sebastian Berg wrote: > One thing to note is that `__array__` is actually asked to return a > copy AFAIK. The documentation on __array__ seems to quite limited, unfortunately. The most I can find are a few sentences here:

[Numpy-discussion] Put type annotations in NumPy proper?

When we started numpy-stubs [1] a few years ago, putting type annotations in NumPy itself seemed premature. We still supported Python 2, which meant that we would need to use awkward comments for type annotations. Over the past few years, using type annotations has become increasingly popular,

Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

On Sun, Feb 23, 2020 at 3:59 PM Ralf Gommers wrote: > > > On Sun, Feb 23, 2020 at 3:31 PM Stephan Hoyer wrote: > >> On Thu, Feb 6, 2020 at 12:20 PM Sebastian Berg < >> sebast...@sipsolutions.net> wrote: >> >>> >>> Another thing about backwar

Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

On Thu, Feb 6, 2020 at 12:20 PM Sebastian Berg wrote: > > It is less clear how this could work for __array_module__, because > > __array_module__ and get_array_module() are not generic -- they > > refers explicitly to a NumPy like module. If we want to extend it to > > SciPy (for which I agree

Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

ath. > > > Anyway, NEP 37 seems a great step in the right direction and would enable > sklearn to actually dispatch in some places. Dispatching just based on > __array_function__ seems not really feasible so far. > > Best, > Andreas Mueller > > > On 1/6/20 11:29 P

[Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

t, Stephan Hoyer === NEP 37 — A dispatch protocol for NumPy-like modules === :Author: Stephan Hoyer :Author: Hameer Abbasi :Author: Sebastian Berg :Status: Draft :Type: Standards Track :Created:

Re: [Numpy-discussion] Adding keepdims to linspace / logspace / geomspace

I'm not sure I understand the motivation here. Is the idea that you want to reuse min/max values computed with keepdims that you also want to use for other purposes? If so, this could be achieved with squeeze(), e.g., np.linspace( arr.min(axis=ax, keepdims=True).squeeze(ax),

Re: [Numpy-discussion] [API] (minor change) Allow multiple axes in `expand_dims`

This looks good to me! On Mon, Dec 2, 2019 at 11:13 AM Sebastian Berg wrote: > Hi all, > > Pull request 14051: > > https://github.com/numpy/numpy/pull/14051 > > means that `np.expand_dims` now accepts multiple axes in the `axis` > argument. As before, the axis signal where a new axis is in the

Re: [Numpy-discussion] Cleanup of travisCI tests.

We still support explicitly opting-out of __array_function__, so I think we should still keep that test configuration. On Fri, Nov 15, 2019 at 1:50 PM Charles R Harris wrote: > Hi All, > > I think there are some travisCI tests that we can eliminate, see tests >

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev wrote: > What would be the use case for a duck-array to implement __array__ and > return a NumPy array? Unless I'm missing something, this seems > redundant and one should just use array/asarray functions then. This > would also prevent

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

On Wed, Sep 11, 2019 at 4:18 PM Ralf Gommers wrote: > > > On Tue, Sep 10, 2019 at 10:59 AM Stephan Hoyer wrote: > >> On Tue, Sep 10, 2019 at 6:06 AM Hameer Abbasi >> wrote: >> >>> On 10.09.19 05:32, Stephan Hoyer wrote: >>> >>> On Mon, S

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

On Tue, Sep 10, 2019 at 6:06 AM Hameer Abbasi wrote: > On 10.09.19 05:32, Stephan Hoyer wrote: > > On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers > wrote: > >> I think we've chosen to try the former - dispatch on functions so we can >> reuse the NumPy API. It could w

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

On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers wrote: > I think we've chosen to try the former - dispatch on functions so we can > reuse the NumPy API. It could work out well, it could give some long-term > maintenance issues, time will tell. The question is now if and how to plug > the gap that

Re: [Numpy-discussion] ENH: Add Moving Average Function

I would be very interested to see the “sliding window view” function merged into np.lib.stride_tricks. I don’t think it makes sense to add a suite of dedicated functions for sliding window calculations that wrap that function. If we are going to go down the path of adding sliding window

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris wrote: > > > On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer wrote: > >> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers >> wrote: >> >>> >>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote: >

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers wrote: > > On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote: > >> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers >> wrote: >> >> >>> The NEP currently does not say who this is meant for. Would yo

Re: [Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation

On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers wrote: > Having __array__ give a TypeError is fine for libraries that want to > prevent unintentional coercion with, e.g., `np.asarray(my_ducktype)`. > However that leaves the obvious question of what the right way is to do > this intentionally. Would

Re: [Numpy-discussion] __array_function related regression for 1.17.0rc1

On Tue, Jul 2, 2019 at 8:16 AM Ralf Gommers wrote: > > > On Tue, Jul 2, 2019 at 1:45 AM Juan Nunez-Iglesias > wrote: > >> On Tue, 2 Jul 2019, at 4:34 PM, Stephan Hoyer wrote: >> >> This is addressed in the NEP, see bullet 1 under "Partial impleme

Re: [Numpy-discussion] __array_function related regression for 1.17.0rc1

On Tue, Jul 2, 2019 at 1:46 AM Juan Nunez-Iglesias wrote: > I'm also wondering where the list of functions that must be implemented > can be found, so that libraries like dask and CuPy can be sure that they > have a complete implementation, and further typeerrors won't be raised with > their

Re: [Numpy-discussion] __array_function related regression for 1.17.0rc1

> > Your suggestion on the issue to switch from typeerror to warning is, imho, >> much better, as long as the warning contains a link to an issue/webpage >> explaining what needs to happen. It's only because I've been vaguely aware >> of the `__array_function__` discussions that I was able to

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Tue, Jun 25, 2019 at 10:14 AM Todd wrote: > On Tue, Jun 25, 2019 at 11:47 AM Alan Isaac wrote: > >> On 6/25/2019 11:03 AM, Todd wrote: >> > Fair enough. But although there are valid reasons to do a divide by >> zero, it still causes a warning because it is a problem often enough that >>

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Tue, Jun 25, 2019 at 7:20 AM Todd wrote: > On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias > wrote: > >> On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote: >> >> Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape >> of `(n, 1)` the right behaviour? I.e.,

Re: [Numpy-discussion] new MaskedArray class

On Mon, Jun 24, 2019 at 5:36 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > > > On Mon, Jun 24, 2019 at 7:21 PM Stephan Hoyer wrote: > >> On Mon, Jun 24, 2019 at 3:56 PM Allan Haldane >> wrote: >> >>> I'm not at all set on that behavior

Re: [Numpy-discussion] new MaskedArray class

On Mon, Jun 24, 2019 at 3:56 PM Allan Haldane wrote: > I'm not at all set on that behavior and we can do something else. For > now, I chose this way since it seemed to best match the "IGNORE" mask > behavior. > > The behavior you described further above where the output row/col would > be masked

Re: [Numpy-discussion] new MaskedArray class

On Mon, Jun 24, 2019 at 8:46 AM Allan Haldane wrote: > 1. Making a "no-clobber" guarantee on the underlying data > Hi Allan -- could kindly clarify what you mean by "no-clobber"? Is this referring to allowing masked arrays to mutate masked data values in-place, even on apparently non-in-place

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Mon, Jun 24, 2019 at 8:10 AM Todd wrote: > On Mon, Jun 24, 2019 at 11:00 AM Stephan Hoyer wrote: > >> On Sun, Jun 23, 2019 at 10:05 PM Stewart Clelland < >> stewartclell...@gmail.com> wrote: >> >>> Hi All, >>> >>> Based on discussion

Re: [Numpy-discussion] new MaskedArray class

On Sun, Jun 23, 2019 at 11:55 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Your proposal would be something like np.sum(array, >> where=np.ones_like(array))? This seems rather verbose for a common >> operation. Perhaps np.sum(array, where=True) would work, making use of >>

Re: [Numpy-discussion] new MaskedArray class

On Sun, Jun 23, 2019 at 4:07 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > - If reductions/aggregations default to skipping missing elements, how is >> it be possible to express "NA propagating" versions, which are also useful, >> if slightly less common? >> > > I have been playing

Re: [Numpy-discussion] new MaskedArray class

On Sat, Jun 22, 2019 at 6:50 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi Allan, > > I'm not sure I would go too much by what the old MaskedArray class did. It > indeed made an effort not to overwrite masked values with a new result, > even to the extend of copying back masked

Re: [Numpy-discussion] new MaskedArray class

On Thu, Jun 20, 2019 at 7:44 PM Allan Haldane wrote: > On 6/19/19 10:19 PM, Marten van Kerkwijk wrote: > > Hi Allan, > > > > This is very impressive! I could get the tests that I wrote for my class > > pass with yours using Quantity with what I would consider very minimal > > changes. I only

Re: [Numpy-discussion] Extent to which to work around matrix and other duck/subclass limitations

On Thu, Jun 13, 2019 at 9:35 AM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi Ralf, others, > > >>> Anyway, I guess this is still a good example to consider for how we >>> should go about getting to a new implementation, ideally with just a >>> single-way to override? >>> >>>

Re: [Numpy-discussion] Extent to which to work around matrix and other duck/subclass limitations

On Wed, Jun 12, 2019 at 5:55 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi Ralf, > > You're right, the problem is with the added keyword argument (which would > appear also if we did not still have to support the old .sum method > override but just dispatched to __array_ufunc__

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

On Wed, Jun 5, 2019 at 1:43 PM Sebastian Berg wrote: > Hi all, > > TL;DR: > > Value based promotion seems complex both for users and ufunc- > dispatching/promotion logic. Is there any way we can move forward here, > and if we do, could we just risk some possible (maybe not-existing) > corner

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

On Sun, Jun 2, 2019 at 1:08 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > > > On Sun, Jun 2, 2019 at 2:21 PM Eric Wieser > wrote: > >> Some of your categories here sound like they might be suitable for ABCs >> that provide mixin methods, which is something I think Hameer suggested

Re: [Numpy-discussion] __skip_array_function__ discussion summary

Sebastian, Stefan and Marten -- thanks for the excellent summaries of the discussion. In line with this consensus, I have drafted a revision of the NEP without __skip_array_function__: https://github.com/numpy/numpy/pull/13624 On Thu, May 23, 2019 at 5:28 PM Marten van Kerkwijk <

Re: [Numpy-discussion] Keep __array_function__ unexposed by default for 1.17?

On Thu, May 23, 2019 at 2:43 AM Ralf Gommers wrote: > > > On Thu, May 23, 2019 at 3:02 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> >> If we want to keep an "off" switch we might want to add some sort of API >>> for exposing whether NumPy is using __array_function__ or not.

Re: [Numpy-discussion] Converting np.sinc into a ufunc

On Wed, May 22, 2019 at 2:00 PM Ralf Gommers wrote: > > > On Wed, May 22, 2019 at 7:34 PM Nathan Goldbaum > wrote: > >> It might be worth using BigQuery to search the github repository public >> dataset for usages of np.sinc with keyword arguments. >> > > We spent some effort at Quansight to

Re: [Numpy-discussion] Keep __array_function__ unexposed by default for 1.17?

On Wed, May 22, 2019 at 2:36 PM Ralf Gommers wrote: > I would still like to turn on __array_function__ in NumPy 1.17. At least, >>> let's try that for the release candidate and see how it goes. >>> >> > I agree. I'd actually suggest flipping the switch asap and see if it > causes any issues for

Re: [Numpy-discussion] Keep __array_function__ unexposed by default for 1.17?

Thanks for raising these concerns. The full implications of my recent __skip_array_function__ proposal are only now becoming evident to me now, looking at it's use in GH-13585. Guaranteeing that it does not expand NumPy's API surface seems hard to achieve without pervasive use of

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

On Sat, May 4, 2019 at 12:29 PM Ralf Gommers wrote: > We seem to have run out of steam a bit here. > We discussed this today in person at the NumPy sprint. The consensus was to go for a name like __skip_array_function__. Ufuncs don't have very good use-cases for a function that skips dispatch:

  1   2   3   >