Mailman 3 October 2021 - NumPy-Discussion

Contributing to Numpy (non coder)
by andresguzman26222014＠gmail.com Oct. 13, 2021

Oct. 13, 2021

Hello everyone, I´m an student of Data Science and a technical writer, and I would like to contribute to NumPy. The problem is that even though I know the basics of Github, I´m not a Developer. I would like to know about these listed options of contributing: https://numpy.org/doc/stable/dev/index.html Among the mentioned in your doc, I have experience in Developing educational content, Project Management and Writing technical documentation. Hope is still possible to contribute. Thanks for reading.

6 5

Musllinux wheels
by Laurie O Oct. 12, 2021

Oct. 12, 2021

CI request: build PEP 656 (https://www.python.org/dev/peps/pep-0656/) compliant "musllinux" wheels. This will allow easy installation in Alpine Docker images. GitHub issue: https://github.com/numpy/numpy/issues/20089

6 12

Intel's Short Vector Math Library has been merged as a git submodule
by Matti Picus Oct. 12, 2021

Oct. 12, 2021

Yesterday we merged PR 19478 [0] to add a open source version of Intel's Short Vector Math library into NumPy. The original PR was by Raghuveer Devulapalli. There was a lot of discussion on the PR, but now that I look back it seems the mailing list may not have been involved. The code lives in https://github.com/numpy/SVML, and in order to pull it in you must now do `git submodule update --init` before building NumPy. The library provides AVX-512 implementations of the following math functions: exp, exp2, log, log2, log10, expm1, log1p, cbrt, pow, sin, cos, tan, asin, acos, atan, atan2, sinh, cosh, tanh, asinh, acosh and atanh, speeding them up significantly where AVX-512 is available. Before this PR was merged, Raghuveer added a set of tests for accuracy and compliance for these functions [1]. The accuracy is now defined as up to 4 ULP in the worst case for tan, cos, sin, asin, atan, expm1, but typically the error is up to 2 ULP. As SciPy already found out, some downstream libraries may need to tweak their tolerances for some functions as a result of this PR. We wanted to put it in early enough in the release cycle so that we can back it out fully or partially if the accuracy degradation is too large, so please speak up if you notice anything strange. Matti [0] https://github.com/numpy/numpy/pull/19478 [1] https://github.com/numpy/numpy/pull/19485

2 2

Idea: adding `ndarray.isin` for consistency with pandas
by Max Ghenis Oct. 11, 2021

Oct. 11, 2021

`numpy.isin` is equivalent to `pandas.{Series,DataFrame}.isin`. Adding `numpy.ndarray.isin` would produce consistency with `pandas` and save 4 characters (`np.isin(x, y)` vs. `x.isin(y)`). I'm adding this idea here in conjunction with filing https://github.com/numpy/numpy/issues/20092 per the instructions.

2 1

Musllinux wheels
by Laurie O Oct. 11, 2021

Oct. 11, 2021

CI request: build PEP 656 (https://www.python.org/dev/peps/pep-0656/) compliant "musllinux" wheels. This will allow easy installation in Alpine Docker images. GitHub issue: https://github.com/numpy/numpy/issues/20089

1 0

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

[JOBS] Solar & Storage Energy Analyst
by Dr. Mark Alexander Mikofski PhD Oct. 7, 2021

Oct. 7, 2021

Dear Pythonistas, If you're an experienced solar energy analyst looking to accelerate the energy transition & make a bigger impact on the climate crisis by using your Python analytical skills to help deploy more solar power & energy storage cheaper, better, & faster, then please come join my team at DNV. I'm not looking for superstars. I just need a few friendly folks who value diversity & are open to using the best tools to save our planet. Please follow the links below or email me for more info: US: https://careers-dnv.icims.com/jobs/16829/job Canada: https://careers-dnv.icims.com/jobs/16831/job Thanks, Mark -- Mark Mikofski, PhD (2005) *Fiat Lux*

1 0

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

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

Oct. 6, 2021

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