- Boost - lists.preview.boost.org

FFT proposal for gsoc 2021
by Eduardo Quintana 08 Apr '21

08 Apr '21

Hi Boost community, I've been working on a C++ templated library for Fast Fourier Transforms, https://github.com/Lagrang3/fftx. Templated because some FFT algorithms are algebraic-field independent, eg. you could FFT an array of N matrices provided a Nth matrix-root-of-unity is given. As a result you could have a single algorithm for a variety of underlying, eg. `std::complex<float>`, `std::complex<double>`, `std::complex<long double>`, `boost::math::quaternion`, finite field types (this would yield the "Number theoretic transform" https://cp-algorithms.com/algebra/fft.html#toc-tgt-6) I would like to improve this library during the GSOC 2021, as a proposal for inclusion inside Boost.Math or Boost.Algorithms. Is there anyone interested in supervising this project? Any opinions? Best regards, Eduardo Quintana

6 29

[GSoC 2021] Proposal for Boost.xml
by qiqi tang 07 Apr '21

07 Apr '21

Hello, My name is Fuqi Tang who is a graduate student in China. I am majoring in Software engineering. I want to take part in GSoC 2021 for the Boost.xml project and I will really appreciate it if the community can watch my proposal and give me some advice to improve it. Below is my proposal link https://docs.google.com/document/d/1GYuiVqU8ChaTG2RO2qhQbpF9QSuK5uGRRNDx0M2… Thanks a lot! Regards, Fuqi

2 1

Review and Feedback for Boost.XML proposal
by YAGNIK VAGHELA 07 Apr '21

07 Apr '21

Hello, I am Yagnik Vaghela. I live in India. I am a 3rd year undergraduate student pursuing B.tech in ICT(Information and communication Technology) at DA-IICT. I would like to participate in GSoC this year. I would like to work on a project Boost.XML library. Here's my draft proposal. Please kindly review it and give feedback. any suggestions would be appreciated. https://docs.google.com/document/d/14rzb_3W_5lNM5_qfYpV4zVOh3QmOwuQgWLfeem_…

2 1

[GSoC] Boost.Real GSoC Proposal Feedback
by Divyam Singal 07 Apr '21

07 Apr '21

Hi all, This is Divyam, a 2nd year CSE student at IIT Guwahati. I have shared my draft proposal through GSoC website. I have shared the drive link to the pdf, as docs don't support rendering of LaTeX maths and graphs. You can comment to provide review by right-clicking that portion in the pdf. Do have a look at it and provide the feedback so that I can make the necessary changes. Thanks and Regards, Divyam Singal

1 0

boost mailing list archive stopped updating
by Janek Kozicki 07 Apr '21

07 Apr '21

Just a heads-up, boost mailing list archive stopped updating 3 days ago: https://lists.boost.org/Archives/boost/ best regards Janek -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdańsk University of Technology Faculty of Applied Physics and Mathematics Department of Theoretical Physics and Quantum Information -- http://yade-dem.org/ http://pg.edu.pl/jkozicki (click English flag on top right)

2 2

[Boost][GIL][GSOC21]Review and Feedback for Boost GIL project proposal
by sayan chaudhuri 07 Apr '21

07 Apr '21

Hello Everyone, My name is Sayan Chaudhuri. I am a final year,undergraduate student,in the Computer Science and Engineering department of IEM,India . I am eager to participate in the GSOC 2021 and willing to contribute to the Boost GIL library. I am looking to implement the ORB feature descriptor for BOOST GIL . Currently the only keypoint detector present is Harris Corner. And no separate descriptors are present. ORB comes with both a keypoint detector and descriptor bundled and it is suitable for real time systems and also license free. Feature descriptors are important for tasks like object recognition, structure from motion, image stitching etc. And ORB is a good choice for real time systems. I am attaching the link of my project proposal for the same below. I would request anyone who is interested to mentor me or co-mentor to kindly have a look at my proposal. I would really appreciate any feedback from your side and I am looking to continue the discussion of the project further. Proposal link : https://docs.google.com/document/d/1ARL57qRdNWPGe3GlqY1n8E31LyUCvyIyvBk_agz… Thank you.

1 0

[release] 1.76.0 post-beta merges
by Marshall Clow 06 Apr '21

06 Apr '21

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on Wednesday, Apr 7. Full calendar here: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall P.S Doc changes and test changes do NOT require release manager approval to be merged.

12 34

[gsoc21] Feedback and advice on proposal
by Haoran Xu 04 Apr '21

04 Apr '21

Hi, I'm really interested in applying for GSoC 2021 and implementing the Boost.XML library. I have completed the competency test and have drafted by proposal. https://docs.google.com/document/d/1KP-g1zMXQdqUzSFMtsURcSpZisjjspvX8lRkdRj… Please tell me what you think this proposal is missing and what I should add on. It's my first time applying for GSoC so I'm not very familiar with the process. Thank you!

2 4

Re: [boost] [Boost][GIL][GSOC21] Draft Proposal for Boost GIL
by sayan chaudhuri 04 Apr '21

