Mailman 3 September 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 do I avoid these messages to appear? I know that I could in principle use numpy.seterr. However, I do NOT want to remove these warnings for other potential divide/multiply/sqrt etc errors. Only when I am using a "where", to in fact avoid such warnings! Note that the warnings only happen once, but since I am going to release that code, I would like to avoid the user to get such messages which are irrelevant here (because I am testing, with the where, when NOT to divide by zero or take a sqrt of a negative number). thanks! Eric

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 can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentati… - Melissa

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 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

12 28

[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. np.expand_dims -> tf.expand_dims. This is done either in debugging (e.g. converting tf to np without eager execution to debug portion of the code), or during prototyping, e.g. develop in numpy and convert in tf. I find myself more than at one occasion to getting syntax errors because of this particular function np.concatenate. It is unnecessarily long. I imagine there are more people that also run into the same problems. Pandas uses concat (torch on the other extreme uses simply cat, which I don't think is as descriptive).

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 think it's worth doing something about. It could contain malicious code for all we know. Cheers, Ralf

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 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

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 correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Newcomer%27… <https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Newcomer%27…> *** You can add the NumPy community calendar to your google calendar by clicking this link: https://calendar.google.com/calendar /r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 - Melissa

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/numpy/pull/18070 While, it has a release note. I am not sure the change got the attention it deserved. This would be especially worrying if it is a regression for anyone? Cheers, Sebastian PS: One additional note, is that this does not work for object arrays (it cannot reasonable): >>> np.unique(a.astype(object)) array([1.0, nan, nan, nan], dtype=object)

4 6

spam on the mailing lists
by Andras Deak Oct. 18, 2021

Oct. 18, 2021

Hi All, Today both of the python.org mailing lists I'm subscribed to (numpy and scipy-dev) got the same kind of link shortener spam. I assume all the mailing lists started getting these, and that these won't go away for a while. Is there any way to prevent these, short of moderating emails from new list members? Assuming the engine even supports that. There aren't many emails, especially from new members, and I can't think of other ways that ensure no false positives in filtering. Since maintainer time is precious, I can volunteer to moderate such emails if needed. Cheers, András

18 39

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg Oct. 14, 2021

Oct. 14, 2021

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, September 8th 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

4 3

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 extensions that consist in mixed C and C++ code. I've kept the change as minimal as possible to ease the (potential) transition and keep the C++ code close to the C code. This led to less idiomatic C++ code, but I value a "correct first" approach. There's an on-going effort by seiko2plus to remove that C layer, I acknowledge this would bring even more C++ code, but that looks orthogonal to me (and a very good second step!) All lights are green for the PR, let's assume it's a solid ground for discussion :-) So, well, what do you think? Should we go forward? Potential follow-ups : - do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep? - what about -fno-exception, -fno-rtti? - coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)

6 9

Moving community meeting to 16:00 UTC
by Sebastian Berg Oct. 7, 2021

Oct. 7, 2021

Hi all, Melissa brought up that we should reschedule the bi-weekly community meeting to the same time slot at the triage meeting: Wednesdays 16:00 UTC (9 am Pacific time) [1] This will simplify attending for those in Europe and allow a more reasonable time including for India. As of now, all regular attendees are happy with this move. But the original idea was that we could also alternate between two times, the current time is e.g. impossible to make from east Asia. Please let me/us know if you prefer a different schedule now (or later!). The idea is that these meetings are accessible to anyone interested. Without any comments, I will announce and change the calendar starting with next weeks meeting. Cheers, Sebastian [1] I have to see whether we will stick with UTC or do any daylight savings.

5 6

ENH: Extended choose -- add an implementation of the choose function which supports more than 32 choices
by Aaron Watters Oct. 7, 2021

Oct. 7, 2021

