Mailman 3 January 2022 - NumPy-Discussion

mixed mode arithmetic
by Neal Becker July 11, 2023

July 11, 2023

I've been browsing the numpy source. I'm wondering about mixed-mode arithmetic on arrays. I believe the way numpy handles this is that it never does mixed arithmetic, but instead converts arrays to a common type. Arguably, that might be efficient for a mix of say, double and float. Maybe not. But for a mix of complex and a scalar type (say, CDouble * Double), it's clearly suboptimal in efficiency. So, do I understand this correctly? If so, is that something we should improve?

4 6

Invalid value encoutered : how to prevent numpy.where to do this?
by Eric Emsellem Feb. 18, 2023

Feb. 18, 2023

Dear all, I have a code using lots of "numpy.where" to make some constrained calculations as in: data = arange(10) result = np.where(data == 0, 0., 1./data) # or data1 = arange(10) data2 = arange(10)+1.0 result = np.where(data1 > data2, np.sqrt(data1-data2), np.sqrt(data2-data2)) which then produces warnings like: /usr/bin/ipython:1: RuntimeWarning: invalid value encountered in sqrt or for the first example: /usr/bin/ipython:1: RuntimeWarning: divide by zero encountered in divide How … [View More]

5 4

Documentation Team meeting - Monday June 8th
by Melissa Mendonça Dec. 4, 2022

Dec. 4, 2022

Hi all! A reminder that on Monday, June 8, we have another documentation team meeting at 3PM UTC**. If you wish to join on Zoom, you need to use this link https://zoom.us/j/420005230 Here's the permanent hackmd document with the meeting notes: https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg <https://www.google.com/url?q=https%3A%2F%2Fhackmd.io%2FoB_boakvRqKR-_2jRV-Q…> Hope to see you around (especially if you want to introduce yourself or discuss ideas for Google Season of Docs). ** You … [View More]

6 74

An extension of the .npy file format
by Michael Siebert Aug. 25, 2022

Aug. 25, 2022

Dear all, originally, I have planned to make an extension of the .npy file format a dedicated follow-up pull request, but I have upgraded my current request instead, since it was not as difficult to implement as I initially thought and probably a more straight-forward solution: https://github.com/numpy/numpy/pull/20321/ What is this pull request about? It is about appending to Numpy .npy files. Why? I see two main use cases: 1. creating .npy files larger than the main memory. They can, … [View More]once finished, be loaded as memory maps 2. creating binary log files, which can be processed very efficiently without parsing Are there not other good file formats to do this? Theoretically yes, but practically they can be pretty complex and with very little tweaking .npy could do efficient appending too. Use case 1 is already covered by the Pip/Conda package npy-append-array I have created and getting the functionality directly into Numpy was the original goal of the pull request. This would have been possible without introducing a new file format version, just by adding some spare space in the header. During the pull request discussion it turned out that rewriting the header after each append would be desirable in case the writing program crashes to minimize data loss. Use case 2 however would highly profit from a new file format version as it would make rewriting the header unnecessary: since efficient appending can only take place along one axis, setting shape[-1] = -1 in case of Fortran order or shape[0] = -1 otherwise (default) in the .npy header on file creation could indicate that the array size is determined by the file size: when np.load (typically with memory mapping on) gets called, it constructs the ndarray with the actual shape by replacing the -1 in the constructor call. Otherwise, the header is not modified anymore, neither on append nor on file write finish. Concurrent appends to a single file would not be advisable and should be channeled through a single AppendArray instance. Concurrent reads while writes take place however should work relatively smooth: every time an np.load (ideally with mmap) is called, the ndarray would provide access to all data written until that time. Currently, my pull request provides: 1. A definition of .npy version 4.0 that supports -1 in the shape 2. implementations for fortran order and non-fortran order (default) including test cases 3. Updated np.load 4. The AppendArray class that does the actual appending Although there is a certain hassle with introducing a new .npy version, the changes themselves are very small. I could also implement a fallback mode for older Numpy installations, if someone is interested. What do you think about such a feature, would it make sense? Anyone available for some more code review? Best from Berlin, Michael PS thank you so far, I could improve my npy-append-array module as well and from what I have seen so far the Numpy code readability exceeded my already high expectations. [View Less]

5 7

copy="never" discussion and no deprecation cycle?
by Sebastian Berg July 21, 2022

July 21, 2022

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"`, `copy="if_needed"`, and `copy="always"` (i.e. string options for the `copy` keyword argument). Strictly speaking, this is against the typical policy (one year of warning/errors). But nobody could think of a reasonable chance that anyone actually uses it. (For me just "policy" will be enough of an argument to just take it … [View More]slow.) BUT: If nobody has *any* concerns at all, I think we may just end up introducing the change right away. The PR is: https://github.com/numpy/numpy/pull/19173 ## The Feature There is the idea to add `copy=never` (or similar). This would modify the existing `copy` argument to make it a 3-way decision: * `copy=always` or `copy=True` to force a copy * `copy=if_needed` or `copy=False` to prefer no-copy behavior * `copy=never` to error when no-copy behavior is not possible (this ensures that a view is returned) this would affect the functions: * np.array(object, copy=...) * arr.astype(new_dtype, copy=...) * np.reshape(arr, new_shape, copy=...), and the method arr.reshape() * np.meshgrid and possibly Where `reshape` currently does not have the option and would benefit by allowing for `arr.reshape(-1, copy=never)`, which would guarantee a view. ## The Options We have three options that are currently being discussed: 1. We introduce a new `np.CopyMode` or `np.<something>.Copy` Enum with values `np.CopyMode.NEVER`, `np.CopyMode.IF_NEEDED`, and `np.CopyMode.ALWAYS` * Plus: No compatibility concerns * Downside(?): This would be a first in NumPy, and is untypical API due to that. 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 code has to take care when it may run on older NumPy versions. And in theory could make old code return the wrong thing. * Plus: Strings are the typical for options in NumPy currently. 3. Same as 2. But we take it very slow: Make strings an error right now and only introduce the new options after two releases as per typical deprecation policy. ## Discussion We discussed it briefly today in the triage call and we were leaning towards strings. I was honestly expecting to converge to option 3 to avoid compatibility issues (mainly surprises with `copy="never"` on older versions). But considering how weird it is to currently pass `copy="never"`, the question was whether we should not change it with a release note. The probability of someone currently passing exactly one of those three (and no other) strings seems exceedingly small. Personally, I don't have a much of an opinion. But if *nobody* voices any concern about just changing the meaning of the string inputs, I think the current default may be to just do it. Cheers, Sebastian [View Less]

