[Numpy-discussion] Re: Applying a function on local environments

On Sat, 27 Jul 2024, at 12:02 AM, Robert Kern wrote: > scipy.ndimage.generic_filter() > See also my post on accelerating generic filters with numba: https://ilovesymposia.com/2017/03/15/prettier-lowlevelcalla

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

On Tue, 7 May 2024, at 7:04 AM, Ralf Gommers wrote: > This problem could have been avoided by proper use of upper bounds. > Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug in > scikit-image (definitely for ABI reasons, and arguably also for API reasons). > It would really be u

[Numpy-discussion] Re: Function that searches arrays for the first element that satisfies a condition

ctions. > > This is only recommended for sourcing functions that are not called > frequently, but rather have a large computational content within them. In > other words not suitable for predicates. > > Regards, > DG > >> On 1 Nov 2023, at 01:05, Juan Nunez-Iglesias wrot

[Numpy-discussion] Re: Function that searches arrays for the first element that satisfies a condition

If you add a layer of indirection with Numba you can get a *very* nice API: @numba.njit def _first(arr, pred): for i, elem in enumerate(arr): if pred(elem): return i def first(arr, pred): _pred = numba.njit(pred) return _first(arr, _pred) This even works with lamb

[Numpy-discussion] Re: Change in numpy.percentile

On Mon, 9 Oct 2023, at 7:07 PM, Andrew Nelson wrote: > On Mon, 9 Oct 2023 at 16:36, Jerome Kieffer wrote: > I'd be ambivalent on making this change. THere are a whole host of other > `np.nan*` functions, would they all need to be modified as well? e.g. > nanprod, nansum, nanargmin, .. I th

[Numpy-discussion] Re: Add to NumPy a function to compute cumulative sums from 0.

I'm very sensitive to the issues of adding to the already bloated numpy API, but I would definitely find use in this function. I literally made this error (thinking that the first element of cumsum should be 0) just a couple of days ago! What are the plans for the "extended" NumPy API after 2.0?

[Numpy-discussion] Re: Precision changes to sin/cos in the next release?