Hi folks! The np.choose function raises a ValueError if called with more than 31 choices. This PR adds an alternate implementation np.extended_choose (which uses the base implementation) that supports any number of choices. https://github.com/numpy/numpy/pull/20001 FYI, I needed this functionality for a mouse embryo microscopy tool I'm building. I'm attempting to contribute it because I thought it might be generally useful. All comments, complaints, or suggestions or code reviews appreciated. thanks! -- Aaron Watters

3 2

Running numpy.test() after pip install
by Bennet Fauber Sept. 29, 2021

Sept. 29, 2021

I just installed NumPy using pip and Python 3.9.7 on CentOS 7.9. Installation went fine, but when I ran >>> import numpy >>> numpy.test() I got a traceback, and this summary. =========================== short test summary info ============================ ERROR - ModuleNotFoundError: No module named 'hypothesis' !!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!! It seems that both hypothesis and pytest are needed to run numpy.test(). We like to be able to run all the tests even after a pip install, and being able to run some of the tests from pip-installed numpy is useful as well. May I suggest you add those two packages as dependencies for NumPy at PyPi? Neither are particularly large, both are generally useful, and I think the potential utility for those who would ike to check on their own system for anomalies outweighs the minimal impact on the majority of users who would not use it but would also probably not notice their presence. If adding them as dependencies seems to heavy weight, or is otherwised deemed undesirable, perhaps just a note in the Project Description at https://pypi.org/project/numpy/ to say that, if you want to run tests, those two packages will be needed? Thanks, -- bennet

5 6

ANN: SfePy 2021.3
by Robert Cimrman Sept. 29, 2021

Sept. 29, 2021

I am pleased to announce the release of SfePy 2021.3. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by finite element methods. It is distributed under the new BSD license. Home page: https://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------- - unified volume and surface integration terms - improved pyvista-based visualization script For full release notes see [1]. Cheers, Robert Cimrman [1] http://docs.sfepy.org/doc/release_notes.html#id1 --- Contributors to this release in alphabetical order: Robert Cimrman Hugo Levy Vladimir Lukes

1 0

NumPy Community Meeting Wednesday (earlier @16:30 UTC!)
by Sebastian Berg Sept. 28, 2021

Sept. 28, 2021

Hi all, There will be a NumPy Community meeting Wednesday September 29th at 16:30 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 NOTE: The time is different from previous meetings which had started at 18:00 UTC.

1 0

np.trunc is inconsistent with array-api
by Kshitij Kalambarkar Sept. 28, 2021

Sept. 28, 2021

Hi, np.trunc returns floating dtype output even for integral dtype input. As per array-api, it should preserve the input dtype. Note: This is also true for np.rint, np.fix, np.ceil, np.floor Reference: https://github.com/numpy/numpy/issues/19464 Possible Fix: 1. We update the behaviour directly with an update to release note. 2. We add a FutureWarning and update the behaviour in a future release. This email is to gauge the preference for the fix. Thank You! Regards, Kshiteej K

5 6

Re: moving the time of community meetings
by Inessa Pawson Sept. 28, 2021

Sept. 28, 2021

