[Numpy-discussion] next NumPy community meeting - March 13th, 2024 at 6pm UTC

[Inessa Pawson]

The next NumPy community meeting will be held this Wednesday, March 13th at
6pm UTC.
Join us via Zoom:
https://numfocus-org.zoom.us/j/83278611437?pwd=ekhoLzlHRjdWc0NOY2FQM0NPemdkZz09
.
Everyone is welcome and encouraged to attend.
To add to the meeting agenda the topics you’d like to discuss, follow the
link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both.
For the notes from the previous meetings, visit:
https://github.com/numpy/archive/tree/main/community_meetings.

-- 
Cheers,
Inessa

Inessa Pawson
GitHub: inessapawson
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Improved 2DFFT Approach

[via NumPy-Discussion]

Good afternoon, Ralf.

We have done some of the measurements you recommended, for your convenience we 
have created a separate folder with notebooks where we measured memory usage 
and performance of our interpretation against Scipy. Separately you can run the 
tests on your hardware and separately measure memory. I've left the link below.

https://github.com/2D-FFT-Project/2d-fft/tree/main/notebooks

We measured efficiency for 4 versions - with multithreading and data type 
conversion. According to the results of the tests, our algorithm has the 
greatest lead in the case with multithreading and without data type conversion 
- 75%, the worst performance without multithreading and with data type 
conversion - 14%. In terms of memory usage we beat NumPy and Scipy by 2 times 
in all cases, I think this is a solid achievement at this point. 

I can generalise that our mathematical approach still has a serious advantage, 
nevertheless we lose always to Scipy in inverse operation case, we haven't 
figured out the reasons yet, we are discussing it at the moment, but we will 
fix it. 

It is important to note that at this stage our algorithm shows the above 
perfomance on matrices of size powers of two. 
This is a specificity of the mathematical butterfly formula. We are 
investigating ways to remove this limitation, we already assessed the effect of 
element imputation and column dropping, the result is not accurate enough. 
Otherwise, we can suggest putting our version to work only in cases of the 
mentioned matrices, it'll still be an upgrade for NumPy.

At this point I can say that we are willing to work and improve the existing 
version within our skills, knowledge and available resources. We still live 
with the idea of adding our interpretation or idea to the existing NumPy 
package, as in theoretical perspective within the memory usage and efficiency, 
it can give a serious advantage on other projects built on NumPy. 

Thank you for your time, we will continue our work and look forward to your 
review.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Improved 2DFFT Approach

[george trojan]

I think the argument nworkers = -1 to scipy.fft.fft2 and scipy.fft.ifft2 is
in the wrong places in the notebook.

Le lun. 11 mars 2024, à 21 h 25, via NumPy-Discussion <
numpy-discussion@python.org> a écrit :

> Good afternoon, Ralf.
>
> We have done some of the measurements you recommended, for your
> convenience we have created a separate folder with notebooks where we
> measured memory usage and performance of our interpretation against Scipy.
> Separately you can run the tests on your hardware and separately measure
> memory. I've left the link below.
>
> https://github.com/2D-FFT-Project/2d-fft/tree/main/notebooks
>
> We measured efficiency for 4 versions - with multithreading and data type
> conversion. According to the results of the tests, our algorithm has the
> greatest lead in the case with multithreading and without data type
> conversion - 75%, the worst performance without multithreading and with
> data type conversion - 14%. In terms of memory usage we beat NumPy and
> Scipy by 2 times in all cases, I think this is a solid achievement at this
> point.
>
> I can generalise that our mathematical approach still has a serious
> advantage, nevertheless we lose always to Scipy in inverse operation case,
> we haven't figured out the reasons yet, we are discussing it at the moment,
> but we will fix it.
>
> It is important to note that at this stage our algorithm shows the above
> perfomance on matrices of size powers of two.
> This is a specificity of the mathematical butterfly formula. We are
> investigating ways to remove this limitation, we already assessed the
> effect of element imputation and column dropping, the result is not
> accurate enough. Otherwise, we can suggest putting our version to work only
> in cases of the mentioned matrices, it'll still be an upgrade for NumPy.
>
> At this point I can say that we are willing to work and improve the
> existing version within our skills, knowledge and available resources. We
> still live with the idea of adding our interpretation or idea to the
> existing NumPy package, as in theoretical perspective within the memory
> usage and efficiency, it can give a serious advantage on other projects
> built on NumPy.
>
> Thank you for your time, we will continue our work and look forward to
> your review.
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: george.tro...@gmail.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] NumPy 2.0.0b1 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.0b1. NumPy 2.0.0 is the first major release since 2006. It is the
result of 10 months of development since the last feature release and is
the work of 190
contributors spread over 968 pull requests. It contains a large number of
exciting new features as well as changes to both the Python and C APIs.

This major release includes breaking changes that could not happen in a
regular minor (feature) release - including an ABI break, changes to type
promotion rules, and API changes which may not have been emitting
deprecation warnings in 1.26.x. Key documents related to how to adapt to
changes in NumPy 2.0 include:

   - The release notes on Github
   
   - The numpy-2-migration-guide
   
   - The numpy 2.0-specific advice in for downstream package authors
   

