- Boost - lists.boost.org

[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

[lambda2] Andrzej's review
by Andrzej Krzemienski 02 Apr '21

02 Apr '21

Hi Everyone, I recommend to REJECT Boost.Lambda2 library in its current form. My opinion is not very strong, and it is based on the perceived trade-off between usefulness and technical problems. I acknowledge that there are practical use cases that the library can address, that are not provided in documentation. (I recommend that examples with pointers, and maybe a complex one with column-oriented design be added). I consider the ADL issue that Barry pointed out a serious one. This will be an additional place where users would suddenly be caught by a magical problem that they will spend hours understanding. I think that the main problem here is that Boost.Lambda2 defines the operators that should belong to namespace std::placeholders. I also note that if this was added to the Standard Library, the problem would be nonexistent, because they would reside in namespace std. Could I propose an alternative design. Add placeholders _1, _2, ... into namespace `boost::lambda2::placeholders` specialize std::is_placeholder` for them, so that `std::bind` can recognize them. Add operators in the same namespace. Then, recommend the following usage of the library: ``` using namespace boost::lambda2::placeholders; void fun() { auto pred = std::bind(_1, &Employee::name) == std::bind(_2, &Employee::name); } ``` This single using directive would make both `std::bind` and Boost.Lambda2 operators work. I would find such a library acceptable. And in fact I could make it a condition for a conditional acceptance. Now, the standard questions: > - What is your evaluation of the design? > I object to the choice to add operators for placeholders from one namespace (std::placeholders) into another namespace (boost::lambda2). Save for that, I find anything else good. - What is your evaluation of the implementation? > Very sweet and clean. I only expect other operators to also work. But Peter already explained that this is his plan. - What is your evaluation of the documentation? > This library doesn't require much documentation of the interface. But I fill it is missing the Motivation section. I would expect to see practical examples: not long ones, but ones that I will find in real programs, like dealing with pointers. - What is your evaluation of the potential usefulness of the library? > Others have convinced me that it will find sufficient application in real programs. - Did you try to use the library? With which compiler(s)? Did you > have any problems? > I tried to reimplement it, and played with some toy examples in Wandbox. (newest GCC). It worked fine. - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I was able to reimplement it, read the entire implementation (which was not difficult: it is like seventy lines). I spent like three hours in total studying it. - Are you knowledgeable about the problem domain? > I used Boost.Lambda and Boost.Bind in the past. Finally, I would like to thank Peter for writing and sharing this library. Regards, &rzej;

3 9

Idea Suggestion for GsOC'21
by Sanyam Bhaskar 01 Apr '21

01 Apr '21

Hey! This is Sanyam Bhaskar. I read over the default Ideas provided to us and XML Parser really caught my eye. I would like to contribute to the same but don’t know where to start. Also, as per my understanding, XML is relatively outdated , when compared to data languages like JSON. So in addition to this being an XML Parser, I think adding a JSON parser alongside it would boost the library’s utility in the modern day industry. I Would appreciate it if someone could tell me how to get started and some feedback on the suggestion. Looking forward to contributing to the project. Yours, Sanyam Bhaskar

4 7

[range] the strange behavior of adjacent_filter
by Andrzej Krzemienski 31 Mar '21

31 Mar '21

Hi everyone, Boost.Range has two GitHub issues on the strange behavior of adjacent_find that have been sitting there for more than two years: https://github.com/boostorg/range/issues/80 https://github.com/boostorg/range/issues/81 The behavior of the algorithm is not well described, but the intuitive expectation would be that it returns for every pair of adjacent elements that match the predicate the second of the pair. However, the unexpected behavior of the algorithm is that for a non-empty range it literally always returns the first element. I do not think that this is by accident, because Ranges V3 also expose the same behavior: https://godbolt.org/z/P33j1qvT6 Does anyone happen to know the reasoning or motivation behind this behavior? Regards, &rzej;

1 0