> > I have to see whether we will stick with UTC or do any daylight > savings. I suggest to continue using UTC to avoid confusion over daylight saving/summer time changes. On Thu, Sep 23, 2021 at 12:00 PM <numpy-discussion-request(a)python.org> wrote: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)python.org > > You can reach the person managing the list at > numpy-discussion-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..."Today's Topics: > > 1. Moving community meeting to 16:00 UTC (Sebastian Berg) > 2. Re: Moving community meeting to 16:00 UTC (Ralf Gommers) > 3. Newcomer's meeting: September 23, 8PM UTC (Melissa Mendonça) > > > > ---------- Forwarded message ---------- > From: Sebastian Berg <sebastian(a)sipsolutions.net> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Wed, 22 Sep 2021 13:31:06 -0500 > Subject: [Numpy-discussion] Moving community meeting to 16:00 UTC > Hi all, > > Melissa brought up that we should reschedule the bi-weekly community > meeting to the same time slot at the triage meeting: > > Wednesdays 16:00 UTC (9 am Pacific time) [1] > > This will simplify attending for those in Europe and allow a more > reasonable time including for India. > > As of now, all regular attendees are happy with this move. But the > original idea was that we could also alternate between two times, the > current time is e.g. impossible to make from east Asia. > > Please let me/us know if you prefer a different schedule now (or > later!). The idea is that these meetings are accessible to anyone > interested. > Without any comments, I will announce and change the calendar starting > with next weeks meeting. > > Cheers, > > Sebastian > > > > [1] I have to see whether we will stick with UTC or do any daylight > savings. > > > > ---------- Forwarded message ---------- > From: Ralf Gommers <ralf.gommers(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Wed, 22 Sep 2021 21:11:45 +0200 > Subject: [Numpy-discussion] Re: Moving community meeting to 16:00 UTC > > > On Wed, Sep 22, 2021 at 8:31 PM Sebastian Berg <sebastian(a)sipsolutions.net> > wrote: > >> Hi all, >> >> Melissa brought up that we should reschedule the bi-weekly community >> meeting to the same time slot at the triage meeting: >> >> Wednesdays 16:00 UTC (9 am Pacific time) [1] >> >> This will simplify attending for those in Europe and allow a more >> reasonable time including for India. >> >> As of now, all regular attendees are happy with this move. > > > I have a structural conflict at that time, I'd only be able to make the > second half of the meeting. > > Perhaps we could make it 16:30 UTC (= 10pm in India), or otherwise 15:00 > or 16:00 UTC on Tuesdays? > > But the original idea was that we could also alternate between two times, >> the >> current time is e.g. impossible to make from east Asia. >> > > Yes, the current time is very late and was only chosen to make it 6am in > Australia (which is no longer needed) - we should move it forward even if > we end up alternating between two times. > > Cheers, > Ralf > > > >> Please let me/us know if you prefer a different schedule now (or >> later!). The idea is that these meetings are accessible to anyone >> interested. >> Without any comments, I will announce and change the calendar starting >> with next weeks meeting. >> >> Cheers, >> >> Sebastian >> >> >> >> [1] I have to see whether we will stick with UTC or do any daylight >> savings. >> _______________________________________________ >> NumPy-Discussion mailing list -- numpy-discussion(a)python.org >> To unsubscribe send an email to numpy-discussion-leave(a)python.org >> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ >> Member address: ralf.gommers(a)googlemail.com >> > > > > ---------- Forwarded message ---------- > From: "Melissa Mendonça" <melissawm(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Wed, 22 Sep 2021 16:24:50 -0300 > Subject: [Numpy-discussion] Newcomer's meeting: September 23, 8PM UTC > Hi all! > > Our next Newcomer's Meeting is on Thursday, > *September 23, at 8pm 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 correct time at your timezone: > https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Newcomers%2… > > *** You can add the NumPy community calendar to your google calendar by > clicking this link: https://calendar.google.com/calendar > /r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 > > - Melissa > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion(a)python.org > To unsubscribe send an email to numpy-discussion-leave(a)python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > -- Every good wish, *Inessa Pawson* Executive Director Albus Code inessa(a)albuscode.org

2 1

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg Sept. 22, 2021

Sept. 22, 2021

Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, September 22nd 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

new searchable mailing list archives
by Ralf Gommers Sept. 21, 2021

Sept. 21, 2021

Hi all, Thanks to the friendly folks who maintain the python.org mailing lists, we now have nice searchable mailing list archives for NumPy and SciPy: https://mail.python.org/archives/list/numpy-discussion@python.org/ https://mail.python.org/archives/list/scipy-dev@python.org/ https://mail.python.org/archives/list/scipy-user@python.org/ Cheers, Ralf

1 0