Highlights include:

   - A new variable-length string dtype, StringDType, and a new
   `numpy.strings` namespace with performant ufuncs for string operations.
   - Support for float32 and long double in all `numpy.fft` functions.
   - Support for the array API standard in the main numpy namespace.
   - MacOS Accelerate support and binary wheels for macOS >=14.
   - A new tracing and introspection API.
   - Performance improvements.
   - Python API improvements.
   - C API improvements.

Wheels can be downloaded from PyPI
; source
archives, release notes, and wheel hashes are available on Github



*Contributors*

A total of 190 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - @Algorithmist-Girl +
   - @DWesl
   - @Illviljan
   - @ellaella12 +
   - @liang3zy22 +
   - @matoro +
   - @mcp292 +
   - @mykykh +
   - @pojaghi +
   - @pratiklp00 +
   - @stefan6419846 +
   - @undermyumbrella1 +
   - Aaron Meurer
   - Aditi Saluja +
   - Agriya Khetarpal +
   - Albert Steppi +
   - Alex Cabrera +
   - Alexander Grund
   - Andrea Bianchi +
   - Andreas Florath +
   - Andrew Ardill +
   - Andrew Ho +
   - Andrew Nelson
   - Andrey Rybakov +
   - Ankur Singh +
   - Anton Prosekin +
   - Antony Lee
   - Bas van Beek
   - Bharat Raghunathan
   - Bhavya Alekhya +
   - Brandon Smith +
   - Brian Walshe +
   - Brigitta Sipőcz
   - Brock Mendel
   - Carl Meyer +
   - Charles Bousseau +
   - Charles Harris
   - Chris Sidebottom
   - Christian Lorentzen
   - Christian Veenhuis
   - Christoph Reiter
   - Christopher Sidebottom
   - Clément Robert
   - Cédric Hannotier
   - D.J. Ramones +
   - DanShatford +
   - Daniel Li +
   - Daniel Vanzo
   - Daval Parmar
   - Developer-Ecosystem-Engineering
   - Dhruv Rawat +
   - Dimitri Papadopoulos Orfanos
   - Edward E
   - Edward Yang +
   - Eisuke Kawashima +
   - Eliah Kagan +
   - Élie Goudout +
   - Elliott Sales de Andrade
   - Emil Olszewski +
   - Emily Hunt +
   - Éric Piel +
   - Eric Wieser
   - Even Rouault +
   - Evgeni Burovski
   - Filipe Laíns +
   - Ganesh Kathiresan
   - Hans Meine
   - Heberto Mayorquin +
   - Heinz-Alexander Fuetterer +
   - Hood Chatham
   - Ivan A. Melnikov +
   - Jacob M. Casey +
   - Jake Lishman +
   - Jake VanderPlas
   - Jake Vanderplas
   - James Oliver +
   - Jan Wassenberg +
   - Janukan Sivajeyan +
   - Johann Rohwer +
   - Johannes Kaisinger +
   - John Muradeli +
   - Kai Striega
   - Kevin Sheppard
   - Kevin Wu +
   - Khawaja Junaid +
   - Kit Lee +
   - Kristian Minchev +
   - Kuan-Wei Chiu +
   - Lane Votapka +
   - Larry Bradley
   - Leo Singer
   - Liang Yan +
   - Linus Sommer +
   - Logan Thomas
   - Lucas Colley +
   - Lukas Geiger
   - Lysandros Nikolaou +
   - Maanas Arora +
   - Maharshi Basu +
   - Mahder Gebremedhin +
   - Marcel Bargull +
   - Mark Mentovai +
   - Mark Ryan +
   - Marten Henric van Kerkwijk +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matthew Barber
   - Matthias Bussonnier
   - Matthias Koeppe
   - Matthias Schaufelberger +
   - Matti Picus
   - Maxwell Aladago
   - Maya Anderson +
   - Melissa Weber Mendonça
   - Meng Xiangzhuo +
   - Michael Kiffer
   - Miki Watanabe (渡邉 美希)
   - Milan Curcic +
   - Miles Cranmer
   - Miro Hrončok +
   - Mohamed E. BRIKI +
   - Mohaned Qunaibit +
   - Mohit Kumar +
   - Muhammed Muhsin +
   - Mukulika Pahari
   - Munira Alduraibi +
   - Namami Shanker
   - Nathan Goldbaum
   - Nyakku Shigure +
   - Ola x Nilsson +
   - Olivier Mattelaer +
   - Omid Rajaei
   - Pablo Losada +
   - Pamphile Roy
   - Paul Reece +
   - Pedro Kaj Kjellerup Nacht +
   - Peiyuan Liu +
   - Peter Hawkins
   - Pierre
   - Pieter Eendebak
   - Quentin Barthélemy +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Randy Eckenrode +
   - Richard Howe +
   - Robert Kern
   - Rohit Goswami
   - Ronald van Elburg +