On Wed, 31 May 2023, at 4:11 PM, Juan Nunez-Iglesias wrote: > For me it is indeed too surprising, and I would be in favour of reverting. (👆 Incidentally I wrote that before seeing https://github.com/scikit-image/scikit-image/pull/6970 😂) > On Wed, 31 May 2023, at 3:55 PM, Sebastian Berg

[Numpy-discussion] Re: Precision changes to sin/cos in the next release?

For me it is indeed too surprising, and I would be in favour of reverting. On Wed, 31 May 2023, at 3:55 PM, Sebastian Berg wrote: > Hi all, > > there was recently a PR to NumPy to improve the performance of sin/cos > on most platforms (on my laptop it seems to be about 5x on simple > inputs). > Th

[Numpy-discussion] Re: Categorical dtypes

Thanks for the response, Sebastian! I'll keep an eye out on that repo. Should there be (is there already) a link to it from the docs? On Tue, 30 May 2023, at 6:21 PM, Sebastian Berg wrote: > On Mon, 2023-05-29 at 10:55 +1000, Juan Nunez-Iglesias wrote: >> Hi folks, >> >

[Numpy-discussion] Categorical dtypes

Hi folks, Apologies if this is documented somewhere, but I haven't been able to find it. I've read through NEP-42 [1] and skimmed NEP-41 [2], but I'm not sure: (a) at what point of implementation we are, and (b) if it's pretty much done, *how* to define a custom categorical dtype. In my use cas

[Numpy-discussion] Re: Software Freedom Conservancy calls for move from Github

Thanks Matthew! I will say one thing, I agree that there are major costs, but the longer I work in this space the more I appreciate the benefits there might be to *not* being on GitHub. I recently (finally) read Nadia Eghbal's Working in Public, where she points out that *adding* friction to th

[Numpy-discussion] Re: NEP 50: Promotion rules for Python scalars

> For example, in NumPy: > >np.median(np.float32([1, 2, 3, 4])) > > did return a float64 before and will now return a float32. I assume > because somewhere we write: `(np.float64(3) + np.float32(2)) / 2`. Sorry, I missed this part of the discussion — I know the discussion centered around P

[Numpy-discussion] Re: Automatic formatters for only changed lines

On Sun, 8 May 2022, at 7:11 AM, Sebastian Berg wrote: > To be fair to black, the main issue there is the trailing `,` which > forces items to be formatted on a line each (yapf does the same). > If you remove the trailing comma, you will get close to what you want > also in black: > > custom

[Numpy-discussion] Re: Automatic formatters for only changed lines

With the caveat that I am just an interested bystander, I would like to point back to yapf as an alternative. I agree with what has already been echoed by the majority of the community, that setting *some* auto-formatter is a huge benefit for both review and writing sanity. I very much disagree

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

> * e.g. the same user might initially be happy about the result of x[0] + 1 > matching their infinite-precision expectation, but then be surprised by > > x[0] + 1 > -> 256 > > y[0] = 1 > x[0] + y[0] > -> 0 # WTH I'll go even further: I would say a common situation where people use syntax lik

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

On Tue, 22 Feb 2022, at 1:01 AM, Stefan van der Walt wrote: > it is easier to explain away `x + 1` behaving oddly over `x[0] + 1` behaving > oddly Is it? I find the two equivalent, honestly. > given that we pretend like NumPy scalars do not exist. This is the leaky abstraction that I think sho

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

On Mon, 21 Feb 2022, at 11:50 PM, Stefan van der Walt wrote: > Just to play a bit of devil's advocate here, I'd have to say that most people > will not expect > > x[0] + 200 > > To often yield a number less than 200! It's tricky though, because I would expect np.uint8(255) + 1 to be equal to

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

> the > latter would seem consistent with the "principle of least surprise" when > moving from a typed language to > NumPy work perhaps, though arguably slightly less user-friendly if naively > doing some operations with > a less formal view of typing (new Python user messing around with NumPy?)

[Numpy-discussion] Re: An article on numpy data types

I'm surprised no one has mentioned it already: int and uint are reversed in the first table. I do agree with others that this is a great overview page that should be included in the numpy docs. Thanks Lev! Juan. On Sun, 26 Dec 2021, at 12:59 PM, Lev Maximov wrote: > I've tried to take into acc

[Numpy-discussion] Re: Allow for callable in indexing

I have to say I like this! Together with partial functions / toolz currying [1] it could make for some rather elegant code: result = gaussian_filter(image)[greater_than(t)] Juan. ..[1]: https://toolz.readthedocs.io/en/latest/curry.html On Wed, 24 Nov 2021, at 9:37 AM, cameron.pinne...@gmail.co

[Numpy-discussion] Re: Code formatters

> On 15 Nov 2021, at 8:23 am, Stefan van der Walt wrote: > > On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote: >> The black formatter is much improved in its latest version and I think good >> enough to start using. The main drawbacks that I see are: >> all operators, including '*' and '

[Numpy-discussion] Re: Revert the return of a single NaN for `np.unique` with floating point numbers?

I agree with the argument to revert. Consistency among libraries should be near the top of the list of priorities, as should performance. Whether the new behaviour "makes more sense", meanwhile, is debatable. On Fri, 5 Nov 2021, at 4:08 PM, Ralf Gommers wrote: > > > On Mon, Aug 2, 2021 at 7:49

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

The upside of discourse, though, is that those messages can be permanently deleted by moderators. In contrast, the mailing list archives appear unalterable... At any rate, those two messages (assuming we're talking about the same ones) don't appear to be spam, but rather a misunderstanding of t

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

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 subscription, and immediately receive resulting spam. A "reputation" sys

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

Personally I was a fan of the Enum approach. People dislike it because it is not “Pythonic”, but imho that is an accident of history because Enums only appeared (iirc) in Python 3.4. In fact, they are the right data structure for this particular problem, so for my money we should *make it* Pytho

Re: [Numpy-discussion] Tensor Typing presentation and discussion on Wednesday! (As part of the NumPy Community Meeting)

presentation > Tensor typing meeting details > <https://docs.google.com/document/d/1oaG0V2ZE5BRDjd9N-Tr1N0IKGwZQcraIlZ0N8ayqVg8/edit> > Thanks again, everyone! > > On Wed, 9 Jun 2021 at 22:28, Sebastian Berg <mailto:sebast...@sipsolutions.net>> wrote: > On Tue

Re: [Numpy-discussion] Tensor Typing presentation and discussion on Wednesday! (As part of the NumPy Community Meeting)

Hello! Any chance this could be recorded for those of us in useless time zones? 😂 On Mon, 7 Jun 2021, at 6:03 PM, Sebastian Berg wrote: > Hi all, > > There will be a NumPy Community meeting Wednesday June 9th at > 20:00 UTC. > > This meeting will be dedicated to a presentation by Matthew and P

Re: [Numpy-discussion] Looking for a difference between Numpy 0.19.5 and 0.20 explaining a perf regression with Pythran

Hi Pierre, If you’re able to compile NumPy locally and you have reliable benchmarks, you can write a script that tests the runtime of your benchmark and reports it as a test pass/fail. You can then use “git bisect run” to automatically find the commit that caused the issue. That will help narro

Re: [Numpy-discussion] NumPy logo merchandise

Yeah I desperately want those mitts! > On 5 Mar 2021,

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

y have existed). > > I would love to see examples of this -- perhaps in matplotlib? > > My thinking is that in most cases it's probably a better idea to keep the > interface simpler, and raise an error for lower-dimensional arrays. Automatic > conversion is conven

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

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 idea where the new axes would end up. So, I’m in favour of includi

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

> On 13 Dec 2020, at 6:25 am, Sebastian Berg wrote: > > But "default" in NumPy really doesn't mean a whole lot? I can think of > three places where "defaults" exists: Huh? There are platform-specific defaults for literally every array creation function in NumPy? In [1]: np.array([4, 9]).dty

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

> I agree. I think we should recommend sane, descriptive names that do the > right thing. So ideally we'd have people spell their dtype specifiers as > dtype=bool # or np.bool > dtype=np.float64 > dtype=np.int64 > dtype=np.complex128 > The names with underscores at the end make little se

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

Hi all, At the prodding [1] of Sebastian, I’m starting a discussion on the decision to deprecate np.{bool,float,int}. This deprecation broke our prerelease testing in scikit-image (which, hooray for rcs!), and resulted in a large amount of code churn to fix [2]. To be honest, I do think *some*

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

I like Ralf's email, and most of all I agree that the existing wording is clearer. My view on the NEP is that it does not mandate dropping support, but encourage it. In my projects I would drop it if I had use for Python 3.7+ features. It so happens that we want to use PEP-593 so we were gratef

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

Looks gorgeous, thank you to all who worked on the implementation, API, and review, and thank you Sebastian for saving me a click! 😂 > On 13 Oct 2020, at 2:25 am, Sebastian Berg wrote: > > On Mon, 2020-10-12 at 08:39 +, Zimmermann Klaus wrote: >> Hello, >> >> I would like to draw the atten

[Numpy-discussion] Sprint leaders wanted for SciPy Japan

Hi NumPythonistas, and apologies cross-posting. I am sprints chair for the upcoming SciPy Japan virtual conference [1]. It’s running Oct 30-31 (main conference) and Nov 1-2 (sprints). This is the second SciPy Japan conference and the first with sprints. The sprints officially run from 9am to 5p

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

9-October/080176.html> > > [6] https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst > <https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst> > [7] > https://github.com/numpy/numpy/blob/master/doc/neps/nep-0038-SIMD-optimizations.rst &

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

I’ve generally been on the “let the NumPy devs worry about it” side of things, but I do agree with Ilhan that `like=` is confusing and `typeof=` would be a much more appropriate name for that parameter. I do think library writers are NumPy users and so I wouldn’t really make that distinction, t

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20

and would be happy to set up one on the topic of Python for Climate Action. > We could host it on July 8th or 10th at 5 - 6 p.m. CDT. Would you be > available to moderate it? > > > -- Forwarded message -- > From: Juan Nunez-Iglesias mailto:j...@fastmail

Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies

Hi everyone, If you live in Australia, this has been a rough year to think about climate change. After the hottest and driest year on record, over 20% of the forest surface area of the south east was burned in the bushfires. Although I was hundreds of kilometres from the nearest fire, the air q

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

Hi everyone, and thank you Ralf for carrying the flag in my absence. =D Sebastian, the *primary* motivation behind avoiding detach() in PyTorch is listed in original post of the PyTorch issue: > People not very familiar with `requires_grad` and cpu/gpu Tensors might go > back and forth with num

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

Hi everyone, > One bit of expressivity we would miss is “copy if necessary, but otherwise > don’t bother”, but there are workarounds to this. After a side discussion with Stéfan van der Walt, we came up with `allow_copy=True`, which would express to the downstream library that we don’t mind wa

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

Hello NumPy-ers! The __array__ method is a great little tool to allow interoperability with NumPy. Briefly, calling `np.array()` or `np.asarray()` on an object with an `__array__` method, one can get a NumPy representation of that object, which may or may not involve data copying (this is up to

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

I'd like to offer a +1 from skimage's perspective (and napari's!) for having NumPy types directly in the repo. We have been wanting to start using type annotations, but the lack of types in NumPy proper, together with the uncertainty about whether numpy-stubs was "officially supported" and in-sy

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

I personally have always found it weird and annoying to deal with 0-D arrays, so +1 for scalars!* Juan *: admittedly, I have almost no grasp of the underlying NumPy implementation complexities, but I will happily take Sebastian's word that scalars can be consistent with the library. On Fri, 2

Re: [Numpy-discussion] "Proposal to accept NEP 34: Disallow inferring dtype=object from sequence

For what it’s worth, I support this NEP. I have indeed seen this mistake often when teaching NumPy. > On 17 Nov 2019, at 8:43 am, Matti Picus wrote: > > I propose to move the NEP https://numpy.org/neps/nep-0034.html from "draft" > to "accepted" status. There were no objections (actually ther

Re: [Numpy-discussion] Recommended way to utilize GPUs via OpenCL, ROCm

I have also used PyOpenCL quite profitably: https://github.com/inducer/pyopencl I philosophically prefer it to ROCm because it targets *all* GPUs, including intel integrated graphics on most laptops, which can actually get quite decent (30x) speedups. > On

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

Hi all, and thank you for all your hard work with this. I wanted to provide more of an "end user" perspective than I think has been present in this discussion so far. Over the past month, I've quickly skimmed some emails on this thread and skipped others altogether. I am far from a NumPy novic

Re: [Numpy-discussion] Accepting NEP 29 — Recommend Python and Numpy version support as a community policy standard

We're behind this at scikit-image! Thank you to all who worked on this proposal! Minor typo: "at minimum the last THREE minor versions" Juan. On Thu, 3 Oct 2019, at 4:54 PM, Sebastian Berg wrote: > Hi all, > > we propose formally accepting the NumPy enhancement proposal 29: > > "Recommend Pyth

Re: [Numpy-discussion] Code review for adding axis argument to permutation and shuffle function

I don’t understand why the proposal would be controversial in any way. It’s very natural to have `axis=` keyword arguments in NumPy, and it’s the lack of them that is surprising. My only additional suggestion would be to allow tuples of axes, but that can come later. Juan. > On 13 Sep 2019, at

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

I’m confused about why it needs write access to code... if I were doing this for scikit-image I would possibly clone the code to a new repo. > On 29 Aug 2019, at 8:03 am, Matti Picus wrote: > > In PR 14378 https://github.com/numpy/numpy/pull/14378 I moved all our python > test dependencies to

Re: [Numpy-discussion] did anyone create numpy.slack.com?

FWIW we use Zulip for scikit-image and we are very happy with it. See https://skimage.zulipchat.com . Advantages over Slack: - free for FOSS, including unlimited archives (https://zulipchat.com/for/open-source/ ) - login

Re: [Numpy-discussion] Creating a sine wave with exponential decay

Hi Francesc, Those numbers are really eye-popping! But the formatting of the code as a string still bugs me a lot. Asking this as a totally naive user, do you know whether PEP523 (adding a frame evaluation API) would allow numexpr to have a more Pytho

Re: [Numpy-discussion] converting 1 dimensional array to 2 dimensional array

Hi Omry! You're looking for `.view()`: In [1]: import numpy as np In [2]: b = np.arange(1, 13).astype(np.uint8) In [4]: y = b.view(np.uint16).reshape((3, 2)) In [5]: y Out[5]: array([[ 513, 1027], [1541, 2055], [2569, 3083]], dtype=uint16) You can also change the endianness by replacing `np.

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

On Tue, 2 Jul 2019, at 4:34 PM, Stephan Hoyer wrote: > This is addressed in the NEP, see bullet 1 under "Partial implementation of > NumPy's API": > http://www.numpy.org/neps/nep-0018-array-function-protocol.html#partial-implementation-of-numpy-s-api > > My concern is that fallback coercion behav

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

On Mon, 1 Jul 2019, at 2:34 PM, Ralf Gommers wrote: > This issue is not very surprising - __array_function__ is going to have a > fair bit of backwards compat impact for people who were relying on feeding > all sorts of stuff into numpy functions that previously got converted with > asarray. A

Re: [Numpy-discussion] NumPy 1.17.0rc1 released

Hi Chuck, and thanks for putting this together! It seems the release has broken existing uses of dask array with `np.min` (I presume among other functions): https://github.com/dask/dask/issues/5031 Perhaps `__array_function__` should be switched off for one more release cycle? I imagine that s

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

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., it should still change from what it is > now - which is to leave the shape at `(n,)`. Just to chime in as a user: v.T

Re: [Numpy-discussion] Was the range() function ever created?

On Sat, 25 May 2019, at 1:49 PM, C W wrote: > I can't be the first person who asked about range() that calculates the > *actual* range of two numbers. Based on your mention of matlab's `range`, I think you're looking for numpy.ptp. https://docs.scipy.org/doc/numpy/reference/generated/numpy.ptp

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

I just want to express my general support for Marten's concerns. As an "interested observer", I've been meaning to give `__array_function__` a try but haven't had the chance yet. So from my anecdotal experience I expect that more people need to play with this before setting the API in stone. At

Re: [Numpy-discussion] [SciPy-User] Why slicing Pandas column and then subtract gives NaN?

> I don’t have index when I read in the data. I just want to slice two series > to the same length, and subtract. That’s it! > > I also don’t what numpy methods wrapped within methods. They work, but hard > do understand. > > How would you do it? In Matlab or R, it’s very simple, one line. Wh

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

> On 10 Jan 2019, at 6:35 pm, Todd wrote: > > Could this approach be used to deprecate `ravel` and let us just use > `flatten`? Could we not? `.ravel()` is everywhere and it matches `ravel_multi_index` and `unravel_index`.___ NumPy-Discussion mail

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Fri, Dec 28, 2018, at 10:58 AM, Ralf Gommers wrote: > > Technically there's nothing we are deprecating. If anything, the one not > super uncommon pattern will be that people use 0/1 instead of False/True, > which works as expected now and will start raising in case we'd go with > np.never_co

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Fri, Dec 28, 2018, at 3:40 AM, Sebastian Berg wrote: > > It’s consistent with np.newaxis in spelling (modulo the _) > > If mistyped, it can be caught easily by IDEs. > > It’s typeable with mypy, unlike constant string literals which > > currently aren’t > > If code written against new numpy is r

Re: [Numpy-discussion] Warn or immidiately change readonly flag on broadcast_arrays return value?

Probably this will cause a lot of groans, but I've definitely written code modifying `broadcast_to` outputs, intentionally. As such I am -1 on this whole endeavour. My preference on making arrays read-only is to have a very light touch if any. As an example, at some point `np.diag` started retur

Re: [Numpy-discussion] Adding "maximum difference" to np.testing.assert_array_equal errors

Another +1 on printing rtol, and +100 (can I do that?) on the overall idea! Thanks Stephan! On Thu, Dec 20, 2018, at 7:27 AM, Christoph Deil wrote: > > > > On 19. Dec 2018, at 19:50, Stefan van der Walt wrote: > > > > On Wed, 19 Dec 2018 09:47:01 -0800, Stephan Hoyer wrote: > >> Example behav

Re: [Numpy-discussion] PR Cleanup

> On 26 Sep 2018, at 5:12 am, Ralf Gommers wrote: > My $2c: I've had this "bot experience" happen to me once (for a pip > contribution), and that left a *really* bad taste. I’m going to second Ralf’s comments here. These bots are a great idea if your number one goal is to reduce the number of

Re: [Numpy-discussion] count_nonzero axis argument?

On Mon, Sep 17, 2018, at 9:37 PM, Matthew Brett wrote: > >>> np.better_count_nonzero([[10, 11], [0, 3]], axis=1) > array([2, 1]) > > It would be much more useful if it did... You might know about this already, but I not too long ago discovered np.apply_along_axis [1], which is a magical function

Re: [Numpy-discussion] pytest, fixture and parametrize

> I find the way that pytest automatically match *argument names* with > the names of fixtures very distasteful and un-Pythonic. THIS! I've been wanting to articulate this for a while but couldn't quite put my finger on it. Nevertheless, I agree with the sentiment in this thread, specifically that,

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

Let me start by thanking Robert for articulating my viewpoints far better than I could have done myself. I want to explicitly flag the following statements for endorsement: > *I would still reserve warnings and deprecation for the cases where > the current behavior gives us something that no one wa

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

> Plain indexing arr[...] should return an error for ambiguous cases. > [...] This includes every use of vectorized indexing with multiple > integer arrays. This line concerns me. In scikit-image, we often do: rr, cc = coords.T # coords is an (n, 2) array of integer coordinates values = image[rr,

Re: [Numpy-discussion] Python 3 compatible examples

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

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

On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote: > Marten's case 1: works exactly like ndarray, but stores data > differently: parallel arrays (e.g., dask.array), sparse arrays (e.g., > https://github.com/pydata/sparse), hypothetical non-strided arrays > (e.g., always C ordered). Two other "hy

Re: [Numpy-discussion] Applying logical operations along an axis of a boolean array?

Use “np.all” or “np.any”. On 18 Dec 2017, 10:02 PM +1100, hanno_li...@gmx.net, wrote: > Hi, > > is it possible, to apply a logical operation, such as AND or OR along a > particular axis of a numpy array? > > Let's say I have an (n,m) array and I want to AND along the first axis, such > that I ge

Re: [Numpy-discussion] How to subset a matrix according to some criterion?

selector = target != 2 data, target = data[selector], target[selector] On 4 Dec 2017, 8:38 AM +1100, Peng Yu , wrote: > Hi, I'd like to select the rows of 'data' for which the corresponding > elements in 'target' is not 2. Could anybody let know what is the best > way (with the least code) to do c

Re: [Numpy-discussion] Type annotations for NumPy

On 26 Nov 2017, 12:27 PM +1100, Nathaniel Smith , wrote: > It turns out that the PEP 484 type system is *mostly* not useful for > this. They're really designed for checking consistency across a large > code-base, not for enabling compiler speedups. For example, if you > annotate something as an in

Re: [Numpy-discussion] Type annotations for NumPy

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. (b) I’ve always thought (since PEP561) that it would be cool for type annotations to replace compiler type annotations for e.g. Cython a

Re: [Numpy-discussion] Vectorization of variant of piecewise or interpolation function

Hi Seth, The function you’re looking for is `np.digitize`: In [1]: t = np.array([0.5,1,1.5,2.5,3,10])    ...: table = np.array([[0,3],[1,0],[2,5],[3,-1]])    ...: In [2]: lookup, values = table[:, 0], table[:, 1:] In [3]: values = np.concatenate((values[0:1], values), axis=0) In [4]: indices = n

Re: [Numpy-discussion] Only integer scalar arrays can be converted to a scalar index

@Robert, good point, always good to try out code before speculating on a thread. ;) Here’s working code to do the averaging, though it’s not block-wise, you’ll have to add that on top with dask/util.apply_parallel. Note also that because of the C-order of numpy arrays, it’s much more efficient

Re: [Numpy-discussion] Only integer scalar arrays can be converted to a scalar index

+1 on the astype(int) call. +1 also on using dask. scikit-image has a couple of functions that might be useful: - skimage.util.apply_parallel: applies a function to an input array in chunks, with user-selectable chunk size and margins. This is powered by dask. - skimage.util.view_as_windows: us

Re: [Numpy-discussion] quantile() or percentile()

I concur with the consensus. On 10 Aug 2017, 11:10 PM +0200, Eric Wieser , wrote: > Let’s try and keep this on topic - most replies to this message has been > about #9211, which is an orthogonal issue. > There are two main questions here: > > 1. Would the community prefer to use np.quantile(x, 0

Re: [Numpy-discussion] ENH: Proposal to add np.neighborwise in PR#9514

It’s nice that this is pure Python / NumPy vectorized, whereas generic_filter requires some compilation to get good performance. (Tim, although your implementation is nice and readable, it would have been very slow for any significant volumes.) However, my feeling is that this function is too s

Re: [Numpy-discussion] Making a 1.13.2 release

Just chiming in with a +1 to releasing 1.13.1 before SciPy. It will certainly save the skimage tutorial a lot of headaches! Not that I’ll be there but I look out for my own. =P On 7 Jul 2017, 3:54 AM +1000, Nathaniel Smith , wrote: > It's also possible to work around the 3.6.1 problem with a sma

Re: [Numpy-discussion] Vector stacks

I’m with Nathaniel on this one. Subclasses make code harder to read and reason about because you now have to be sure of the exact type of things that users are passing you — which are array-like but subtly different. On 2 Jul 2017, 9:46 AM +1000, Marten van Kerkwijk , wrote: > I'm not sure ther

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

I agree that shipping a sane/sanitising doctest runner would go 95% of the way to alleviating my concerns. Regarding 2.0, this is the whole point of semantic versioning: downstream packages can pin their dependency as 1.x and know that they - will continue to work with any updates - won’t make t

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

To reiterate my point on a previous thread, I don't think this should happen until NumPy 2.0. This *will* break a massive number of doctests, and what's worse, it will do so in a way that makes it difficult to support doctesting for both 1.13 and 1.14. I don't see a big enough benefit to these c

Re: [Numpy-discussion] Boolean binary '-' operator

OMG deprecating + would be a nightmare. I can’t even begin to count the number of times I’ve used e.g. np.sum(arr == num)… Originally with a dtype cast but generally I’ve removed it because it worked. … But I just saw the behaviour of `sum` is different from that of adding arrays together (wher