[academic study] how do OSS developers respond to such phenomena as partially or wrongly implemented functionality?
by nicole novielli Sept. 20, 2021

Sept. 20, 2021

Hello, We're a team of Software Engineering researchers investigating technical debt. Technical debt refers to "not quite right code which we postpone making it right” (Cunningham) and this may often introduce a cost. More specifically, the aim of this study is to gather information on how open source developers respond to specific source code phenomena such as partially or wrongly implemented functionality. With the results of this study we aim to create a better understanding of how developers annotate issues in source code. These results will be used to support prioritisation of maintenance activities in software systems. The survey data will be collected, analyzed and stored so that research questions can be answered and the results can be published. Since the survey is anonymous, no personal information is collected. For the same reason we cannot modify or remove answers upon request. If you contribute code to this project you can help us out by filling out the following survey: https://forms.office.com/r/xRg92faiNd. The survey should take you at most 15 minutes. Thanks in advance, Nicole Novielli (University of Bari, Italy) also on behalf of Nathan Cassee, Massimiliano Di Penta, Alexander Serebrenik, and Fiorella Zampetti

1 0

deprecating float(x) for ndim > 0
by Nico Schlömer Sept. 17, 2021

Sept. 17, 2021

Hi everyone, This is seeking input on PR [1] which I've worked on with @eric-wieser and @seberg. It deprecates ``` float(x) ``` if `x` is an array of ndim > 0. (It works with all arrays of size 1 right now.) This aligns the behavior of float() on ndarrays with float() on lists which already fails today. It also deprecates the implicit conversion to float in assignment expressions like ``` a = np.array([1, 2, 3]) a[0] = [5] # deprecated, should be a[0] = 5 ``` In general, the PR makes numpy a tad bit stricter on how it treats scalars vs. single-item arrays. The change also prevents the #1 wrong usage of float(), namely for extracting the scalar value from an array. One should rather use `x[0]` or `x.item()` to that which doesn't convert the value to a Python float. To estimate the impact of the PR, I looked at major numpy dependents like matplotlib, scipy, pandas etc., and of course numpy itself. Except scipy, all projects were virtually clean to start with. Scipy needed some changes for all tests to pass without warning, and all of the changes were improvements. In particular, the deprecation motivates users to use actual scalars when scalars are needed, e.g., in the case of scipy, as the return value of a goal functional. It'd be great if you could try the branch against your own project and let us know (here or in the PR) about and problems that you might have. Thanks! Nico [1] https://github.com/numpy/numpy/pull/10615 [2] https://github.com/numpy/numpy/issues/10404

5 6

npreadtext: `numpy.loadtxt` in C
by Ross Barnowski Sept. 16, 2021

Sept. 16, 2021

