Mailman 3 August 2021 - NumPy-Discussion

New Feature added to rotate MeshGrid
by Yash Tewatia 31 Aug '21

31 Aug '21

Hi, it is my first contribution to the open-source community, I have tried to fix issue #19315, which is to add a new feature of rotating mesh grid in NumPy. It would be great if I get improvements and suggestions for it. Added functionality of rotating mesh grid which fixes #19315 issue, adds a feature which works as follows Parameters ----------- xspan : Input_array range of values of x in the unrotated matrix. yspan : Input_array range of values of y in the unrotated matrix. angle : float or int Angle of rotation, positive for clockwise rotation, negative for anti-clockwise rotation. boolRad : bool True if the given angle is in Radians, False if given angle is in Degrees. Returns -------- out : ndarray A new nested array is generated by Einstein Summation after rotation is applied. Examples ---------- >>> xspan = np.linspace(-2*np.pi, 2*np.pi, 3) >>> yspan = np.linspace(-2*np.pi, 2*np.pi, 3) >>> arr = np.rotateMeshgrid(xspan,yspan,0.4) >>> arr array([[[-6.32689674, -0.04386455, 6.23916764], [-6.28303219, 0. , 6.28303219], [-6.23916764, 0.04386455, 6.32689674]], [[-6.23916764, -6.28303219, -6.32689674], [ 0.04386455, 0. , -0.04386455], [ 6.32689674, 6.28303219, 6.23916764]]]) >>> arr = np.rotateMeshgrid(xspan,yspan,80,False) >>> arr array([[[ 6.9383701 , 6.24478659, 5.55120308], [ 0.69358351, 0. , -0.69358351], [-5.55120308, -6.24478659, -6.9383701 ]], [[-5.55120308, 0.69358351, 6.9383701 ], [-6.24478659, 0. , 6.24478659], [-6.9383701 , -0.69358351, 5.55120308]]]) Code snippet: ( https://user-images.githubusercontent.com/60055574/131483810-05012ab1-8971-… )

2 1

SeedSequence.spawn()
by Stig Korsnes 29 Aug '21

29 Aug '21

Hi, Is there a way to uniquely spawn child seeds? I`m doing monte carlo analysis, where I have n random processes, each with their own generator. All process models instantiate a generator with default_rng(). I.e ss=SeedSequence() cs=ss.Spawn(n), and using cs[i] for process i. Now, the problem I`m facing, is that results using individual process depends on the order of the process initialization ,and the number of processes used. However, if I could spawn children with a unique identifier, I would be able to reproduce my individual results without having to pickle/log states. For example, all my models have an id (tuple) field which is hashable. If I had the ability to SeedSequence(x).Spawn([objects]) where objects support hash(object), I would have reproducibility for all my processes. I could do without the spawning, but then I would probably loose independence when I do multiproc? Is there a way to achieve my goal in the current version 1.21 of numpy? Best Stig

2 11

Announcing PyData/Sparse 0.13.0
by Hameer Abbasi 28 Aug '21

28 Aug '21

Hello everyone. I’m happy to announce version 0.13.0 of PyData/Sparse. PyData/Sparse provides sparse arrays for the PyData ecosystem: It mimics the NumPy API but provides sparse storage. Version 0.13.0 was mainly a bugfix-centred release, fixing many bugs and regressions reported by users for versions 0.12.0 and 0.11.0. Python 3.6 was dropped for this release, and version 3.9 support was formally added. Some minor features were also added. Source Code: https://github.com/pydata/sparse/tree/0.13.0 <https://github.com/pydata/sparse/tree/0.13.0> Documentation: https://sparse.pydata.org/en/0.13.0/ <https://sparse.pydata.org/en/0.13.0/> Changelog: https://sparse.pydata.org/en/0.13.0/changelog.html <https://sparse.pydata.org/en/0.13.0/changelog.html> Best regards, Hameer Abbasi

1 0

NumPy Development Meeting Wednesday - Triage Focus
by Sebastian Berg 25 Aug '21

25 Aug '21

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

Floating point precision expectations in NumPy
by Sebastian Berg 19 Aug '21

19 Aug '21

