There will be a NumPy Community meeting Wednesday May 13th at 1pm
Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in
and edit the work-in-progress meeting topics and notes:
it has come up in the last community call that many of our committee
membership lists have not been updated in a while.
This is not a big issue as such. But, while these committees are not
very active on a day-to-day basis, they are an important part of the
community and it is better to update them regularly and thus also
ensure they remain representative of the community.
We would like to start by updating the members of the Code of Conduct
(CoC) committee. The CoC committee is in charge of responding and
following up to any reports of CoC breaches, as stated in:
If you are interested in or happy to serve on our CoC committee please
let me or e.g. Ralf Gommers know, join the next community meeting
(April 29th, 11:00PDT/18:00UTC), or reply on the list.
I hope we will be able to discuss and reach a consensus between those
interested and involved quickly (possibly already on the next community
call). In either case, before any changes they will be run by the
mailing list to ensure community consensus.
Over in numpy-stubs we've been working on typing "array like":
It would be nice if the type were public so that downstream projects
could use it (e.g. it would be very helpful in SciPy). Originally the
plan was to only make it publicly available at typing time and not
runtime, which would mean that no changes to NumPy are necessary; see
for more information on how that works.
But, Stephan pointed out that it might be confusing to users for
objects to only exist at typing time, so we came around to the
question of whether people are open to the idea of including the type
aliases in NumPy itself. Ralf's concrete proposal was to make a module
numpy.types (or maybe numpy.typing) to hold the aliases so that they
don't pollute the top-level namespace. The module would initially
contain the types
- (maybe) ShapeLike
Note that we would not need to make changes to NumPy right away;
instead it would probably be done when numpy-stubs is merged into
What do people think?
There has been a discussion about divmod (1.0, 0.0) bug here :
Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan, nan).
This is not consistent with IEEE 754
<https://en.wikipedia.org/wiki/IEEE_754> standard which says that 1.0/0.0
divisions should return inf and raise dividebyzero error. Although this may
not apply to divmod, it should apply to floor_divide and mod.
I have summarized in the table below, summarizing current state and
Operator Warning message Expected warning Result Expected Result
np.divmod Invalid error invalid and dividebyzero ?? nan, nan inf, nan
np.fmod(1.0, 0.0) Invalid error Invalid nan nan
np.floor_divide(1.0, 0.0) Invalid error Dividebyzero nan inf
np.remainder(1.0, 0.0) Invalid error Invalid nan nan
For remainder and fmod above, according to the standard, it is supposed to
raise invalid error. We need to change the code to also raise dividebyzero
error for floor_divide.
The question is what to do for np.divmod (since this is not defined by
standard). My opinion is in this case we need to set both dividebyzero and
invalid error flags since its a combination of these two operations.
This is going to cause a breaking change/silent incorrect results to
atleast some users who are either doing one or two of the following:
1. expecting nans from their output and check isnan but not isinf in their
code and accordingly do further computations.
2. who currently call raise only on invalid and not dividebyzero errors for
any of the above listed operations.
Considering this we can try one of the two things:
1. Create a futurewarning for every divmod(1.0, 0.0) path. This may be very
noisy and I cannot think of an action for a user to take to suppress this.
2. Since bug fixes are exempt from backwards compatibility policy
<https://numpy.org/neps/nep-0023-backwards-compatibility.html> just notify
in the release notes, maybe after a couple of releases. (More Impactful)
Depending on the compiler, and if it implements annex F of the C standard,
it may not support 1.0/0.0 operation and may crash. Also this is the case
for true_divide also, so we wont be breaking more users than we currently
Would like to hear your thoughts about this!
Our bi-weekly triage-focused NumPy development meeting is tomorrow
(Wednesday, May 6th) at 11 am Pacific Time (18:00 UTC).
Everyone is invited to join in and edit the work-in-progress meeting
topics and notes:
I encourage everyone to notify us of issues or PRs that you feel should
be prioritized or simply discussed briefly. Just comment on it so we
can label it, or add your PR/issue to this weeks topics for discussion.