Hi all, This is to announce [`npreadtext`](https://github.com/BIDS-numpy/npreadtext), a drop-in replacement for `numpy.loadtxt` written in C for improved performance. We are now at feature parity with `loadtxt`, and would greatly appreciate your feedback & testing. We hope eventually to include `npreadtext` in NumPy itself. ## Installation `npreadtext` has been tested with NumPy v1.18 and higher and can be installed using: ``` python -m pip install numpy python -m pip install git+git://github.com/BIDS-numpy/npreadtext ``` To enable the C-accelerated version of `np.loadtxt`, monkey-patch NumPy: ```python >>> import numpy as np >>> from npreadtxt import monkeypatch_numpy ``` This replaces `np.loadtxt` with `npreadtext._loadtxt`. ## Feedback You may leave comments here or file issues on the [project issue tracker]( https://github.com/BIDS-numpy/npreadtext/issues). Please also share text files that strain or break the reader. ## Benchmarks Preliminary benchmarks show a significant improvement in performance: ``` python runtests.py --bench-compare monkeypatch-npreadtext bench_io npreadtext np.loadtxt speedup function + 7.74±0.04ms 146±0.8ms 18.85 bench_io.LoadtxtCSVStructured.time_loadtxt_csv_struct_dtype + 9.67±0.1ms 181±0.6ms 18.67 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 100000) + 969±10μs 17.9±0.1ms 18.48 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 10000) + 950±7μs 14.6±0.04ms 15.39 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 10000) + 9.65±0.03ms 146±0.2ms 15.13 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 100000) + 11.8±0.06ms 141±0.3ms 11.96 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 100000) + 11.9±0.1ms 141±0.3ms 11.88 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 100000) + 12.6±0.1ms 150±0.6ms 11.85 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 100000) + 1.18±0.01ms 13.9±0.1ms 11.74 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 10000) + 1.19±0.01ms 13.9±0.09ms 11.68 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 10000) + 1.27±0ms 14.7±0.06ms 11.64 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 10000) + 12.4±0.06ms 140±0.6ms 11.28 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(100000) + 1.22±0.02ms 13.8±0.09ms 11.26 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(10000) + 20.8±0.2μs 194±0.5μs 9.32 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 100) + 20.4±0.2μs 162±0.3μs 7.97 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 100) + 1.04±0ms 8.17±0.08ms 7.84 bench_io.LoadtxtUseColsCSV.time_loadtxt_usecols_csv([1, 3, 5, 7]) + 884±2μs 6.79±0.02ms 7.68 bench_io.LoadtxtUseColsCSV.time_loadtxt_usecols_csv([1, 3]) + 1.56±0.01ms 12.0±0.05ms 7.68 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 10000) + 16.1±0.05ms 122±0.3ms 7.56 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 100000) + 23.4±0.04μs 163±0.9μs 6.94 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 100) + 22.6±0.09μs 153±0.2μs 6.76 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 100) + 22.9±0.5μs 154±0.7μs 6.72 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 100) + 22.8±0.5μs 150±0.8μs 6.58 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(100) + 809±8μs 5.10±0.02ms 6.30 bench_io.LoadtxtUseColsCSV.time_loadtxt_usecols_csv(2) + 7.31±0.01ms 42.0±0.08ms 5.75 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(20000) + 748±2μs 4.11±0.04ms 5.50 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(2000) + 26.0±0.2μs 131±0.3μs 5.02 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 100) + 87.3±0.4μs 436±1μs 5.00 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(200) + 2.09±0.01ms 10.1±0.04ms 4.86 bench_io.LoadtxtReadUint64Integers.time_read_uint64(10000) + 2.09±0ms 10.1±0.04ms 4.83 bench_io.LoadtxtReadUint64Integers.time_read_uint64_neg_values(10000) + 215±0.5μs 1.03±0ms 4.82 bench_io.LoadtxtReadUint64Integers.time_read_uint64_neg_values(1000) + 217±0.9μs 1.02±0ms 4.72 bench_io.LoadtxtReadUint64Integers.time_read_uint64(1000) + 123±0.6μs 580±3μs 4.71 bench_io.LoadtxtReadUint64Integers.time_read_uint64_neg_values(550) + 124±0.8μs 573±4μs 4.63 bench_io.LoadtxtReadUint64Integers.time_read_uint64(550) + 4.15±0.01ms 14.4±0.05ms 3.46 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 10000) + 58.6±0.1ms 195±0.8ms 3.33 bench_io.LoadtxtCSVSkipRows.time_skiprows_csv(10000) + 41.8±0.1ms 139±1ms 3.33 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 100000) + 64.6±0.09ms 215±1ms 3.32 bench_io.LoadtxtCSVSkipRows.time_skiprows_csv(500) + 64.9±0.2ms 215±2ms 3.30 bench_io.LoadtxtCSVSkipRows.time_skiprows_csv(0) + 55.0±0.5μs 154±0.4μs 2.81 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 100) + 23.9±0.1μs 60.1±1μs 2.51 bench_io.LoadtxtCSVDateTime.time_loadtxt_csv_datetime(20) + 12.1±0.2μs 29.4±0.2μs 2.44 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int64', 10) + 12.0±0.05μs 26.2±0.2μs 2.18 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('int32', 10) + 12.5±0.08μs 26.1±0.09μs 2.08 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('complex128', 10) + 12.3±0.04μs 24.9±0.4μs 2.02 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float64', 10) + 12.3±0.1μs 24.8±0.2μs 2.02 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('float32', 10) + 12.2±0.04μs 24.5±0.1μs 2.01 bench_io.LoadtxtCSVComments.time_comment_loadtxt_csv(10) + 13.3±0.1μs 23.4±0.1μs 1.76 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('object', 10) + 18.5±0.3μs 25.6±0.5μs 1.39 bench_io.LoadtxtCSVdtypes.time_loadtxt_dtypes_csv('str', 10) ``` The repository includes [procedures for running benchmarks locally]( https://github.com/BIDS-numpy/npreadtext#benchmarking).

1 0

Re: [Numpy-discussion] deprecating float(x) for ndim > 0
by george trojan Sept. 16, 2021

Sept. 16, 2021

Responding to the post by nico.schloemer(a)gmail.com (I subscribe to the digest). I just wrote the following code: twb = scipy.optimize.fsolve(phi, tdb, args=(tdb, p, w, hd_tdb, hg_tdb), xtol=1e-8) tdb, p, w, hd_tdb, hg_tdb twb.shape print("wet-bulb temperature {:.5f} [deg K]".format(float(twb))) The output is (313.15, 101325.0, 0.009200033532084696, 40182.343155896095, 2573510.322137241) (1,) wet-bulb temperature 295.17583 [deg K] All arguments are floats, the function phi returns float as well. I did expect the output to be float. Instead I got a 1d array. Were my expectations wrong? The print statement would stop working after deprecation. George

4 3

Re: [Numpy-discussion] deprecating float(x) for ndim > 0
by george trojan Sept. 16, 2021

Sept. 16, 2021

To Andrew Nelson: > In the return section for fsolve the documentation states that the return > value, `x`, is an `ndarray`. True, my bad. There is another issue with `fsolve`: it implicitly changes the argument passed to `func`. Consider def func(x): # x = float(x) if not np.isscalar(x) and x.shape != (): raise ValueError('The argument must be a number or a 0-d array') return x - 1 fsolve(func, np.array(2.0)) ---------------------------------------------------------------------------ValueError Traceback (most recent call last)/tmp/ipykernel_1017360/2091764495.py in <module> 5 return x - 1 6 ----> 7 fsolve(func, np.array(2.0)) . . . ValueError: The argument must be a number or a 0-d array I had the commented out line in my code (in real life I am calling a library function that accepts only numeric types, not arrays). Changing this to line to x = x.item() makes sense. The documentation states that `func` takes at least one (possibly vector) argument. It must take a vector.

1 0

Re: [Numpy-discussion] graphic design contribution to NumPy
by Inessa Pawson Sept. 15, 2021

Sept. 15, 2021

Hi, Vasiliy! It would be great if the infographic embraces the flat design principles and echoes the style of other graphic elements of the website. Let’s continue this conversation on GitHub, in the comments for the issue #435 <https://github.com/numpy/numpy.org/issues/435>. On Tue, Sep 14, 2021 at 12:00 PM <numpy-discussion-request(a)python.org> wrote: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/numpy-discussion > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)python.org > > You can reach the person managing the list at > numpy-discussion-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..." > Today's Topics: > > 1. graphic design contribution (Holam Gadol) > > > > ---------- Forwarded message ---------- > From: Holam Gadol <holamgadol(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Mon, 13 Sep 2021 23:11:07 +0300 > Subject: [Numpy-discussion] graphic design contribution > Thank you for replying, Inessa. > > Refining infographics from the issue #435 > <https://github.com/numpy/numpy.org/issues/435> looks interesting. > > Do you have a particular style for them? I saw the icons were redrawn in > material design. Should infographics follow the same style? > > Best wishes, > Vasiliy > > > пн, 13 сент. 2021 г. в 06:11, Inessa Pawson <albuscode(a)gmail.com>: > >> Thank you for offering your help, Holam! >> We have quite a few options for you. If you’d like to help us improve >> numpy.org, this is the latest discussion on this topic: >> https://github.com/numpy/numpy.org/issues/342 . We could also apply your >> graphic design skills to enhance our documentation and educational >> materials. >> Let me know what you’d like to take on, and I will send you more info >> about it. >> >> On Sat, Sep 11, 2021 at 12:04 PM <numpy-discussion-request(a)python.org> >> wrote: >> >>> Send NumPy-Discussion mailing list submissions to >>> numpy-discussion(a)python.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> or, via email, send a message with subject or body 'help' to >>> numpy-discussion-request(a)python.org >>> >>> You can reach the person managing the list at >>> numpy-discussion-owner(a)python.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of NumPy-Discussion digest..." >>> Today's Topics: >>> >>> 1. graphic design contribution (Holam Gadol) >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Holam Gadol <holamgadol(a)gmail.com> >>> To: numpy-discussion(a)python.org >>> Cc: >>> Bcc: >>> Date: Sat, 11 Sep 2021 16:05:43 +0300 >>> Subject: [Numpy-discussion] graphic design contribution >>> Greetings to everyone! >>> >>> I`de like to help the numpy project with graphic design. >>> >>> What are the first steps to start with? >>> >>> There are issues about documentation and code on github, but how about >>> graphics? >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion(a)python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> >> >> >> -- >> Every good wish, >> *Inessa Pawson* >> Executive Director >> Albus Code >> inessa(a)albuscode.org >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion(a)python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion(a)python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- Every good wish, *Inessa Pawson* Executive Director Albus Code inessa(a)albuscode.org

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg Sept. 14, 2021

Sept. 14, 2021

Hi all, There will be a NumPy Community meeting Wednesday September 15th 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

Re: [Numpy-discussion] NumPy-Discussion Digest, Vol 180, Issue 9
by Inessa Pawson Sept. 13, 2021

Sept. 13, 2021

Thank you for offering your help, Holam! We have quite a few options for you. If you’d like to help us improve numpy.org, this is the latest discussion on this topic: https://github.com/numpy/numpy.org/issues/342 . We could also apply your graphic design skills to enhance our documentation and educational materials. Let me know what you’d like to take on, and I will send you more info about it. On Sat, Sep 11, 2021 at 12:04 PM <numpy-discussion-request(a)python.org> wrote: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/numpy-discussion > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)python.org > > You can reach the person managing the list at > numpy-discussion-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..." > Today's Topics: > > 1. graphic design contribution (Holam Gadol) > > > > ---------- Forwarded message ---------- > From: Holam Gadol <holamgadol(a)gmail.com> > To: numpy-discussion(a)python.org > Cc: > Bcc: > Date: Sat, 11 Sep 2021 16:05:43 +0300 > Subject: [Numpy-discussion] graphic design contribution > Greetings to everyone! > > I`de like to help the numpy project with graphic design. > > What are the first steps to start with? > > There are issues about documentation and code on github, but how about > graphics? > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion(a)python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- Every good wish, *Inessa Pawson* Executive Director Albus Code inessa(a)albuscode.org

2 1

graphic design contribution
by Holam Gadol Sept. 11, 2021

Sept. 11, 2021

Greetings to everyone! I`de like to help the numpy project with graphic design. What are the first steps to start with? There are issues about documentation and code on github, but how about graphics?

1 0

Help Regarding Debugging Cython Code
by Amardeep Singh Sept. 5, 2021

Sept. 5, 2021

Hi Team If some one has setup to debug cython code can you please share the details. I am using ubuntu 20.4 . Not sure why gdb not picking up breakpoints. I am able to debug c extensions but not cython code. Thx

2 1

ANN: pvlib-0.9.0 released
by Dr. Mark Alexander Mikofski PhD Sept. 3, 2021

Sept. 3, 2021

Dear Pythonistas and solar power enthusiasts, On behalf of the maintainers, we're happy to announce a new release of pvlib python: software for simulating performance of photovoltaic solar energy systems. *See what's new for v0.9.0:* * https://pvlib-python.readthedocs.io/en/stable/whatsnew.html *Releases are available from PyPI and the conda-forge channel:* * https://pypi.org/project/pvlib/ * https://anaconda.org/conda-forge/pvlib-python *Read the Documentation:* * https://pvlib-python.readthedocs.io/en/stable/index.html *Report issues & contribute:* * https://github.com/pvlib/pvlib-python *Highlights:* * There are some breaking changes <https://pvlib-python.readthedocs.io/en/stable/whatsnew.html#breaking-changes>, so please read the Release Notes carefully before updating. * pvlib now has a new Array class <https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.pvsystem.Arra…> that represents groups of identical modules that are part of a PVSystem but have the same orientation and mounting type. * The PVSystem class <https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.pvsystem.PVSy…> can now model a combination of arrays each with different orientations, modules, and mounting types. * pvlib completed a very successful GSoC <https://summerofcode.withgoogle.com/>, which added several new iotools like get_bsrn() <https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.iotools.get_b…> , get_pvgis_hourly() <https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.iotools.read_…> , get_cams() <https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.iotools.get_c…>, and more. Special thanks to Adam R. Jensen <https://predictablysunny.com/>, Kevin Anderson, and many reviewers who helped! * Many bug fixes <https://pvlib-python.readthedocs.io/en/stable/whatsnew.html#bug-fixes> including a fix to Perez <https://github.com/pvlib/pvlib-python/issues/1238> contributed by Clean Power Research. Read their blog <https://www.solaranywhere.com/2021/pvlib-models-via-solaranywhere-joins-pvl…> to learn more about how they're contributing to pvlib. Thanks! *The maintainers thank you for using pvlib python!* -- Mark Mikofski, PhD (2005) *Fiat Lux*

1 0

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 positions to identify, document, and implement practices to foster inclusive open-source communities. This project will be led by Melissa Mendonça (NumPy), with additional mentorship and guidance provided by Ralf Gommers (NumPy, SciPy), Hannah Aizenman and Thomas Caswell (Matplotlib), Matt Haberland (SciPy), and Joris Van den Bossche (Pandas). This is an ambitious project aiming to discover and implement activities that should structurally improve the community dynamics of our projects. By establishing these new cross-project roles, we hope to introduce a new collaboration model to the Scientific Python communities, allowing community-building work within the ecosystem to be done more efficiently and with greater outcomes. We also expect to develop a clearer picture of what works and what doesn’t in our projects to engage and retain new contributors, especially from historically underrepresented groups. Finally, we plan on producing detailed reports on the actions executed, explaining how they have impacted our projects in terms of representation and interaction with our communities. The two-year project is expected to start by November 2021, and we are excited to see the results from this work! You can read the full proposal in figshare [3] and see this announcement at the NumPy site [4]. Cheers! - Melissa [1] https://chanzuckerberg.com/eoss/ [2] https://cziscience.medium.com/advancing-diversity-and-inclusion-in-scientif… [3] https://figshare.com/articles/online_resource/Advancing_an_inclusive_cultur… [4] https://numpy.org/news/#advancing-an-inclusive-culture-in-the-scientific-py…

2 1

no community meeting today
by Ralf Gommers Sept. 1, 2021

Sept. 1, 2021

Hi all, Just a heads up that there's no community meeting later today. For next time, please feel free to add topics to https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both. Cheers, Ralf

1 0