04 Apr '21

Hello Everyone, My name is Sayan Chaudhuri. I am a final year,undergraduate student,in the Computer Science and Engineering department of IEM,India . I am eager to participate in the GSOC 2021 and willing to contribute to the Boost GIL library. I am looking to implement the ORB feature descriptor for BOOST GIL . Currently the only keypoint detector present is Harris Corner. And no separate descriptors are present. ORB comes with both a keypoint detector and descriptor bundled and it is suitable for real time systems and also license free. Feature descriptors are important for tasks like object recognition, structure from motion, image stitching etc. And ORB is a good choice for real time systems. I am attaching the link of my project proposal for the same below. I would request anyone who is interested to mentor me or co-mentor to kindly have a look at my proposal. I would really appreciate any feedback from your side and I am looking to continue the discussion of the project further. Proposal link : https://docs.google.com/document/d/1ARL57qRdNWPGe3GlqY1n8E31LyUCvyIyvBk_agz… . Thank you.

1 0

Re: [boost] FFT proposal for gsoc 2021
by Eduardo Quintana 03 Apr '21

03 Apr '21

Hi Kostas, Good critics are necessary for the sake of improvement. All of your comments are welcome. > 1) The discussion of NTT. While boost.multiprecision can potentially be used > to implement the Zp ring, it currently does not contain any such construct. > Reading further, there is nothing about NTT in the deliverables. If the idea > is peripheral to the GSOC project, then it does not need to be mentioned at > all. Note that even the PARI library does not yet have NTT implemented and > for them I think it is a high priority (must be a very hard problem). 1) I mentioned the NTT because is part of the motivation for having a general DFT instead just complex-DFT. Maybe the text it is not clear. You'll get the NTT for free. See these two examples https://github.com/Lagrang3/fftx/blob/master/examples/ex02.cpp https://github.com/Lagrang3/fftx/blob/master/examples/ex03.cpp Unfortunately I haven't produced a convolution routine yet, hence in ex03 I had to compute it explicitely. There is also a small implementation of Zp https://github.com/Lagrang3/fftx/blob/master/examples/modulo.h if there was one in Boost I would gladly use it. > 2) Section 2.2. Most people know the Convolution Theorem, but at least myself > do not know anything about the Rader algorithm. Since you propose to > implement it, why not describe it in that Section, maybe instead of the > Convolution Theorem. 2) The Convolution Theorem is very well known yes. I wanted just to make a small subsection in order to clarify which flavour of the Convolution I am using: the Circular Discrete Convolution (CDC) which fits naturally into the DFT scheme. The other Discrete Convolution is the one that you write as c_i = \sum_{j} a_j b_{i-j} produces, in my opinion, many questions to the reader for instance: what do we do with the negative indexes? Zero-pad them or wrap around from the end? I think writing proofs and detailed algorithms is not necessary for the text of the proposal. Last year when I started the fftx experiment I came to the conclusion at some point that I needed, besides Cooley-Tukey and mixed-radix, another algorithm to compute the DFT for prime sizes. Then I found the description of Rader's algorithm in Wikipedia. FFTW uses it, by the way. > 3) Section 2.3. You say: "FFTW was designed to compute DFT for complex > numbers, like in Example 1. There is no support for DFT in the broader sense > of Definition 1. For example, we cannot use FFTW to compute the NTTs described > in the Example 2." Since you are not going to be able to solve this problem in > this GSOC project, it is better to not make such comments. 3) Yes I will solve that problem. There will be two back-ends: mine for general purposes DFTs and FFTW for complex DFTs. My back-end is half-way through I have implemented: - two versions of the mixed-radix Cooley-Tukes (aka Good-Thomas) recursively and not, - a pure Cooley-Tukey in-place which is the one in the blue line shown here: https://github.com/Lagrang3/fftx/blob/master/assets/powers-2.png That makes the back-end functional for any DFT size, with the inconvenience of the O(n^2) slow-down for prime numbers. The work to be done from now on will include the Rader algorithm (for the prime case) and further performance improvements. A funny thing about this general purpose DFT back-end is that I can test its performance against other complex-DFT (eg. FFTW). If some knows of a NTT library or the implementation of weirder DFTs to compare with, please raise your hand. > 4) Section 2.3. "scalability of the parallel MPI routines for computing > 3-dimensional DFT" , "domain decomposition" - here again I think it is worth > to remember that if the project is not going to address domain decomposition, > then it is better to not talk about it. 4) That's true. But that's a very urgent problem that we could very well solve originally within Boost. However it cannot be done until we produce a Boost FFT. Hence you get an extra motivation for doing the Boost FFT. > 5) Since this project is done under Boost, it seems logical to make sure the > proposed code work with Boost.Math complex types. Is this not part of the > plan? Why no word about it in the deliverables? 5) It did cross my mind, but I clearly forgot to talk about it. Thanks for alerting me. Thanks for the feedback. Eduardo

2 2