12 28

Numpy binary wheels and CI for win/arm64 platform
by Niyas Sait June 22, 2022

June 22, 2022

Hello, Numpy v1.21.2 <https://github.com/numpy/numpy/releases/tag/v1.21.2> added support for windows/arm64 platforms but we still don't have any systems in place to produce binary wheels or test win/arm64 packages. I think it will be good to start looking into this. CPython has an official buildbot worker running for win/arm64 and official python support for the platform will be available from the 3.11 release. It is not yet clear to me how the build and CI system for numpy is deployed … [View More]

4 9

[Feature Request] Add alias of np.concatenate as np.concat
by Iordanis Fostiropoulos May 11, 2022

May 11, 2022

In regard to Feature Request: https://github.com/numpy/numpy/issues/16469 It was suggested to sent to the mailing list. I think I can make a strong point as to why the support for this naming convention would make sense. Such as it would follow other frameworks that often work alongside numpy such as tensorflow. For backward compatibility, it can simply be an alias to np.concatenate I often convert portions of code from tf to np, it is as simple as changing the base module from tf to np. e.g. … [View More]

7 6

request to remove the numpy-aarch64 package from PyPI
by Ralf Gommers March 14, 2022

March 14, 2022

Hi all, 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 provided, but guessed the same username on GitHub) and asked to remove it: https://github.com/tomasriv/DNA_Sequence/issues/1. There are a very large number of packages with "numpy" in the name on PyPI, and there's no way we can audit/police that effectively, but if it's a rebuild that pretends like it's official then I … [View More]

5 7

advice for using datetime64 in C binding
by Benoit Gschwind Feb. 18, 2022

Feb. 18, 2022

