I was wondering if it is a possible addition to numpy to have a function to
wrap values to an interval. Typically, it is desired to limit an angle to
[0, 2pi) or [-pi ,pi), either by letting it "overflow" or by "bouncing"
hence and forth.
The function which does this is actually really simple.
However, whenever I am facing this task I tend to work a while on this
until I get it correct.
I have a small and handy function (it is small because it just uses
np.divmod) at hand which does this, including also the left-open or closed
cases, and some tests.
In case this is of interest, I can contribute.
Our bi-weekly triage-focused NumPy development meeting is Wednesday,
May 19th 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, discussed, or reviewed.
The `ndarray.ctypes` object currently contains four (undocumented) methods that are essentially leftover implementation artifacts,
kept around for the sake of backwards compatibility. As this was three years ago it is, in my opinion, a suitable time now to properly deprecate them,
my question being if anyone would have objections to this.
The methods in question are:
* `get_data` (use the `data` property instead)
* `get_shape` (use the `shape` property instead)
* `get_strides` (use the `ctypes.strides` property instead)
* `get_as_parameter` (use the `_as_parameter_` property instead)
For those interested, a PR implementing their deprecation is currently up at https://github.com/numpy/numpy/pull/19031
Bas van Beek
Thank you so much for this opportunity!
I am so excited to get started with this project. I really appreciate all
the help and encouragement from the community.
It is going to be so much fun to work with you all!
On Sat, May 15, 2021 at 2:18 AM <numpy-discussion-request(a)python.org> wrote:
> Send NumPy-Discussion mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NumPy-Discussion digest..."
> Today's Topics:
> 1. Google Season of Docs (Melissa Mendon?a)
> 2. Re: Google Season of Docs (Stefan van der Walt)
> 3. Re: Google Season of Docs (Ralf Gommers)
> 4. Re: bad CRC errors when using np.savez, only sometimes
> though! (Isaac Gerg)
> Message: 1
> Date: Fri, 14 May 2021 15:41:56 -0300
> From: Melissa Mendon?a <melissawm(a)gmail.com>
> To: Discussion of Numerical Python <numpy-discussion(a)python.org>
> Subject: [Numpy-discussion] Google Season of Docs
> Content-Type: text/plain; charset="utf-8"
> Hello, all!
> I am happy to announce we found our technical writer for the Google Season
> of Docs program. After looking at all submitted proposals we have decided
> to hire Mukulika. You can see her Statement of Interest here:
> We are very glad to participate again this year and sincerely thank all the
> technical writers who took an interest in our project and that contacted us
> about it. If you want to keep contributing to NumPy, you are all most
> Mukulika has already started doing some contributions to NumPy and we wish
> her a successful project. Me and Ross will be the mentors for this proposal
> but the community is also encouraged to participate with suggestions and
> comments. You can check out the timeline and more details about GSoD here:
I am using 1.19.5 on Windows 10 using Python 3.8.6 (tags/v3.8.6:db45529,
Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)].
I have two python processes running (i.e. no threads) which do
independent processing jobs and NOT writing to the same directories. Each
process runs for 5-10 hours and then writes out a ~900MB npz file
containing 4 arrays.
When I go back to read in the npz files, I will sporadically get bad CRC
errors which are related to npz using ziplib. I cannot figure out why this
is happening. Looking through online forums, other folks have had CRC
problems but they seem to be isolated to specifically using ziblib, not
numpy. I have found a few mentions though of ziplib causing headaches if
the same file pointer is used across calls when one uses the file handle
interface to ziblib as opposed to passing in a filename.'
I have verified with 7zip that the files do in fact have a CRC error so its
not an artifact of the ziblib. I have also used the file handle interface
to np.load and still get the error.
Aside from writing my own numpy storage file container, I am stumped as to
how to fix this, or reproduce this in a consistent manner. Any suggestions
would be greatly appreciated!
I am happy to announce we found our technical writer for the Google Season
of Docs program. After looking at all submitted proposals we have decided
to hire Mukulika. You can see her Statement of Interest here:
We are very glad to participate again this year and sincerely thank all the
technical writers who took an interest in our project and that contacted us
about it. If you want to keep contributing to NumPy, you are all most
Mukulika has already started doing some contributions to NumPy and we wish
her a successful project. Me and Ross will be the mentors for this proposal
but the community is also encouraged to participate with suggestions and
comments. You can check out the timeline and more details about GSoD here:
If changing the on-disk format is an option, I would suggest h5py <https://docs.h5py.org/en/stable/> which allows to save numpy arrays in HDF5 format.
On 14 May 2021, at 16:22, numpy-discussion-request(a)python.org<mailto:email@example.com> wrote:
Aside from writing my own numpy storage file container, I am stumped as to how to fix this, or reproduce this in a consistent manner. Any suggestions would be greatly appreciated!
There will be a NumPy Community meeting Wednesday Mai 12th at
20:00 UTC. Everyone is invited and encouraged to
join in and edit the work-in-progress meeting topics and notes at: