Mailman 3 August 2021 - 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

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

[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

Fwd: ndarray should offer __format__ that can adjust precision
by Ivan Gonzalez Dec. 3, 2021

Dec. 3, 2021

It would be nice to be able to use the Python syntax we already use to format the precision of floating numbers in numpy: >>> a = np.array([-np.pi, np.pi]) >>> print(f"{a:+.2f}") [-3.14 +3.14] This is particularly useful when you have large arrangements. The problem is that if you want to do it today, it is not implemented: >>> print(f"{a:+.2f}") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported format string … [View More]passed to numpy.ndarray.__format__ In this PR (https://github.com/numpy/numpy/pull/19550) I propose a very basic formatting implementation for numeric numbers that uses `array2string` just like it currently does `str` At first, since we are only considering formatting the numeric type, floating numbers specifically, we are only interested in being able to change the precision, the sign, and possibly the rounding or truncation. Since the `array2string` function already does everything we need, we only need to implement the` __format__` function of the `ndarray` class which parses a predefined format (similar to the one already used by Python for built-in data types) to indicate the parameters before said. I propose a mini format specification inspired in the [Format Specification Mini-Language](https://docs.python.org/3/library/string.html#formatspec). ``` format_spec ::= [sign][.precision][type] sign ::= "+" | "-" | " " precision ::= [0-9]+ type ::= "f" | "e" ``` We are going to consider only 3 arguments of the `array2string` function:` precision`, `suppress_small`,` sign`. In particular, the `type` token sets the` suppress_small` argument to True when the type is `f` and False when it is `e`. This is in order to mimic Python's behavior in truncating decimals when using the fixed-point notation. As @brandon-rhodes said in gh-5543, the behavior when you try to format an array containing Python objects, the behavior should be the same as Python has implemented by default in the `object` class: ` format (a, "") ` should be equivalent to `str (a)` and `format(a, "not empty")` should raise an exception. What remains to be defined is the behavior when trying to format an array with a non-numeric data type (`np.numeric`) other than `np.object_`. Should we raise an exception? In my opinion yes, since in the future formatting is extended -- for example, for dates -- people are aware that before that was not implemented. I'm open to suggestions. - Ivan [View Less]

3 2

Newcomer's meeting - later today (4pm UTC)!
by Melissa Mendonça Dec. 1, 2021

Dec. 1, 2021

Hi all! Sorry for the late notice - our next Newcomer's Meeting is today, * July 15, at 4pm UTC.* This is an informal meeting with no agenda to ask questions, get to know other people and (hopefully) figure out ways to contribute to NumPy. Feel free to join if you are lurking around but found it hard to start contributing - we'll do our best to support you. If you wish to join on Zoom, use this link: https://zoom.us/j/6345425936 Hope to see you around! ** You can click this link to get the … [View More]

1 7

Revert the return of a single NaN for `np.unique` with floating point numbers?
by Sebastian Berg Nov. 14, 2021

Nov. 14, 2021

Hi all, In NumPy 1.21, the output of `np.unique` changed in the presence of multiple NaNs. Previously, all NaNs were returned when we now only return one (all NaNs were considered unique): a = np.array([1, 1, np.nan, np.nan, np.nan]) Before 1.21: >>> np.unique(a) array([ 1., nan, nan, nan]) After 1.21: array([ 1., nan]) This change was requested in an old issue: https://github.com/numpy/numpy/issues/2111 And happened here: https://github.com/numpy/… [View More]

4 6

A bite of C++
by Serge Guelton Oct. 8, 2021

Oct. 8, 2021

Hi folks, https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick. Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world. Some changes in distutils were needed to cope with C++-specific flags, and … [View More]

6 9

New CZI grant to support DEI initiatives in the scientific Python ecosystem
by Melissa Mendonça Sept. 2, 2021

Sept. 2, 2021

We are happy to announce the Chan Zuckerberg Initiative has awarded a grant to support the onboarding, inclusion, and retention of people from historically marginalized groups on scientific Python projects, and to structurally improve the community dynamics for NumPy, SciPy, Matplotlib, and Pandas. As a part of CZI’s Essential Open Source Software for Science program [1], this Diversity & Inclusion supplemental grant [2] will support the creation of dedicated Contributor Experience Lead … [View More]

2 1

New Feature added to rotate MeshGrid
by Yash Tewatia Aug. 31, 2021

Aug. 31, 2021

Hi, it is my first contribution to the open-source community, I have tried to fix issue #19315, which is to add a new feature of rotating mesh grid in NumPy. It would be great if I get improvements and suggestions for it. Added functionality of rotating mesh grid which fixes #19315 issue, adds a feature which works as follows Parameters ----------- xspan : Input_array range of values of x in the unrotated matrix. yspan : Input_array range of values of y in the … [View More]

2 1

SeedSequence.spawn()
by Stig Korsnes Aug. 29, 2021

Aug. 29, 2021

Hi, Is there a way to uniquely spawn child seeds? I`m doing monte carlo analysis, where I have n random processes, each with their own generator. All process models instantiate a generator with default_rng(). I.e ss=SeedSequence() cs=ss.Spawn(n), and using cs[i] for process i. Now, the problem I`m facing, is that results using individual process depends on the order of the process initialization ,and the number of processes used. However, if I could spawn children with a unique identifier, I … [View More]

2 11

Announcing PyData/Sparse 0.13.0
by Hameer Abbasi Aug. 28, 2021

Aug. 28, 2021

Hello everyone. I’m happy to announce version 0.13.0 of PyData/Sparse. PyData/Sparse provides sparse arrays for the PyData ecosystem: It mimics the NumPy API but provides sparse storage. Version 0.13.0 was mainly a bugfix-centred release, fixing many bugs and regressions reported by users for versions 0.12.0 and 0.11.0. Python 3.6 was dropped for this release, and version 3.9 support was formally added. Some minor features were also added. Source Code: https://github.com/pydata/sparse/tree/… [View More]

1 0

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg Aug. 25, 2021

Aug. 25, 2021

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, August 25th at 9 am Pacific Time (16:00 UTC). 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

Floating point precision expectations in NumPy
by Sebastian Berg Aug. 19, 2021

Aug. 19, 2021

Hi all, there is a proposal to add some Intel specific fast math routine to NumPy: https://github.com/numpy/numpy/pull/19478 part of numerical algorithms is that there is always a speed vs. precision trade-off, giving a more precise result is slower. So there is a question what the general precision expectation should be in NumPy. And how much is it acceptable to diverge in the precision/speed trade-off depending on CPU/system? I doubt we can formulate very clear rules here, but any … [View More]

5 6

Adding New Feature
by Bhavay Malhotra Aug. 19, 2021

Aug. 19, 2021

Dear Team, I’m thinking of adding a new feature in response to the issue no. #19039. The feature is basically a function to check whether the data type of both the numpy arrays are same or not. If the numpy arrays have different data types function return a False else it returns a True. Please consider my feature and reply appropriately so that I can send my PR accordingly. Waiting to see a prompt reply. Thanking You. Regards, Bhavay

2 1

[JOB] modeling engineer at Form Energy
by Dr. Mark Alexander Mikofski PhD Aug. 18, 2021

Aug. 18, 2021

https://jobs.lever.co/formenergy/672c9b68-fc0e-46ff-b430-7a65e829ab8a Role Description We are looking for a Staff Modeling Engineer to join our systems team to build energy storage system performance models which will be used as the basis for designing our multi-day storage product. The Staff Modeling Engineer will be responsible for engaging with the battery team, the systems team, and the market analytics team to develop modeling tools which capture the electrochemical performance of our … [View More]

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg Aug. 18, 2021

Aug. 18, 2021

Hi all, There will be a NumPy Community meeting Wednesday August 18th at 20: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

OS X universal2 wheels
by Charles R Harris Aug. 16, 2021

Aug. 16, 2021

Hi All, I note that the numpy universal wheels for Mac are marked "10_9" whereas the wheels for Arm64 are marked '11_0'. Does that need to be fixed? Chuck

2 1

NumPy 1.21.2 released
by Charles R Harris Aug. 15, 2021

Aug. 15, 2021

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.21.2. NumPy 1.21.2 is a maintenance release that fixes bugs discovered after 1.21.1. It also provides 64 bit manylinux Python 3.10.0rc1 wheels for downstream testing. Note that Python 3.10 is not yet final. There is also preliminary support for Windows on ARM64 builds, but there is no OpenBLAS for that platform and no wheels are available. The Python versions supported for this release are 3.7-3.9. The 1.21.2 … [View More]release is compatible with Python 3.10.0rc1 and Python 3.10 will be officially supported after it is released. The previous problems with gcc-11.1 have been fixed by gcc-11.2, check your version if you are using gcc-11. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.21.2/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.21.2>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 10 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Bas van Beek - Carl Johnsen + - Charles Harris - Gwyn Ciesla + - Matthieu Dartiailh - Matti Picus - Niyas Sait + - Ralf Gommers - Sayed Adel - Sebastian Berg *Pull requests merged* A total of 18 pull requests were merged for this release. - #19497: MAINT: set Python version for 1.21.x to ``<3.11`` - #19533: BUG: Fix an issue wherein importing ``numpy.typing`` could raise - #19646: MAINT: Update Cython version for Python 3.10. - #19648: TST: Bump the python 3.10 test version from beta4 to rc1 - #19651: TST: avoid distutils.sysconfig in runtests.py - #19652: MAINT: add missing dunder method to nditer type hints - #19656: BLD, SIMD: Fix testing extra checks when ``-Werror`` isn't applicable... - #19657: BUG: Remove logical object ufuncs with bool output - #19658: MAINT: Include .coveragerc in source distributions to support... - #19659: BUG: Fix bad write in masked iterator output copy paths - #19660: ENH: Add support for windows on arm targets - #19661: BUG: add base to templated arguments for platlib - #19662: BUG,DEP: Non-default UFunc signature/dtype usage should be deprecated - #19666: MAINT: Add Python 3.10 to supported versions. - #19668: TST,BUG: Sanitize path-separators when running ``runtest.py`` - #19671: BLD: load extra flags when checking for libflame - #19676: BLD: update circleCI docker image - #19677: REL: Prepare for 1.21.2 release. Cheers Charles Harris [View Less]

1 0

Drop LGTM testing.
by Charles R Harris Aug. 14, 2021

Aug. 14, 2021

Hi All, LGTM on github uses Python 3.7, which causes a problem if we drop 3.7 support. LGTM is nice for pointing to possible code improvements, but we mostly ignore it anyway. There are probably standalone code analysers that would serve our needs as well, so dropping it seems the easiest way forward. Thoughts? Chuck

3 4

Idea: Simplify passing of shared memory info for ndarrays
by Randall Pittman Aug. 13, 2021

Aug. 13, 2021

Hi! First time poster to the list, long time happy user of NumPy (thank you, devs!!) I created a bit of a wrapper for using `ndarray` with Py 3.8+ `multiprocessing.shared_memory`. I really like the ability to use `SharedMemory` with `ndarray` via the `buffer` arg. (as in https://docs.python.org/3/library/multiprocessing.shared_memory.html#multip…) However, it seemed a bit clunky to worry about passing the SharedMemory object or name, dtype, and shape to reconstruct the `ndarray` in other … [View More]

1 0

Dropping Python 3.7 for NumPy 1.22
by Charles R Harris Aug. 13, 2021

Aug. 13, 2021

Hi All, This is to propose dropping Python 3.7 for NumPy 1.22. Doing so will allow merging the array API standard <https://github.com/numpy/numpy/pull/18585> (keyword only arguments), simplify removing import time compiles <https://github.com/numpy/numpy/pull/19638>, allow making 64 bit pickles the default, and bring annotations closer to current. NEP 29 <https://numpy.org/neps/nep-0029-deprecation_policy.html> suggests Dec 26, 2021 for the drop date, which is close to the … [View More]

2 1

Matti Picus and Sebastian Berg added to org-admin
by Charles R Harris Aug. 12, 2021

Aug. 12, 2021

Hi All, Matti Picus and Sebastian Berg have been added to the org-admin team on github. That will allow them to help maintain the github site going forward. Chuck

1 0