Hello, I using the following code: if (PyArray_TYPE(arr1) == NPY_DATETIME) { // Ensure datetime64[ms] auto tmp = reinterpret_cast<PyArrayObject*>(PyObject_CallMethod(reinterpret_cast<PyObject*>(arr1), "astype", "(s)", "datetime64[ms]")); std::swap(arr1, tmp); Py_XDECREF(tmp); // Ensure integer tmp = reinterpret_cast<PyArrayObject*>(PyObject_CallMethod(reinterpret_cast<PyObject*>(arr1), "astype", "(s)", "i8")); std::swap(arr1, tmp); Py_XDECREF(tmp); tmp = … [View More]

2 8

adding a new member to the NumPy CoC committee
by Ralf Gommers Feb. 16, 2022

Feb. 16, 2022

Hi all, Anirudh Subramanian has indicated that he is happy to be replaced on the Code of Conduct committee. Right now the committee is Stefan van der Walt, Melissa Mendonca, and Anirudh (stepping down). We'd like to add a new third person. If anyone is interested, could you please reply or reach out to Stefan/Melissa/me? For reference, the last time we updated the committee in May 2020: https://mail.python.org/archives/list/numpy-discussion@python.org/message/4… Cheers, Ralf

1 1

NumPy community meeting – Wednesday, February 2nd, 2022 at 18:00 (6 pm) UTC
by Inessa Pawson Jan. 31, 2022

Jan. 31, 2022

Our next NumPy Community meeting is scheduled for Wednesday, February 2nd at 18:00 (6 pm) UTC. Join us via Zoom: https://berkeley.zoom.us/j/762261535 As always, everyone is welcome and encouraged to attend. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Cheers, Inessa Inessa Pawson Contributor Experience Lead | NumPy

1 0

ANN: SciPy 1.8.0rc4 -- please test
by Tyler Reddy Jan. 30, 2022

Jan. 30, 2022

Hi all, On behalf of the SciPy development team I'm pleased to announce the release candidate SciPy 1.8.0rc4. Please help us test this pre-release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.8.0rc4 One of a few ways to install the release candidate with pip: pip install scipy==1.8.0rc4 ===================== SciPy 1.8.0 Release Notes ===================== Note: SciPy 1.8.0 is not released yet! SciPy 1.8.… [View More]

1 0

Announcement: SciPy Community Meetings
by Melissa Mendonça Jan. 30, 2022

Jan. 30, 2022

Hello, all! Some of you might be interested to know that we are organizing SciPy Community Meetings again. The idea is to have those every two weeks on Wednesdays, alternating between times to try and get as many timezones as possible. The next one will happen this week, on* February 2, at 12 pm UTC*. Here's the hackmd we are using to take notes: https://hackmd.io/pyhudrC5TgSwdJtpPldHgQ Cheers, Melissa p.s. Here's a handy link where you can get the meeting time in your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=SciPy+Community+M…

3 4

New experimental DType example (for physical Unit handling)
by Sebastian Berg Jan. 28, 2022

Jan. 28, 2022

Hi all, I have created a new prototype showcasing the new experimental DType and ufunc API here: https://github.com/seberg/unitdtype Aside from showing Units, this is also a good resource to get an idea of how the new (including very complicated) DTypes will look like, as well as how UFuncs should look like. This time it is in C and much more full featured (although some convenience methods are missing) -- expect more of those to be added over time. As of now, it requires a custom NumPy … [View More]branch (I hope that goes away quickly, but it may always be necessary as new things gets added). It does use `unyt` under-the-hood in order to calculate conversion factors and result units. [1] The code should be able to do quite a lot of things, but of course is not meant to be full-featured yet and bugs are likely if you do stranger things. A main thing is that a good chunk of ufuncs are now supported by "reusing" NumPy's existing ufuncs: * negative, positive * add, subtract * multiple, divide * matmul * fmod * hypot (not sure if this is quite right) * maximum, minimum, fmax, fmin * comparisons (note that we never compare to 0 scalars, unlike some implementations) – that also allows `np.min` and `np.max`. * Logical ufuncs (via casting to boolean) More common things that are definitely not support (as of now!): * `sum` is clunky requiring `initial=QuantityScalar(0, correct_unit)` to work. This is a problem with NumPy's design of the "identity", and the (always known) fix is to improve the identity machinery in NumPy. – I am looking into it, but as usual it requires more cleanup elsewhere for a good solution. * `prod` is more tricky, because its result unit would depend on the number of elements. This (and gufuncs for such operations) would require a specialized, new, API. (I do not think this is hard, but I will not throw myself at it.) * sorting/parititioning and many other functions. Those two can be made to work easily (by using the old API, we should make a new one but that is a different issue). * `arange` and `linspace` each have their problems (linspace just because the `scalar` is not really usable yet). (again, nothing major, although `arange` could use a new machinery) * printing is not great, this requires a cleanup of how NumPy prints... * … Cheers, Sebastian [1] Completely arbitrary and easily replaceable choice, I just found how to get the conversion factors quickly in `unyt`. Plus, without using a dev-version of `astropy`, `astropy.units` sometimes clashes with NumPy `main`. [View Less]

1 0

Numpy array
by bigfixforum＠gmail.com Jan. 27, 2022

Jan. 27, 2022

Hi, i am new to numpy. This is first time i am using numpy. https://github.com/mspieg/dynamical-systems/blob/master/Bifurcations.ipynb This code i found to create bifurcation graph. There is section of code which i am not able to understand vr[stable], vx[stable] vr and vx is array of 150 elements. unstable and stable array also has 150 elements But vr[stable], vx[stable] becomes 75 elements in the array. Which i am not able to umderstand how 150 elements in array drops to 75

4 5

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg Jan. 26, 2022

Jan. 26, 2022

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, January 26th at 17:00 UTC (9:00am Pacific Time). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized, discussed, or reviewed. Best regards Sebastian

1 0

Mac wheel builds for Python 3.8 have stopped working.
by Charles R Harris Jan. 26, 2022

Jan. 26, 2022

Hi All, This seems due to an environment change in azure-pipelines sometime after Jan 7. My guess is the Python version setting environment changed from 0.193 to 0.197. It can be fixed by using `MACOSX_DEPLOYMENT_TARGET=10.14`. Note that 10.9 has been unsupported since 2019 and 10.14 is the lowest version currently supported. We can either change to 10.14 or try to get azure to make a change so that 10.9 works again. I've opened an issue <https://github.com/numpy/numpy/issues/20893>. I … [View More]

1 0

NumPy Newcomers' Hour – Thursday, January 27th
by Inessa Pawson Jan. 25, 2022

Jan. 25, 2022

Our next Newcomers' Hour is this Thursday, January 27th at 4 pm UTC. We have no agenda this time. Stop by to ask questions or just to say hi. Join the meeting via Zoom: https://us02web.zoom.us/j/87192457898 Cheers, Inessa Inessa Pawson NumPy Contributor Experience Lead

1 0

exp(NINF) returns underflow error after version 1.20
by Michael Gutteridge Jan. 25, 2022

Jan. 25, 2022

We have an interesting situation where a test suite that checks the value of e^-inf is behaving differently depending on Numpy version. The minimal test I'm using is: #!/usr/bin/env python3 import numpy as np np.seterr(under='raise') print(np.exp(np.NINF)) With numpy version 1.19.5 and 1.20.3 we consistently get "0.0" as the result. Later versions- 1.21 and 1.22- raise an underflow error: Traceback (most recent call last): File "./under.py", line 4, in <module> print(np.exp(np.… [View More]

2 2

Performance mystery
by Warren Weckesser Jan. 25, 2022

Jan. 25, 2022

In the script below, the evaluation of the expression `z.real**2 + z.imag**2` is timed using the `timeit` module. `z` is a 1D array of random samples with dtype `np.complex128` and with length 250000. The mystery is the change in performance of the calculation from the first array to which it is applied to the second. The output of the script is ``` numpy version 1.23.0.dev0+460.gc30876f64 619.7096 microseconds 625.3833 microseconds 634.8389 microseconds 137.0659 microseconds 137.5231 … [View More]

9 18

Re: Proposal for new function to determine if a float contains an integer
by Stefano Miccoli Jan. 24, 2022

Jan. 24, 2022

I would rather suggest .is_integer(integer_dtype) signature because knowing that 1e300 is an integer is not very useful in the numpy world, since this integer number is not representable as a numpy.integer dtype. Note that in python assert not f.is_integer() or int(f) == f never fails because integers have unlimited precision but this does would not map into assert ( ~f_arr.is_integer() | (np.int64(f_arr) == f.arr) ).all() because of possible OverflowErrors. Stefano > On 31 Dec 2021, … [View More]

4 4

Shape detection
by pawel.darlak＠gmail.com Jan. 24, 2022

Jan. 24, 2022

Hello, I am not sure that this is correct group for my problem but I hope someone can help me :) I try to analyze picture with porous material (https://python.neocast.eu/disc.png). I calculate a total quantity of each pores but I would like also calculate a porosity. To make I need a size of sample or total pixels which are in the sample. How to do it ? thanks in advance Pavel

3 2

Upcoming: 2nd edition of "Machine learning with scikit-learn MOOC"
by Gael Varoquaux Jan. 23, 2022

Jan. 23, 2022

Hi everyone, The team at Inria, with the help of the Inria learning lab, will soon be opening the 2nd edition of the "Machine Learning with scikit-learn" MOOC: https://www.fun-mooc.fr/en/courses/machine-learning-python-scikit-learn/ The content of the MOOC is visible here (we are still polishing details, this is not final): https://inria.github.io/scikit-learn-mooc/ As you can see, it touches all the basics of machine learning, introduced with scikit-learn, teaching much more than the API of … [View More]

1 0

ANN: SciPy 1.8.0rc3 -- please test
by Tyler Reddy Jan. 22, 2022

Jan. 22, 2022

Hi all, On behalf of the SciPy development team I'm pleased to announce the release candidate SciPy 1.8.0rc3. Please help us test this pre-release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.8.0rc3 One of a few ways to install the release candidate with pip: pip install scipy==1.8.0rc3 ===================== SciPy 1.8.0 Release Notes ===================== Note: SciPy 1.8.0 is not released yet! SciPy 1.8.… [View More]

1 0

deprecating numpy.distutils
by Ralf Gommers Jan. 22, 2022

Jan. 22, 2022

Hi all, Now that 1.22.0 is out the door, I think it's time to deprecate `numpy.distutils` completely. A brief summary for context: - `distutils` was deprecated in Python 3.10, and will be removed in Python 3.12 (Oct 2023 release date) - `setuptools` has re-enabled its vendored copy of `distutils` in its 60.0 release. It's incompatible with `numpy.distutils` and many more breaking changes are to be expected. - Rebasing `numpy.distutils` on top of `setuptools` will be a moving target. More … [View More]importantly, `numpy.distutils` still has serious and hard to fix bugs and design issues. For example, we cannot build SciPy in parallel due to race conditions in the Fortran support code, and there's a very elusive bug where building an extension module which links in a static Fortran-only library is underlinked and breaks at runtime in dev environments. My initial plan was to contribute Fortran support and other `numpy.distutils` features to `setuptools`, but I've personally changed my mind on that and don't plan to do that work. I think `setuptools` is moving too slow for this to be a productive exercise, and the design of distutils is fundamentally unfixable. So it's a much better investment of time to help projects migrate away from `numpy.distutils` (and hence from `setuptools`). The tracking issue for this is https://github.com/numpy/numpy/issues/18588. Please see the comments and linked issue/thread for more details. My proposal is: 1. deprecate `numpy.distutils` now in main. 2. keep it around for another 2 years after the 1.23.0 release. On >=3.12 it will raise an informative error when someone tries to import it. 3. Only setuptools < 60.0 is supported. This is the status as of today - unless there's an issue with Python 3.11 support, I don't see a point in spending time on keeping up with new setuptools releases, a pin is just fine. 4. Write a docs page with migration info on how to deal with the deprecation, and update it before the 1.23.0 release. Note that the setuptools maintainers have said that they are happy to consider new features if people want to integrate them. The most popular/useful features for `numpy.distutils` are (1) Fortran support, and (2) nested setup.py support. The former is probably not a good idea to integrate, the latter may be. There aren't many packages who need BLAS/LAPACK support anymore, scikit-learn/statsmodels/etc. switched to the Cython/C API exposed by SciPy, rather than linking to BLAS/LAPACK directly. For NumPy itself, we should move to Meson after the SciPy 1.9.0 release has gone out and ironed out all the remaining issues there. We can revisit that in 6 months or so. Thoughts? Cheers, Ralf [View Less]

4 7

Fit 2D points to closed curve
by roger.davies＠geo-spatial.co.uk Jan. 21, 2022

Jan. 21, 2022

Hi, 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 taken around that border, so some error is included in the 2D data set. I would like to know what python function I could use to do a 2D best fit of the points to the curve. Plenty of examples of fitting curves to points but not of best fitting points to a closed curve of which I do … [View More]

4 3

call for contributions – content writers for the NumPy newsletter
by Inessa Pawson Jan. 19, 2022

Jan. 19, 2022

Happy New Year, everyone! I hope you had a restful holiday break and are entering the new year refreshed and inspired. The NumPy documentation team and I are gearing up for the launch of the NumPy newsletter and currently looking for content writers. If you are new to contributing to open source or NumPy, this is a great way to start. You will deepen your knowledge about NumPy, as software and a community, and collaborate with other NumPy contributors. For more about our plans for the … [View More]

3 5

NumPy Newcomers Hour – Thursday, January 13th
by Inessa Pawson Jan. 19, 2022

Jan. 19, 2022

The next NumPy Newcomers Hour is this *Thursday, January 13th at 4 pm UTC*. We are trying out a new format: a guest speaker presentation + Q&A. *Ganesh Kathiresan*, a NumPy maintainer, will show how to: – browse code with vim, ctags, and cscope; – the basics of how to debug NumPy core files. *Join us via Zoom*: https://us02web.zoom.us/j/87192457898 Cheers, Inessa Inessa Pawson NumPy Contributor Experience Lead

2 3

NumPy 1.22.1 has been released.
by Charles R Harris Jan. 18, 2022

Jan. 18, 2022

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 1.22.1. NumPy 1.22.1 fixes several bugs discovered after the 1.22.0 release. Notable fixes are: - Fix for f2PY docstring problems (SciPy) - Fix for reduction type problems (AstroPy) - Fixes for various typing bugs. The Python versions supported in this release are 3.8-3.10. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.22.1>; source archives, release notes, and wheel … [View More]hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.22.1>. Linux users will need pip >= 0.19.3 in order to install the manylinux2014 wheels. A recent version of pip is needed to install the universal2 macos wheels. *Contributors* A total of 14 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Arryan Singh - Bas van Beek - Charles Harris - Denis Laxalde - Isuru Fernando - Kevin Sheppard - Matthew Barber - Matti Picus - Melissa Weber Mendonça - Mukulika Pahari - Omid Rajaei + - Pearu Peterson - Ralf Gommers - Sebastian Berg *Pull requests merged* A total of 20 pull requests were merged for this release. - #20702: MAINT, DOC: Post 1.22.0 release fixes. - #20703: DOC, BUG: Use pngs instead of svgs. - #20704: DOC: Fixed the link on user-guide landing page - #20714: BUG: Restore vc141 support - #20724: BUG: Fix array dimensions solver for multidimensional arguments... - #20725: TYP: change type annotation for ``__array_namespace__`` to ModuleType - #20726: TYP, MAINT: Allow ``ndindex`` to accept integer tuples - #20757: BUG: Relax dtype identity check in reductions - #20763: TYP: Allow time manipulation functions to accept ``date`` and ``timedelta``... - #20768: TYP: Relax the type of ``ndarray.__array_finalize__`` - #20795: MAINT: Raise RuntimeError if setuptools version is too recent. - #20796: BUG, DOC: Fixes SciPy docs build warnings - #20797: DOC: fix OpenBLAS version in release note - #20798: PERF: Optimize array check for bounded 0,1 values - #20805: BUG: Fix that reduce-likes honor out always (and live in the... - #20806: BUG: ``array_api.argsort(descending=True)`` respects relative... - #20807: BUG: Allow integer inputs for pow-related functions in ``array_api`` - #20814: DOC: Refer to NumPy, not pandas, in main page - #20815: DOC: Update Copyright to 2022 [License] - #20819: BUG: Return correctly shaped inverse indices in array_api set... Cheers, Charles Harris [View Less]

3 3

next NumPy Community meeting – January 19th at 18:00 (6 pm) UTC
by Inessa Pawson Jan. 18, 2022

Jan. 18, 2022

Our next NumPy Community meeting is scheduled for tomorrow, Wednesday, January 19th at 18:00 (6 pm) UTC.* Join us via Zoom: https://berkeley.zoom.us/j/762261535 As always, everyone is welcome and encouraged to attend. To add to the meeting agenda the topics you’d like to discuss, follow the link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both *PLEASE NOTE that the schedule has slightly changed: starting tomorrow, we will be meeting an hour earlier. To convert the start time to the local time … [View More]

1 0

numpy 1.22.1 failed with "RuntimeError: Setuptools version is '60.5.0', version < '60.0.0' is required."
by s.srigowthami＠gmail.com Jan. 18, 2022

Jan. 18, 2022

Hi, We are using Openstack zuul ( Openstack CI ) to deploy devstack on IBM PPC64el hardware In https://review.opendev.org/c/openstack/requirements/+/824810/2/upper-constr… commit the numpy package version is updated from 1.22.0 to 1.22.1 When the version 1.22.0 of numpy was used setuptools-60.5.0 has successfully deployed. where as with the latest numpy 1.22.1 the setuptools package installation is failing with the below runtime error. Error: 2022-01-18 12:17:18.663446 | devstack-focal-… [View More]

2 1

ndarray typing advise
by Vincent Schut Jan. 18, 2022

Jan. 18, 2022

Hi, I'm having a hard(ish) time adding the right type annotations to some numpy-using code. I hope someone more knowledgeable can give me some advise. Specifically, the following questions pop up: - How do I correctly type a ndarray as being an array of float64, such that mypy can infer that when I index this array, the result is actually a float (currently I consistently get "Any" after indexing)? - How can I get compatibility between np.floating and builtin.float? Currently, some … [View More]

3 3

Importance of setting up SVML during build
by Sandro Tosi Jan. 16, 2022

Jan. 16, 2022

Hello, i'm preparing 1.22.1 for inclusion in Debian, and noticed how the new numpy has a git submodule to include numpy/SVML in its source tree. We are basing the debian package on the github tarball, and that does not include any submodule, so i'm wondering how important it is to have the SVML files around when building the packages. Given it's not immediately possible to include an external set of files, i'm just trying to balance the effort to inject them and their usefulness. At the same … [View More]

2 2

MacPython travis funds have run out (again)
by Charles R Harris Jan. 14, 2022

Jan. 14, 2022

Hi All, Travis wheel build problems again. There is still a positive balance, but apparently it is insufficiently positive. Which is strange if ARM64 is free. Wheel builds have been failing since last weekend. Matti, could you ask for more credits? I'm thinking we really need to move off travis for ARM builds. Chuck

3 7

np.convolve question
by cae＠live.in Jan. 14, 2022

Jan. 14, 2022

Hello, I am a mechanical engineer and am using Numpy Convolve to smoothen 1D data collected from physical testing for a diesel engine. (I found convolve the best after comparing with other smoothing methodologies) I tried reading the numpy manual and the wikipedia article referenced in it. But I would specifically like to ask/discuss what would happen if the second 1D input is not given? what type of window will the function pass the data through to smoothen it? Here are the articles I have … [View More]

3 2

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg Jan. 12, 2022

Jan. 12, 2022

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, January 12th at 17:00 UTC (9:00am Pacific Time). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized, discussed, or reviewed. Best regards Sebastian

1 0

Writing an array subclass in a compiled language with proper dispatch
by Juan Luis Cano Rodríguez Jan. 11, 2022

Jan. 11, 2022

Hi all, I am a long time user of astropy.units, which allows one to define quantities with physical units as follows: >>> from astropy import units as u >>> 10 << u.cm <Quantity 10. cm> >>> np.sqrt(4 << u.m ** 2) <Quantity 2. m> >>> ([1, 1, 0] << u.m) @ ([0, 10, 20] << u.cm / u.s) <Quantity 10. cm m / s> >>> (([1, 1, 0] << u.m) * ([0, 10, 20] << u.cm / u.s)).to(u.m ** 2 / u.s) <Quantity [0. , … [View More]

3 3

representation of valid float type range
by alejandro.giacometti＠gmail.com Jan. 10, 2022

Jan. 10, 2022

I am getting an interesting result, and I'm wondering if anyone would care to give me some intuition of why. The example is simple enough, I want to get a range of values that are representable by a type: ```python f64_info = np.finfo(np.float64) valid_range = np.linspace( start=f64_info.min, stop=f64_info.max, num=10 ) valid_range => array([ nan, inf, inf, inf, inf, inf, inf, inf, … [View More] inf, 1.79769313e+308]) ``` The minimum value is representable by the type, I can see it: ```python f64_info.min => -1.7976931348623157e+308 ``` I thought that maybe the valid range cannot start with the minimun value, so I've tried a few alternatives: ```python valid_range = np.linspace( start=f64_info.min + f64_info.eps, stop=f64_info.max, num=10 ) valid_range => array([ nan, inf, inf, inf, inf, inf, inf, inf, inf, 1.79769313e+308]) valid_range = np.linspace( start=f64_info.min + f64_info.tiny, stop=f64_info.max, num=10 ) valid_range => array([ nan, inf, inf, inf, inf, inf, inf, inf, inf, 1.79769313e+308]) ``` I thought maybe the range is too wide, but I can do this: ```python valid_range = np.linspace( start=0, stop=f64_info.max, num=10 ) valid_range => array([0.00000000e+000, 1.99743682e+307, 3.99487363e+307, 5.99231045e+307, 7.98974727e+307, 9.98718408e+307, 1.19846209e+308, 1.39820577e+308, 1.59794945e+308, 1.79769313e+308]) ... valid_range = np.linspace( start=f64_info.tiny, stop=f64_info.max, num=10 ) valid_range => array([2.22507386e-308, 1.99743682e+307, 3.99487363e+307, 5.99231045e+307, 7.98974727e+307, 9.98718408e+307, 1.19846209e+308, 1.39820577e+308, 1.59794945e+308, 1.79769313e+308]) ... f32_info = np.finfo(np.float32) valid_range = np.linspace( start=f32_info.tiny, stop=f32_info.max, num=10, dtype=np.float32, ) valid_range => array([1.1754944e-38, 3.7809150e+37, 7.5618299e+37, 1.1342745e+38, 1.5123660e+38, 1.8904575e+38, 2.2685490e+38, 2.6466405e+38, 3.0247320e+38, 3.4028235e+38], dtype=float32) ``` I know that linear space is arbitrary, and perhaps not that useful. In fact this is valid: ```python valid_range = np.logspace( start=f64_info.minexp, stop=f64_info.maxexp, num=10, base=2, endpoint=False ) valid_range => array([2.22507386e-308, 8.67124674e-247, 3.37923704e-185, 1.31690901e-123, 5.13207368e-062, 2.00000000e+000, 7.79412037e+061, 3.03741562e+123, 1.18369915e+185, 4.61294681e+246]) ``` But I'm still confused on why linear space is invalid Thanks! [View Less]

7 10

mypy false positives
by Vincent Schut Jan. 7, 2022

Jan. 7, 2022

Hi all, I've got a question about numpy typing. We have our own internal codebase that heavily depends on numpy, and we're trying to get the number of mypy errors down. Many of the remaining mypy errors are actually numpy false positives. I hoped that with the numpy 1.22.0 release these would be fixed, as there ought to be many typing improvements in that version, but apparently they're not? I'm asking here to check if this is just still a work in progress and we should be patient, or … [View More]

2 2

No credits left in travis for 1.22.0 release
by Charles R Harris Jan. 6, 2022

Jan. 6, 2022

Hi All, We need to get more credits in order to run MacPython/numpy-wheels builds on travis. Anyone recall how to go about this? Chuck

5 8

NumPy Community Meeting Wednesday
by Sebastian Berg Jan. 5, 2022

Jan. 5, 2022

Hi all, There will be a NumPy Community meeting Wednesday January 5th at 19:00 UTC. Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

MyGrad 2.1.0 has been released
by rsoklaski＠gmail.com Jan. 4, 2022

Jan. 4, 2022

Hi all, I am pleased to announce that MyGrad 2.1.0 has been released. In accordance with NEP 29, we have dropped support for NumPy < 1.19. Changelog: https://mygrad.readthedocs.io/en/latest/changes.html#v2-1-0 What the heck is MyGrad? MyGrad provides drop-in automatic differentiation to native NumPy code. Just pass MyGrad-tensors into your NumPy-based code (instead of arrays), and start differentiating! It accomplishes this by making keen use of NumPy's function-override mechanisms.

1 0

Re: An article on numpy data types (Lev Maximov)
by Stefano Miccoli Jan. 2, 2022

Jan. 2, 2022

First of all, happy new 2022 UTC year! Let my add just a very brief note to this discussion: I opened https://github.com/numpy/numpy/issues/20675 <https://github.com/numpy/numpy/issues/20675> which addresses the shortcomings of the current documentation, which is in my opinion not sufficiently explicit in stating the datetime64 semantics. It is true that these are largely consistent with python ‘datetime.datetime’, but ‘explicit is better than implicit’. If nobody objects I will then … [View More]open a doc-only PR adding a very short paragraph to the docs trying to explain the points discussed here. As what regards how much time UTC gained from 1970-01-01 up to today, you are right, it’s about 29 s. The UTC timescale was officially born in 1963 but it can be traced back at least up to 1956/1958, see https://github.com/skyfielders/python-skyfield/issues/679 <https://github.com/skyfielders/python-skyfield/issues/679> where this is discussed with reference to the timescales implemented in python-skyfield. Stefano > On 31 Dec 2021, at 13:27, numpy-discussion-request(a)python.org wrote: > > Hey, Stefano! > > The level of being pedantic is absolutely acceptable. > > I don't question any of your arguments. They are all perfectly valid. > > Except that I'd rather say it is ~29 seconds if measuring against 1970. Leap seconds were introduced in 1972 and there were > a total of 27 seconds since then, but TAI time was ticking since 1958 and gained 10 seconds by 1970 so it is approximately 0.83 second per year at which gives approx 28.67 sec between today and 1970. > So 1970 is a bad choice of epoch if you want to introduce a leap-second-aware datetime. > In GPS time they chose 1980. In TAI it is 1958, but that is somewhat worse than 1980 because it is not immediately clear how to perform the conversion timestamp<->timedelta between 1958 and 1970. > > Something like 'proleptic gps time' would be needed to estimate the number of leap seconds in the years before 1972 when they were introduced. Or maybe to limit the leap-second timescale > to start at 1972 and not to accept any timestamps before that date. > > The system that ignores the existence of the leap seconds has a right to exist. > But it just has limited applicability. > > np.datetime64 keeps time as a delta between the moment in time and a predefined epoch. > Which standard does it use to translate this delta to human-readable time in years, > months, and so on? > > If it is UTC, then it must handle times like 2016-12-31 23:59:60, because it is a valid UTC timestamp. > >>> np.datetime64('2016-12-31 12:59:60') > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ValueError: Seconds out of range in datetime string "2016-12-31 12:59:60" > > Datetime also fails (so far) to handle it: > >>> dt(2016,12,31,23,59,60) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ValueError: second must be in 0..59 > > But `time` works. Well, at least it doesn't raise an exception: > >>> t = time.struct_time((2016,12,31,12,59,60,0,0,0)); t > time.struct_time(tm_year=2016, tm_mon=12, tm_mday=31, tm_hour=12, tm_min=59, tm_sec=60, tm_wday=0, tm_yday=0, tm_isdst=0) > >>> time.asctime(t) > 'Mon Dec 31 12:59:60 2016' > >>> time.gmtime(calendar.timegm(t)) > time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=1, tm_isdst=0) > > Imagine a user that decides which library to use to store some (life critical!) measurements taken every 100 ms. He looks at NumPy datetime64, reads that it is capable of handling attosecods, and decides that it is a perfect fit. Now imagine that on 31 Dec 2022 the World Government decided to inject a leap second. The system will receive the announcement from the NTC servers and will > prepare to replay this second twice. As soon as this moment chimes in he'll run into a ValueError, which he won't notice because he's celebrating a New Year :) And guess whom he'll blame? ;) > > Actually the humanity has already got used to replaying timespans twice. It happens every year in the countries that observe daylight saving time. And the solution is to use a more linear scale than local time, namely, UTC. But now turns out that UTC is not linear enough and it also has certain timespans happening twice. > > The solution once again is use a _really_ linear time which is TAI. I think python 'time' library did a right thing to introduce time.CLOCK_TAI, after all. > > Astropy handles the UTC scale properly though: > >>> t = Time('2016-12-31 23:59:60') > <Time object: scale='utc' format='iso' value=2016-12-31 23:59:60.000> > >>> t0 = Time('2016-12-31 23:59:59') > <Time object: scale='utc' format='iso' value=2016-12-31 23:59:59.000> > >>> delta = t-t0 > <TimeDelta object: scale='tai' format='jd' value=1.1574074074038876e-05> > >>> delta.sec > 0.9999999999969589 > >>> t0 + delta > <Time object: scale='utc' format='iso' value=2016-12-31 23:59:60.000> > > So the solution for that particular person with regular intervals of time is to use astropy. I mention it in the article. > I made some corrections to the text. I'd be grateful if you had a look and pointed me to the particular sentences > that need improvement. > > Best regards, > Lev > [View Less]

3 3

NumPy 1.22.0 has been released
by Charles R Harris Jan. 1, 2022

Jan. 1, 2022

Hi All, On behalf of the NumPy team, I'm pleased to announce the release of NumPy 1.22.0. NumPy 1.22.0 is a big release featuring the work of 153 contributors spread over 609 pull requests. There have been many improvements, highlights are: - Annotations of the main namespace are essentially complete. Upstream is a moving target, so there will likely be further improvements, but the major work is done. This is probably the most user visible enhancement in this release. - A … [View More]preliminary version of the proposed Array-API is provided. This is a step in creating a standard collection of functions that can be used across applications such as CuPy and JAX. - NumPy now has a DLPack backend. DLPack provides a common interchange format for array (tensor) data. - New methods for `quantile`, `percentile`, and related functions. The new methods provide a complete set of the methods commonly found in the literature. - A new configurable allocator for use by downstream projects. These are in addition to the ongoing work to provide SIMD support for commonly used functions, improvements to F2PY, and better documentation. The Python versions supported in this release are 3.8-3.10, Python 3.7 has been dropped. Note that 32 bit wheels are only provided for Python 3.8 and 3.9 on Windows, all other wheels are 64 bits on account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit support. All 64 bit wheels are also linked with 64 bit integer OpenBLAS, which should fix the occasional problems encountered by folks using truly huge arrays. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.22.0/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.22.0>. Linux users will need pip >= 0.19.3 in order to install the manylinux2014 wheels. A recent version of pip is needed to install the universal2 macos wheels. *Contributors* A total of 153 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - @DWesl - @Illviljan - @h-vetinari - @yan-wyb + - Aaron Meurer - Abel Aoun + - Adrian Gao + - Ahmet Can Solak + - Ajay DS + - Alban Colley + - Alberto Rubiales + - Alessia Marcolini + - Amit Kumar + - Andrei Batomunkuev + - Andrew Watson + - Anirudh Dagar + - Ankit Dwivedi + - Antony Lee - Arfy Slowy + - Arryan Singh + - Arun Palaniappen + - Arushi Sharma + - Bas van Beek - Brent Brewington + - Carl Johnsen + - Carl Michal + - Charles Harris - Chiara Marmo - Chris Fu (傅立业) + - Christoph Buchner + - Christoph Reiter + - Chunlin Fang - Clément Robert + - Constanza Fierro - Damien Caliste - Daniel Ching - David Badnar + - David Cortes + - David Okpare + - Derek Huang + - Developer-Ecosystem-Engineering + - Dima Pasechnik - Dimitri Papadopoulos + - Dmitriy Fishman + - Eero Vaher + - Elias Koromilas + - Eliaz Bobadilla + - Elisha Hollander + - Eric Wieser - Eskild Eriksen + - Evan Miller + - Fayas Noushad + - Gagandeep Singh + - Ganesh Kathiresan - Ghiles Meddour + - Greg Lucas - Gregory R. Lee - Guo Shuai + - Gwyn Ciesla + - Hameer Abbasi - Hector Martin + - Henry Schreiner + - Himanshu + - Hood Chatham + - Hugo Defois + - Hugo van Kemenade - I-Shen Leong + - Imen Rajhi + - Irina Maria Mocan + - Irit Katriel + - Isuru Fernando - Jakob Jakobson - Jerry Morrison + - Jessi J Zhao + - Joe Marshall + - Johan von Forstner + - Jonas I. Liechti + - Jonathan Reichelt Gjertsen + - Joshua Himmens + - Jérome Eertmans - Jérôme Kieffer + - KIU Shueng Chuan + - Kazuki Sakamoto + - Kenichi Maehashi - Kenny Huynh + - Kent R. Spillner + - Kevin Granados + - Kevin Modzelewski + - Kevin Sheppard - Lalit Musmade + - Malik Idrees Hasan Khan + - Marco Aurelio da Costa + - Margret Pax + - Mars Lee + - Marten van Kerkwijk - Matthew Barber + - Matthew Brett - Matthias Bussonnier - Matthieu Dartiailh - Matti Picus - Melissa Weber Mendonça - Michael McCann + - Mike Jarvis + - Mike McCann + - Mike Toews - Mukulika Pahari - Nick Pope + - Nick Wogan + - Niels Dunnewind + - Niko Savola + - Nikola Forró - Niyas Sait + - Pamphile ROY - Paul Ganssle + - Pauli Virtanen - Pearu Peterson - Peter Hawkins + - Peter Tillema + - Prathmesh Shirsat + - Raghuveer Devulapalli - Ralf Gommers - Robert Kern - Rohit Goswami + - Ronan Lamy - Ross Barnowski - Roy Jacobson + - Samyak S Sarnayak + - Sayantika Banik + - Sayed Adel - Sebastian Berg - Sebastian Schleehauf + - Serge Guelton - Shriraj Hegde + - Shubham Gupta + - Sista Seetaram + - Stefan van der Walt - Stephannie Jimenez Gacha + - Tania Allard - Theodoros Nikolaou + - Thomas Green + - Thomas J. Fan - Thomas Li + - Tim Hoffmann - Tom Tan + - Tyler Reddy - Vijay Arora + - Vinith Kishore + - Warren Weckesser - Yang Hau - Yashasvi Misra - Yuval Ofek + - Zac Hatfield-Dodds - Zhang Na + Cheers, Charles Harris [View Less]

1 0

Proposal to add method for string slicing to np.char
by Joseph Fox-Rabinovitz Jan. 1, 2022

Jan. 1, 2022

I made a PR for another new method `np.char.slice_` here: https://github.com/numpy/numpy/pull/20694 Here is an excerpt of the PR message: There are numerous examples of string slicing being a fairly requested feature: - https://stackoverflow.com/q/70547027/2988730 - https://stackoverflow.com/q/39042214/2988730 - https://stackoverflow.com/q/40976714/2988730 - https://stackoverflow.com/q/64981711/2988730 - https://stackoverflow.com/q/31387047/2988730 - https://stackoverflow.com/q/69856133/… [View More]

1 0