[Numpy-discussion] Re: Improved 2DFFT Approach

Hi Alexander, On 2024-03-14 22:43:38, Alexander Levin via NumPy-Discussion wrote: Memory Usage - https://github.com/2D-FFT-Project/2d-fft/blob/testnotebook/notebooks/memory_usage.ipynb Timing comparisons(updated) -

[Numpy-discussion] Re: New DType and ArrayMethod C APIs are public

On Wed, Feb 14, 2024, at 14:34, Nathan wrote: > The DType API publicly exposes the PyArray_DTypeMeta C struct, which > represents DType metaclasses. It also exposes a function for registering > user-defined DTypes and a set of slot IDs and function typedefs that users > can implement in C to

[Numpy-discussion] Re: welcome Raghuveer, Chris, Mateusz and Matt to the NumPy maintainers team

On Fri, Jan 26, 2024, at 12:04, Ralf Gommers wrote: > We've got four new NumPy maintainers! Welcome to the team, and > congratulations to: > > - Raghuveer Devulapalli (https://github.com/r-devulap) > - Chris Sidebottom (https://github.com/mousius) > - Mateusz Sokół (https://github.com/mtsokol/)

[Numpy-discussion] Re: Meson - C extension - Finding numpy includes in virtual env

Hi Nathan, On Tue, Nov 28, 2023, at 08:42, Nathan wrote: > It looks like `spin build` does `meson build` and `meson install` and doesn't > do `pip install`. I'd like numpy to be importable in a python environment of > my choosing, so I tend to instead manually install numpy into that >

[Numpy-discussion] Re: Meson - C extension - Finding numpy includes in virtual env

On Sun, Nov 26, 2023, at 12:03, Nathan wrote: > For my work I tend to use a persistent build directory with build isolation > disabled as discussed in the meson-python docs. Out of curiosity, how is this different from, e.g., `spin build` which builds into `./build-install`? Stéfan

[Numpy-discussion] Re: Meson - C extension - Finding numpy includes in virtual env

