Mailman 3 December 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. 3, 2022

Dec. 3, 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

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 10, 2022

May 10, 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

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

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

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