[Numpy-discussion] Re: Improved 2DFFT Approach
On Wed, Feb 28, 2024 at 6:59 AM camrymanjr--- via NumPy-Discussion < numpy-discussion@python.org> wrote: > Good day! > > My name is Alexander Levin. > > My colleague and I did a project on optimisation of two-dimensional > Fourier transform algorithm six months ago. We took your implementation of > numpy fft2d as a unit of quality. > Thanks for sharing Alexander. > In the course of our research we found out that initially mathematically > the method uses a far from optimal algorithm. As you may know, your > operation goes first by rows then by columns applying a one-dimensional > transformation. After spending some time researching mathematical papers on > this topic, we found and implemented a new approach, the so-called > Cooley-Tukey butterfly, optimised by Russian mathematicians in 2016. > > The output is a completely new approach, where we immediately apply a > two-dimensional operation and save a serious proportion of time on it. As a > result, we wrote a C++ package for Python, using Cython as a wrapper. The > result was the package and an article on Medium describing the process. On > tests for matrices ranging in size from 2048x512 to 8192x8192, our > algorithm outperformed the NumPy transformation by an average of 50% in > time. > Did you also benchmark against `scipy.fft` by any chance? SciPy uses a newer C++ version of PocketFFT. In NumPy we just switched over from the older C code of PocketFFT to the newer C++ code: https://github.com/numpy/numpy/pull/25536. That PR also solves the upcasting that your Medium article touches on; we now have proper float32/complex64 support. Note that SciPy also has a multi-threaded version, which you can enable with the `workers` keyword. It'd also be interesting perhaps to benchmark memory usage, since your article touches on eliminating temporary arrays. After discussing this matter with my colleague with whom we did the above > development, we came to a common desire to share our results with you. Your > company has been making a huge contribution to the IT community for almost > 20 years on a pro bono basis. We share your philosophy and so we want to > make the CS world a better place by providing you with our code to optimise > the approach in an existing operation in your package. > Great to hear that. Note that we're not a company - more a loosely organized team of mostly volunteers and some folks who get to work on NumPy as part of their day job at a company or university. > We would like to offer you our development version, though it'll need some > minor improvements, we'd love to finish them collaboratively with you and > hear your thoughts regarding what we have discovered and done so far. We'd > be honored to help you and become NumPy contributors. > Performance improvements are always of interest, so if this is an algorithmic improvement without loss of accuracy, then that sounds very relevant. And more contributors are always welcome! Cheers, Ralf I trust that our vision will resonate with you and that you will agree with > us. I invite you to read our quick article about the process, which I have > linked below, and our fully functioning package and share your views on our > contribution to NumPy. We are willing to edit the code to fit your > standards, as we believe that the best use of our work will be to > contribute to the development of technology in the world. > > Thank you for your time. We look forward to your response and opinion. > > Medium Article about the process: > https://medium.com/p/7963c3b2f3c9 > GitHub Source code Repository: > https://github.com/2D-FFT-Project/2d-fft > ___ > 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: ralf.gomm...@googlemail.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] Re: JSON format for multi-dimensional data
Thank you dom for this encouraging comment ! I agree with these remarks. I will indeed integrate the extensions made by scipp to Xarray. Note: I am also looking for feedback regarding the analysis of tabular structures (e.g. to identify the hidden multidimensional structure): https://github.com/loco-philippe/tab-analysis/blob/main/docs/tabular_analysis. pdf. Do you think this might be of interest to scipp or Xarray? ___ 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: JSON format for multi-dimensional data
Could be of interest to scipp. They already put work to link to https://www.nexusformat.org. Maybe they would be interested in JData as well. — Also, what could be interesting is "format independent standard”. So that there is a general standard of data structures, which is adapted by different data formats, which are in turn implemented in different languages. Something like SansIO concept in the world of protocols. — Benefits: a) This way, if format obeys the standard, I would be certain that directed graph has node, edge, and graph attributes. b) Also, selling this to different libraries would be easier. Numpy would only need to implement 2 methods (to/from), which can be used by different formats and libraries. c) Another benefit of this would be that it would be possible to skip “format” step to convert between different libraries. E.g. xarray and scipp. d) Finally, if I decide to make my own data class, say graph. I only need 2 methods to be able to convert it to any other library. — I would happily be part of such project. Regards, DG > On 29 Feb 2024, at 15:04, phili...@loco-labs.io wrote: > > Thank you dom for this encouraging comment ! > > I agree with these remarks. > I will indeed integrate the extensions made by scipp to Xarray. > > Note: I am also looking for feedback regarding the analysis of tabular > structures (e.g. to identify the hidden multidimensional structure): > https://github.com/loco-philippe/tab-analysis/blob/main/docs/tabular_analysis. > pdf. > Do you think this might be of interest to scipp or Xarray? > ___ > 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: dom.grigo...@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] ENH: Add 'axis' kwarg to np.tile
Hoping to get some more feedback on my recent PR [0] which has stagnated a bit for the past few weeks. This adds an `axis` keyword argument to np.tile which may be an int or tuple of ints, much like np.sum or np.roll. This is my first contribution to numpy :) Thanks, Evan [0]: https://github.com/numpy/numpy/pull/25703 ___ 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: ENH: Add 'axis' kwarg to np.tile
Hi, I think the thing to do is argue that this should be included in the array API: https://data-apis.org/array-api/latest/API_specification/generated/array_api.tile.html#array_api.tile Once that’s settled we can add it to NumPy. In general there’s a feeling that there are already too many keywords in the API and now that the array API is a thing, we can point to that as a place to hash out API decisions. Including syntax in the array API also encourages more libraries to adopt your preferred syntax. Nathan On Thu, Feb 29, 2024 at 4:12 PM wrote: > Hoping to get some more feedback on my recent PR [0] which has stagnated a > bit for the past few weeks. > > This adds an `axis` keyword argument to np.tile which may be an int or > tuple of ints, much like np.sum or np.roll. > > This is my first contribution to numpy :) > > Thanks, > Evan > > [0]: https://github.com/numpy/numpy/pull/25703 > ___ > 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: nathan12...@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] Re: ENH: Add 'axis' kwarg to np.tile
Not to discourage you from making the suggestion https://github.com/data-apis/array-api/issues, but my experience is that the array API consortium tends to make the reverse argument, that if something isn't already implemented in one (or ideally most) array libraries, then it's less likely to be slated for inclusion. The general exception to this is for things for which there is a clear user need but no pre-existing APIs, for example, the new isdtype() function or the new inspection APIs added in the 2023.12 version of the standard, which are needed to make portable array code easier to write. Although I haven't checked if libraries like pytorch already have this feature in tile(). If you do want to propose this for the array API, I would be sure to 1. show that there is a clear user need 2. argue that this is not difficult for most array libraries to implement (this applies generally, not just for this one suggestion) Also FWIW, tile() is new in the 2023.12 standard (just released a few days ago), so that potentially strengthens the argument that an axis keyword was missed during standardization and should be added. Aaron Meurer On Thu, Feb 29, 2024 at 4:42 PM Nathan wrote: > > Hi, > > I think the thing to do is argue that this should be included in the array > API: > > https://data-apis.org/array-api/latest/API_specification/generated/array_api.tile.html#array_api.tile > > Once that’s settled we can add it to NumPy. > > In general there’s a feeling that there are already too many keywords in the > API and now that the array API is a thing, we can point to that as a place to > hash out API decisions. > > Including syntax in the array API also encourages more libraries to adopt > your preferred syntax. > > Nathan > > On Thu, Feb 29, 2024 at 4:12 PM wrote: >> >> Hoping to get some more feedback on my recent PR [0] which has stagnated a >> bit for the past few weeks. >> >> This adds an `axis` keyword argument to np.tile which may be an int or tuple >> of ints, much like np.sum or np.roll. >> >> This is my first contribution to numpy :) >> >> Thanks, >> Evan >> >> [0]: https://github.com/numpy/numpy/pull/25703 >> ___ >> 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: nathan12...@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: asmeu...@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