Hi Doug, On Sun, Nov 26, 2023, at 06:29, Doug Turnbull wrote: > To debug, I ran `pip install . --no-build-isolation` it worked (using venv's > numpy) When developing NumPy, we typically build in the existing environment. This is done either via `pip install -e .` (which installs hooks to

[Numpy-discussion] Re: Meson - C extension - Finding numpy includes in virtual env

Hi Doug, On Sat, Nov 25, 2023, at 07:14, Doug Turnbull wrote: > Unfortunately the following command fails: > > incdir_numpy = run_command(py, > ['-c', 'import numpy; print(numpy.get_include())'], > capture: true, > check: false, > ).stdout().strip() In your repo it says stderr, but the

[Numpy-discussion] Re: How to sample unique vectors

On Fri, Nov 17, 2023, at 16:52, Robert Kern wrote: > That optimistic optimization makes this the fastest solution. That'd work great, thanks Robert, Aaron, and everyone who shared input. Stéfan___ NumPy-Discussion mailing list --

[Numpy-discussion] Re: How to sample unique vectors

On Fri, Nov 17, 2023, at 14:28, Stefan van der Walt wrote: > Attached is a script that implements this solution. And the version with set duplicates checking. Stéfan import random import functools import itertools import operator import numpy as np def cumulative_prod(arr): return l

[Numpy-discussion] Re: How to sample unique vectors

On Fri, Nov 17, 2023, at 11:07, Robert Kern wrote: > If the arrays you are drawing indices for are real in-memory arrays for > present-day 64-bit computers, this should be adequate. If it's a notional > array that is larger, then you'll need actual arbitrary-sized integer > sampling. The

[Numpy-discussion] How to sample unique vectors

Hi all, I am trying to sample k N-dimensional vectors from a uniform distribution without replacement. It seems like this should be straightforward, but I can't seem to pin it down. Specifically, I am trying to get random indices in an d0 x d1 x d2.. x dN-1 array. I thought about sneaking in

[Numpy-discussion] Re: welcome Andrew Nelson to the NumPy maintainers team

On Mon, Aug 21, 2023, at 01:34, Ralf Gommers wrote: > On behalf of the steering council, I am very happy to announce that Andrew is > joining the Maintainers team. Andrew, a warm welcome to the team! Thank you for all your work so far, and for continuing your involvement with the project.

[Numpy-discussion] Re: update on build system changes in NumPy's main branch

On Fri, Aug 11, 2023, at 12:04, Ralf Gommers wrote: > We've landed some major changes in `main` this week, so I thought it's a good > idea to keep everyone in the loop. This is a *significant* amount of work. Thank you, Ralf, for keeping track of all the moving parts and for working with the

[Numpy-discussion] Example gufuncs

Hi all, To teach gufuncs, we used to rely on the example implementations in `numpy.core.umath_tests`. That module has since been deprecated. Is there another, more suitable location for such examples? I know it's been on SciPy's roadmap to convert some of `sp.linalg` to gufuncs, but that

[Numpy-discussion] Re: Moving busday functionality to numpy-financial

Hi Kai, I agree with that the change has maintenance implications for numpy-financial. It's not *hard* building binary wheels, per se, but it's certainly a bigger job than maintaining and testing pure Python. As the maintainer of that library, you should decide whether that's something you

[Numpy-discussion] Re: Port Powersort Improvement of Timsort

Hi Ben, Thanks for your proposal! On Wed, Jun 14, 2023, at 03:24, Ben Weston wrote: > I wonder if you'd be receptive to a PR bringing the same change to > numpy. I do have an existing implementation in C++ to work from > (https://github.com/sebawild/powersort), in addition to the C >

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

Hi Sebastian, Could you clarify whether there are now varying code paths, depending on the CPU features available? As mentioned on the skimage issue, if results differ but errors are reduced across the board, I'd be happy to fix the test suite. But if this simply jiggers results, I'm less

[Numpy-discussion] Re: Introducing `np.types`

On Tue, Feb 14, 2023, at 12:27, Ralf Gommers wrote: > Okay, as long as we keep in mind that it should contain all these > not-for-main-namespace functions/classes, it seems fine with me. We can live > with two namespaces (`types` and `exceptions`), but more would get a bit too > much. We were

[Numpy-discussion] Re: Congratulation to our newest maintainer Mukulika Pahari

On Fri, Jan 27, 2023, at 02:20, Matti Picus wrote: > The NumPy steering council recently granted maintainer rights to > Mukulika Pahari (https://github.com/Mukulikaa/) Congratulations, Makulika, and thank you for all your work on the project! Stéfan

[Numpy-discussion] Re: ANN: NumPy Fellowship Program & Sayed Adel as our first Developer in Residence

On Thu, Dec 1, 2022, at 13:27, Stefan van der Walt wrote: > On Thu, Dec 1, 2022, at 13:17, Ralf Gommers wrote: >> I'm excited to be able to share this announcement on behalf of the NumPy >> Steering Council. We have created a new program, the NumPy Fellowship >> Program, a

[Numpy-discussion] Re: ANN: NumPy Fellowship Program & Sayed Adel as our first Developer in Residence

On Thu, Dec 1, 2022, at 13:17, Ralf Gommers wrote: > I'm excited to be able to share this announcement on behalf of the NumPy > Steering Council. We have created a new program, the NumPy Fellowship > Program, and offered Sayed Adel the very first Developer in Residence role. > Sayed starts his

[Numpy-discussion] Re: Expanding support in testing for external collections.Sequence objects

On Tue, Nov 29, 2022, at 07:21, i...@markopacak.com wrote: > The debate is whether np.testing.asset_equal should support > collections.Sequence objects. assert list(sequence1) == list(sequence2) should do the trick, and also handles int vs float and nan comparisons. > What is the general view

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

On Fri, Nov 25, 2022, at 08:33, Sebastian Berg wrote: > I would like to formally propose accepting NEP 51. Without any concern > voiced, we will consider it accepted within 7 days. +1 We should update the NEP to match any changes made later, like `np.str_` and `np.bool_`, so that we have a

[Numpy-discussion] Re: Add a new CI provider for aarch64, macos arm64, musl

Hi Matti, On Mon, Nov 21, 2022, at 06:20, Matti Picus wrote: > I am writing to the list for visibility: I opened an issue [0] about > adding the Cirrus CI provider to take over some of the CI task runners > from travis.com. We have been experiencing strange timeouts on the > travis runs, and

[Numpy-discussion] Re: plan for moving to Meson

On Fri, Nov 11, 2022, at 06:03, Evgeni Burovski wrote: > before: any thoughts to change it to e.g. tempita templating? With the "e.g." maybe being jinja2. tempita works well, but hasn't been worked on since 2013. Stéfan ___ NumPy-Discussion mailing

[Numpy-discussion] Re: Create `np.exceptions` for new exceptions in NumPy?

Hi Sebastian, On Fri, Nov 11, 2022, at 05:46, Sebastian Berg wrote: > I would suggest introducing `np.exceptions`. > > We already have custom errors and warnings: > > * AxisError > * TooHardError (used by `np.shares_memory()`) > * ComplexWarning > * RankWarning > * VisibleDeprecationWarning > *

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

On Fri, Oct 28, 2022, at 01:54, Sebastian Berg wrote: > The main change is to show scalars as: > > * `np.float64(3.0)` ­instead of just `3.0` > * `np.True_` instead of `True` > * `np.void((3, 5), dtype=[('a', ' `(3, 5)` > * Use `np.` rather than `numpy.` for datetime/timedelta. I very much

[Numpy-discussion] Re: NEP 50 and integers (e.g. uint8 together -1)

Hi Sebastian, On Wed, Sep 28, 2022, at 12:11, Sebastian Berg wrote: > np.array([1, 2], dtype="uint8") + (-1) > > which currently returns an "int16" array must raise an error. This is > because we want to return a uint8 array but the -1 cannot be > represented well by -1. Did you mean: the

[Numpy-discussion] Re: PR hasn't been responded to in 2 weeks

On Wed, Sep 28, 2022, at 08:01, Matti Picus wrote: > The reviewers also asked you to consider a different interface > (method=), I did not see a response to that suggestion. I think that interface suggestion makes sense. Since there seemed to be some confusion in the comments, I'll summarize

[Numpy-discussion] Re: Representation of NumPy scalars

I am in favor of such a change. It will make what is returned more transparent to users (and reduce confusion for newcomers). With NEP50, we're already adopting a philosophy of explicit scalar usage anyway: no longer pretending or trying to make transparent that Python floats and NumPy floats

[Numpy-discussion] Re: Display runtime information through a new function: `show_runtime`

On Tue, Aug 9, 2022, at 04:10, Ralf Gommers wrote: >> >> On 7/8/22 07:08, Stefan van der Walt wrote: >> > >> > If the aim is to merge these functions (show_config/runtime) >> > eventually, why not merge them now and avoid introducing another >>

[Numpy-discussion] Re: Display runtime information through a new function: `show_runtime`

Hi Ganesh, If the aim is to merge these functions (show_config/runtime) eventually, why not merge them now and avoid introducing another function into the root namespace? Stéfan On Sat, Aug 6, 2022, at 20:55, Ganesh Kathiresan wrote: > Hi Team, > > We are planning on adding a new function

[Numpy-discussion] Re: GSoC Student Announcement 2022

On Mon, May 23, 2022, at 07:24, Rohit Goswami wrote: > NumPy as a sub-organization under the Python Software Foundation > organization will be mentoring a summer student this year funded by the > Google Summer of Code program. Ralf facilitated the application process > and I will be the primary

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

On Mon, May 23, 2022, at 10:34, Ralf Gommers wrote: > I'm not so interested in the detailed discussion later on in this thread to > be honest. Let me propose a simple solution that should make everyone happy: > 1. We drop pdf builds in CI, the release process and the Docker image, but > keep

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

Hi Matti, On Thu, May 5, 2022, at 22:08, Matti Picus wrote: > This somehow runs when I do "git commit"? Do I need to add anything to > my git environment to pick up the hook? How do I turn it off if I find > it prevents progress or breaks? Do we need to add anything to the > documentation to

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

On Thu, May 5, 2022, at 12:00, Trevor Gross wrote: > I don't necessarily know that this should be enforced on CI off the bat > (though in the future it could be), but at least having the tool available > and easily usable would help to incrementally improve codebase style, and > remove the need

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

On Tue, Mar 8, 2022, at 09:01, Sebastian Berg wrote: > An annoyance with methods is that our class is `np.ndarray` with an > awkward `__new__` [2]. > So if it is `np.array.from_*` it would not be (only) a static- or > classmethod, but also attached to that function. It sounds like there are

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

Hi Sebastian, On Tue, Mar 8, 2022, at 07:41, Sebastian Berg wrote: > just a brief note that: > > https://github.com/numpy/numpy/pull/21145 > > will add `np.from_dlpack` (to import objects implementing the > `__dlpack__` dunder [1]. In other places in the ecosystem, like pandas and xarray,

[Numpy-discussion] Depending on NumPy: to future pin or not

Hi all, There's a discussion at https://github.com/numpy/numpy/pull/21144 on whether we should recommend to libraries that depend on NumPy to limit the number of future NumPy releases their package will operate with. If this is something you've spent time thinking about, please weigh in.

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

On Mon, Feb 21, 2022, at 20:56, Juan Nunez-Iglesias wrote: > > 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

[Numpy-discussion] Re: Unpacking 0-D object arrays when setting item/filling

On Mon, Feb 14, 2022, at 12:45, Sebastian Berg wrote: > But this is currently *not* consistently the case. I wish to make this > consistent. The confusion is around object arrays, though: > > value = np.array(None, dtype=object) > arr[0] = value > > Stores `value` without unpacking it

[Numpy-discussion] Re: Announcement: SciPy Community Meetings

On Sat, Jan 29, 2022, at 07:11, Melissa Mendonça wrote: > The next one will happen this week, on* February 2, at 12 pm UTC*. I just want to confirm that this means "mid-day UTC" or "4am Pacific"? Stéfan ___ NumPy-Discussion mailing list --

[Numpy-discussion] Re: Shape detection

Hi Pawel, I would recommend scikit-image for these types of analysis. Here's a start: --- from skimage import io, measure import numpy as np image = io.imread('disc.png') thresholded = image > 10 labels = measure.label(image) regions = measure.regionprops(labels) regions_small = [r for r in

[Numpy-discussion] Re: Fit 2D points to closed curve

Hi Roger, On Thu, Jan 20, 2022, at 07:13, roger.dav...@geo-spatial.co.uk wrote: > I use a CAD package called Rhino which lets users write python scripts > that run in the cad environment. I have a closed curve that is a design > surface border and I have a sparse data set of 2D surveyed points

[Numpy-discussion] Re: Performance mystery

On Tue, Jan 18, 2022, at 21:55, Warren Weckesser wrote: > expr = 'z.real**2 + z.imag**2' > > z = generate_sample(n, rng) 樂 If I duplicate the `z = ...` line, I get the fast result throughout. If, however, I use `generate_sample(1, rng)` (or any other value than `n`), it does not improve

[Numpy-discussion] Re: Code formatters

On Thu, Nov 18, 2021, at 09:51, Sebastian Berg wrote: > Git can even mark commits as "only style fixups" I think to hide them > from `git blame` and following history has never bothered me too much; > the only thing that seems tricky there is when functionality is moved > between files. > The main

[Numpy-discussion] Tensor typing meeting (15 Nov) slides & video

I thought this might be of interest to Bas and others. - Original message - From: Matthew Rahtz via Typing-sig Date: Tuesday, November 16, 2021 02:31 Thanks to everyone for coming! Recording is here ,

[Numpy-discussion] Re: Code formatters

On Sun, Nov 14, 2021, at 15:26, Juan Nunez-Iglesias wrote: > Oh, and yes, yapf does allow formatting only the diff. I agree that > reformatting the entire code base is problematic. That's a good point: it's possible to make these changes incrementally. There's something called yapf-diff. It's

[Numpy-discussion] Re: Code formatters

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 '/', get spaces around them, > * very long strings are not

[Numpy-discussion] Re: Spam in PRs?

Hi Chuck, On Wed, Oct 20, 2021, at 14:35, Charles R Harris wrote: > Anyone know why/how app.netlify got into scipy.org? See > https://github.com/scipy/scipy.org/pull/417 for an example. More information > at https://app.netlify.com/sites/condescending-hopper-c3ed30/deploys . Yes, this is part

[Numpy-discussion] Re: Musllinux wheels

On Tue, Oct 12, 2021, at 10:13, Matthew Brett wrote: > If you haven't got to it, I can do it. Filed a PR for this last night: https://github.com/multi-build/docker-images/pull/20 Best regards, Stéfan ___ NumPy-Discussion mailing list --

[Numpy-discussion] Re: Musllinux wheels

On Mon, Oct 11, 2021, at 07:56, Matthew Brett wrote: > My guess is that that would be less than 90 minutes of work for > someone with some Docker experience. I'll give it a shot. Stéfan ___ NumPy-Discussion mailing list -- numpy-discussion@python.org

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

On Wed, Oct 6, 2021, at 13:57, Aaron Meurer wrote: > Coming back to earth on the original discussion, is there really no > way to moderate new users on the mailing list platform used by this > list (mailman?)? On the SymPy list, which uses Google Groups, we > moderate all new users, so that first

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

On Wed, Sep 29, 2021, at 14:39, Ralf Gommers wrote: > > On Wed, Sep 29, 2021 at 11:32 PM Stefan van der Walt > wrote: >> __ >> On Wed, Sep 29, 2021, at 13:58, Ralf Gommers wrote: >>> This was discussed in the community meeting today. No one was really >&g

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

On Wed, Sep 29, 2021, at 13:58, Ralf Gommers wrote: > This was discussed in the community meeting today. No one was really > enthusiastic, concerns that were brought up included the lack of an email > interface, and an unclear boundary between issues and discussions. FWIW, Discourse has an

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

On Wed, Sep 29, 2021, at 03:02, Ralf Gommers wrote: > We don't have admin access to the python.org lists, so this is a bit of a > problem. We have never had a spam problem, so we can ask to block this user > first. If it continues to happen, we may be able to moderate new subscriber > emails,

Re: [Numpy-discussion] Proposal for adding bit_count

On Mon, Aug 2, 2021, at 10:50, Sebastian Berg wrote: > * Should `np.ndarray.bit_count()` exist? I tend against this; > but we should have it on (integer) scalars to mirror the > Python `int`. Should `np.bit_count` exist? Having it on the int* types may be sufficient. > * The return value

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

On Mon, Jul 5, 2021, at 00:42, Ralf Gommers wrote: > I share your dislike, but I don't really see a better place where it doesn't > make it even harder to spell, but I did just think of an alternative that may > actually be quite reasonable: keep it private. That would be fine. We haven't had

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

On Sun, Jul 4, 2021, at 13:00, Ralf Gommers wrote: > I don't think so. We basically arrived at the solution, and there's a PR that > is mostly done too. This really isn't that complicated that we should require > a NEP. Personally, I don't like np.CopyMode in the main namespace. If we can agree

Re: [Numpy-discussion] `keepdims=True` for argmin/argmx and C-API `PyArray_ArgMaxWithKeepdims`

Hi Sebastian, On Wed, Jun 30, 2021, at 18:23, Sebastian Berg wrote: > The PR https://github.com/numpy/numpy/pull/19211 proposes to extend > argmin and argmax with a `keepdims=False` keyword-only argument. This seems consistent with existing APIs, so I'm not concerned. For those wondering,

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

On Thu, Jun 24, 2021, at 01:03, Ralf Gommers wrote: > For this one, I'd say it kinda looks like we do need one, so then let's just > add one and be done with it, rather than inventing odd patterns like tacking > enum members onto an existing function. There are two arguments on the table that

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

On Wed, Jun 23, 2021, at 18:01, Juan Nunez-Iglesias wrote: > 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

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

opy.NEVER = _CopyNever() > ``` > > All of these versions (and using the enum directly) seem fine to me. > If we go down the enum route route, we probably want to add "new-style" > versions of `np.CLIP` and friends that are true enums / live within a more > obvious

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

On Sun, Jun 20, 2021, at 20:46, Gagandeep Singh wrote: > I have recently joined the mailing list and have gone through the previous > discussions on this thread. I would like to share my analysis (advantages and > disadvantages) of three possible alternatives (Enum, String, boolean) to >

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

On Sun, Jun 20, 2021, at 18:53, Charles R Harris wrote: > > On Fri, Jun 18, 2021 at 8:52 AM Stefan van der Walt > wrote: >> __ >> On Thu, Jun 17, 2021, at 16:23, Stephan Hoyer wrote: >>> This happens all the time. Even if we make copy='never' an error *today*,

Re: [Numpy-discussion] NEP 36- fair play (was: request to remove the numpy-aarch64 package from PyPI)

On Tue, Jun 15, 2021, at 00:38, Matti Picus wrote: > Having just re-read the NEP, I think the Motivation section should > mention name re-use: "Additionally, we wish to reduce confusion when > package names imply they are sanctioned or maintained by NumPy". Other > than that it looks good to

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

On Thu, Jun 17, 2021, at 16:23, Stephan Hoyer wrote: > This happens all the time. Even if we make copy='never' an error *today*, > users will be encountering existing versions of NumPy for years into the > future, so we won't be able to change the behavior of copy='never' for a very > long

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

On Tue, Jun 15, 2021, at 11:12, ALFONSO LUIS CASTAÑO MARIN wrote: > To what potential PEP are you referring exactly? Type arithmetic or > automatically interpret `1` as `Literal[1]` wherever it makes sense? I guess both, but particularly the first (using standard operators in type

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

Hi Alfonso, Matthew, On Tue, Jun 15, 2021, at 06:59, ALFONSO LUIS CASTAÑO MARIN wrote: > First of all, when talking about type arithmetic I suggest to refer to the > latest presentation for the summit rather than from the Tensor Typing > Meetings >

Re: [Numpy-discussion] request to remove the numpy-aarch64 package from PyPI

On Sun, Jun 13, 2021, at 18:21, Charles R Harris wrote: > > > On Sun, Jun 13, 2021 at 10:47 AM Ralf Gommers wrote: >> FYI, I noticed this package that claimed to be maintained by us: >> https://pypi.org/project/numpy-aarch64/. That's not ours, so I tried to >> contact the author (no email

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

On Tue, Jun 8, 2021, at 03:23, Juan Nunez-Iglesias wrote: > Hello! Any chance this could be recorded for those of us in useless > time zones?  I added a note to the agenda; we'll ask the speakers and record if they don't mind. Stéfan ___

Re: [Numpy-discussion] Google Season of Docs

On Fri, May 14, 2021, at 11:41, Melissa Mendonça wrote: > I am happy to announce we found our technical writer for the Google Season of > Docs program. After looking at all submitted proposals we have decided to > hire Mukulika. You can see her Statement of Interest here: >

Re: [Numpy-discussion] Steering Council membership updates

On Wed, Mar 31, 2021, at 03:18, Ralf Gommers wrote: > We're excited to welcome Inessa Pawson and Melissa Mendonça as new SC > members. Inessa has been contributing for close to two years, and has been a > driving force behind the new website, the user survey, and other content and > community

[Numpy-discussion] Development branches renamed

Hi everyone, The development branches of most of the repositories on github.com/numpy have been renamed to `main` (this is the GitHub default for newly created repositories). The move has not yet been made for sub-projects such as `numpydoc` or `numpy.org`, but those should follow soon. We

Re: [Numpy-discussion] Pearu Peterson has joined the NumPy developers team.

On Sun, Feb 7, 2021, at 10:12, Charles R Harris wrote: > Pearu Peterson has joined the NumPy developers team. Pearu was responsible > for contributing f2py and much of distutils in the early days of NumPy. > Welcome back Pearu. Welcome back, it's good to see you around more, Pearu! Best

Re: [Numpy-discussion] On the use of adding an expfit class in or next to the polynomial module

Hi there, Thanks for reaching out. On Wed, Jan 27, 2021, at 04:24, Swan BOSC wrote: > Namely, the expfit function, as presented here > > (https://octave.sourceforge.io/optim/function/expfit.html) doesn't seem to > exist. I'm currently

[Numpy-discussion] PSF Scientific WG grants

Hi all, I'd like to make you aware of this call for funding from the PSF: https://pyfound.blogspot.com/2020/12/psf-scientific-working-group-announces.html Funding is for up to 4000 USD. The deadline has been extended (the blog post will soon be updated accordingly); I recommend submitting

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

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 within the next five days. Thanks for the heads-up, Ralf. I am

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

Hi Sebastian, Looking at these three rules, they all seem to stem from one simple question: do we desire for a single code snippet to be runnable on multiple array implementations? On Wed, Dec 2, 2020, at 15:34, Sebastian Berg wrote: > 1. If an argument is invalid in NumPy it is considered and

Re: [Numpy-discussion] API, NEP: Inclusion of the experimental `like=` argument in NumPy 1.20 (we currently lean to yes)

On Thu, Nov 12, 2020, at 17:48, Sebastian Berg wrote: > [3] There is the "middle ground": We could require an environment > variable to activate it. But we discussed it briefly at the community > meeting as well, and I think the consensus was there is probably no > good argument for that. (e.g. it

Re: [Numpy-discussion] New package to speed up ufunc inner loops

On Wed, Nov 4, 2020, at 16:21, Aaron Meurer wrote: > But as I noted, this is already off topic for the original discussion > here, and since there's apparently no interest in improving the NEP > wording, I'll drop it. I was trying to understand where, specifically, the language falls short, and

Re: [Numpy-discussion] New package to speed up ufunc inner loops

On Wed, Nov 4, 2020, at 14:54, Aaron Meurer wrote: > Again, *I* understand the purpose of this document, but I think the > way it is currently written it could easily be misinterpreted by > someone else. Misinterpreted in what way? That they would think we have an ability to enforce the

Re: [Numpy-discussion] New package to speed up ufunc inner loops

On Wed, Nov 4, 2020, at 13:47, Aaron Meurer wrote: > I hope this isn't too off topic, but this "fair play" NEP reads like > it is a set of additional restrictions on the NumPy license, which if > it is, would make NumPy no longer open source by the OSI definition. I > think the NEP should be much

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

On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote: > I also misunderstood the purpose of the NEP. I assumed it was > intended to encourage projects to drop old versions of Python. Other > people have viewed the NEP similarly: > https://github.com/networkx/networkx/issues/4027 Of all the

Re: [Numpy-discussion] NumPy team update

Ralf, thank you very much for summarizing community movements—it is great to see all this growth. To all new committers and team members, thank you, and welcome! Your work is so appreciated. Keep up the good work! Stéfan On Thu, Jun 18, 2020, at 23:57, Ralf Gommers wrote: > The NumPy team is

Re: [Numpy-discussion] Armv8 server donation

On Thu, Jun 11, 2020, at 13:47, ChunLin Fang wrote: > I noticed that the shippable CI always skipped after PR submitted , The > reason why it's skip seems to be "No active nodes found in shared node pool > "shippable_shared_aarch64"" > Potential bugs may buried through out numpy without

Re: [Numpy-discussion] Google Season of Docs 2020 - New NumPy Community Member

Hi Themistoklis, Welcome to the NumPy mailing list! Thank you for the overview of your work. We look forward to the GSoD this year, and I'm excited to see all the enthusiasm for it. Best regards, Stéfan On Tue, May 12, 2020, at 16:02, Themistoklis Spanoudis wrote: > Hello everyone! > > I am

Re: [Numpy-discussion] Season of Docs technical writer

Hi Ben, On Fri, May 1, 2020, at 05:52, Ben Nathanson wrote: > I've updated my page (https://bennathanson.com/numpy2020) to include a > section on Curation and Adaptation. I enjoyed reading your page, and appreciate the wit sprinkled through your writing. I look forward to working with you this

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

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 came around to the > question of whether people are open to the idea of including the type > aliases in NumPy itself. Ralf's

Re: [Numpy-discussion] Suggestion: prevent silent downcast in np.full_like

Hi Alexis, On Mon, Feb 24, 2020, at 12:00, A T wrote: > Here is a summarized code example of how unsafe downcasting in np.full_like() > resulted in issues in our scientific toolbox: > > t0 = 20.5 > # We're trying to make a constant-valued "ufunc" > temperature = lambda x: np.full_like(x, t0) >

Re: [Numpy-discussion] Proposal to accept NEP #44: Restructuring the NumPy Documentation

On Wed, Feb 19, 2020, at 03:58, Melissa Mendonça wrote: > I am proposing the acceptance of NEP 44 - Restructuring the NumPy > Documentation. > > https://numpy.org/neps/nep-0044-restructuring-numpy-docs.html Thanks, Melissa, for developing this NEP! The plan makes sense to me. Best regards,

Re: [Numpy-discussion] Tensor Developer Summit

Hi Neil, On Wed, Feb 19, 2020, at 11:43, Neal Becker wrote: > Sounds like an exciting group! Will it be streamed? Due to the highly interactive nature of this event, we will not be streaming. Best regards, Stéfan ___ NumPy-Discussion mailing list

[Numpy-discussion] Tensor Developer Summit

Hi all, This has been mentioned on the community calls, but not on the mailing list, so a reminder about the Tensor Developer Summit happening at March in Berkeley: https://xd-con.org/tensor-2020/ We would love to have developers and advanced users of NumPy (or other array libraries with

[Numpy-discussion] BIDS-NumPy progress reports, 2018/2019

Dear colleagues, I'd like to thank everyone who contributed to NumPy over the past year. NumPy is a complex undertaking that requires inputs from many spheres to progress. Your contribution, however big or small, is important, and we appreciate you taking the time to make it. As we look back

Re: [Numpy-discussion] welcome Shaloo Shalini to the NumPy team

On Fri, Nov 15, 2019, at 15:17, Ralf Gommers wrote: > Please welcome Shaloo Shalini to the NumPy team. Shaloo is an experienced > technology marketing consultant with a passion for open source. She has been > contributing graphical content, information mapping and technical writing > since the

[Numpy-discussion] Sprint, this Friday/Saturday (22/23 November)

Hi everyone, This is a reminder of the NumPy sprint that will be happening in Berkeley this Friday and Saturday, 22 and 23 November. The schedule for the sprint is at: https://hackmd.io/@GicvKC4NRbK9X9ElJTixwg/ryEPQyprr Best regards, Stéfan ___

Re: [Numpy-discussion] a new grant for NumPy and OpenBLAS!

Hi Ralf, On Thu, Nov 14, 2019, at 15:42, Ralf Gommers wrote: > I'm very pleased to announce that NumPy and OpenBLAS have received a joint > grant for $195,000 from the Chan Zuckerberg Initiative. Congratulations on receiving this grant! I am very happy to see more funded involvement in NumPy,

Re: [Numpy-discussion] Unsupporting python3.5

On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote: > I think we can support 3.5 as long as we please, the question is how long we > *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm > concerned about making 1.18 outright incompatible with 3.5. I would like to > see

Re: [Numpy-discussion] Np.genfromtxt Problem

On Fri, Oct 4, 2019, at 10:31, Stephen P. Molnar wrote: > data = np.genfromtxt(files, usecols=(3), dtype=None, skip_header=8, > skip_footer=1, encoding=None) This seems like a good use case for `dask.dataframe.read_csv` [0]. Stéfan [0]

Re: [Numpy-discussion] Low-level API for Random

On Fri, Sep 20, 2019, at 21:30, Robert Kern wrote: > Given the prevalence of Cython, it's actually really easy to use the Python > API pretty easily in "C", so it's actually a huge waste if the C API matches > the Python API too closely. The power and utility of the C API will be in how > it

  1   2   >