Hi all, there is a proposal to add some Intel specific fast math routine to NumPy: https://github.com/numpy/numpy/pull/19478 part of numerical algorithms is that there is always a speed vs. precision trade-off, giving a more precise result is slower. So there is a question what the general precision expectation should be in NumPy. And how much is it acceptable to diverge in the precision/speed trade-off depending on CPU/system? I doubt we can formulate very clear rules here, but any input on what precision you would expect or trade-offs seem acceptable would be appreciated! Some more details ----------------- This is mainly interesting e.g. for functions like logarithms, trigonometric functions, or cubic roots. Some basic functions (multiplication, addition) are correct as per IEEE standard and give the best possible result, but these are typically only correct within very small numerical errors. This is typically measured as "ULP": https://en.wikipedia.org/wiki/Unit_in_the_last_place where 0.5 ULP would be the best possible result. Merging the PR may mean relaxing the current precision slightly in some places. In general Intel advertises 4 ULP of precision (although the actual precision for most functions seems better). Here are two tables, one from glibc and one for the Intel functions: https://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions… (Mainly the LA column) https://software.intel.com/content/www/us/en/develop/documentation/onemkl-v… Different implementation give different accuracy, but formulating some guidelines/expectation (or referencing them) would be useful guidance. For basic

5 6

Adding New Feature
by Bhavay Malhotra 19 Aug '21

19 Aug '21

Dear Team, I’m thinking of adding a new feature in response to the issue no. #19039. The feature is basically a function to check whether the data type of both the numpy arrays are same or not. If the numpy arrays have different data types function return a False else it returns a True. Please consider my feature and reply appropriately so that I can send my PR accordingly. Waiting to see a prompt reply. Thanking You. Regards, Bhavay

2 1

[JOB] modeling engineer at Form Energy
by Dr. Mark Alexander Mikofski PhD 18 Aug '21

18 Aug '21

https://jobs.lever.co/formenergy/672c9b68-fc0e-46ff-b430-7a65e829ab8a Role Description We are looking for a Staff Modeling Engineer to join our systems team to build energy storage system performance models which will be used as the basis for designing our multi-day storage product. The Staff Modeling Engineer will be responsible for engaging with the battery team, the systems team, and the market analytics team to develop modeling tools which capture the electrochemical performance of our product under real world operating conditions, equipping those teams with the tools they need to make trade decisions between cost, performance, and durability. This engineer is expected to collaborate with the engineers developing the mechanistic battery models but need not be an electrochemist. The engineer is expected to have experience with systems modelling at a high level and proven abilities for abstracting and simplifying complex systems.

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg 18 Aug '21

18 Aug '21

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

OS X universal2 wheels
by Charles R Harris 16 Aug '21

16 Aug '21

Hi All, I note that the numpy universal wheels for Mac are marked "10_9" whereas the wheels for Arm64 are marked '11_0'. Does that need to be fixed? Chuck

2 1

NumPy 1.21.2 released
by Charles R Harris 15 Aug '21

15 Aug '21

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.21.2. NumPy 1.21.2 is a maintenance release that fixes bugs discovered after 1.21.1. It also provides 64 bit manylinux Python 3.10.0rc1 wheels for downstream testing. Note that Python 3.10 is not yet final. There is also preliminary support for Windows on ARM64 builds, but there is no OpenBLAS for that platform and no wheels are available. The Python versions supported for this release are 3.7-3.9. The 1.21.2 release is compatible with Python 3.10.0rc1 and Python 3.10 will be officially supported after it is released. The previous problems with gcc-11.1 have been fixed by gcc-11.2, check your version if you are using gcc-11. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.21.2/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.21.2>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 10 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Bas van Beek - Carl Johnsen + - Charles Harris - Gwyn Ciesla + - Matthieu Dartiailh - Matti Picus - Niyas Sait + - Ralf Gommers - Sayed Adel - Sebastian Berg *Pull requests merged* A total of 18 pull requests were merged for this release. - #19497: MAINT: set Python version for 1.21.x to ``<3.11`` - #19533: BUG: Fix an issue wherein importing ``numpy.typing`` could raise - #19646: MAINT: Update Cython version for Python 3.10. - #19648: TST: Bump the python 3.10 test version from beta4 to rc1 - #19651: TST: avoid distutils.sysconfig in runtests.py - #19652: MAINT: add missing dunder method to nditer type hints - #19656: BLD, SIMD: Fix testing extra checks when ``-Werror`` isn't applicable... - #19657: BUG: Remove logical object ufuncs with bool output - #19658: MAINT: Include .coveragerc in source distributions to support... - #19659: BUG: Fix bad write in masked iterator output copy paths - #19660: ENH: Add support for windows on arm targets - #19661: BUG: add base to templated arguments for platlib - #19662: BUG,DEP: Non-default UFunc signature/dtype usage should be deprecated - #19666: MAINT: Add Python 3.10 to supported versions. - #19668: TST,BUG: Sanitize path-separators when running ``runtest.py`` - #19671: BLD: load extra flags when checking for libflame - #19676: BLD: update circleCI docker image - #19677: REL: Prepare for 1.21.2 release. Cheers Charles Harris

1 0

NumPy-Discussion August 2021