happy to have you back.
Hi
My name is Ashar, a pre-final year undergraduate student. Last year I worked with Boost.uBLAS and added Boost.YAP Expression template and another student Amit added some new interfaces like subtensor view and other really cool things.
They are! Indeed.
During the development and addition of new YAP based ET, I did faced many issues with the legacy C++ code in matrix and vectors, this was more pronounced as Boost.uBLAS.tensor was targetting C++17 and rest of the uBLAS had C++11 or earlier code. The new project about C++20-ification of Boost.uBLAS seems a really nice step towards creating a more unified and standardized experience across all 3 types (vector, matrix, tensor) also we can experiment if C++20 does makes things faster or not.
I have been following C++20 since its first draft (July 2017, Toronto) and now that it has been finalized, I have tested and experimented with most of its features with clang/gcc/trunks. So, I believe this makes me a potential candidate for this project.
I am interested in working in this project and Here are some of the ideas in general that I have toward C++20-ification of uBLAS.
Very happy about that. Let me go through your list.
1. concepts : We have so many type_traits.hpp and all those legacy traits which can be really replaced by new concepts. It will make template type errors really short and nice to debug.
Agree. I would like to slowly approach this topic and start with it when the tensor data type with subtensors are finalized.
2. The one ranges : Eric Neibler's one ranges will be very nice to have in uBLAS, we currently have iterator based abstraction but since ranges are the new way to interact with containers in C++20, addition of this will really make uBLAS one of its kind in Linear algebra. Further more, Amit's work can be used here and we can have views and adapter (only for tensor upto now).
This topic might be too early for an investigation right now. Once subtensors are included in boost we should try to
3. std::span : Span are used widely in linear algebra and with C++20, Standard has added it. Albeit uBLAS has its own span and extents it will be very good to make them compatible or interoperable with standard spans.
std::span and boost::numeric::ublas::span have different meanings. The latter is used for tensor selections with three member variables while the other is refering to a static or dynamic memory region with a pointer to the memory region and its length. Still std::span could be a good use for ublas.
4. Constexpr-ification : C++20 made so much things constexpr, try/catch to even dynamic containers like vector and strings. We can really leverage the new constexpr abilities like memory allocation and freeing to build a really awesome constexpr vector/matrix/tensor interfaces.
This is a good point. I think that C++17 gave us already the right opportunities.
5. Modules : Finally we got rid of leaky include directives, making uBLAS modules based will be I think the first library in Boost to have it.
We should see how and when the boost community switches to modules.
6. New Tool-chains : Travis CI is used for CI and its at best cannot give over 18.04LTS for jobs, Setting up CI with modern tool-chain to build and run C++20 will also be a job of its own.
Oh. I am totally for stabilizing our current development branch. This is something ublas needs to do.
7. Misc: spaceship operator and other minor changes like feature/test-macros and other minor topping that comes with C++20 can be used really nicely.
I am also very aware of that all these can take much more time than what we get in GSOC, but I will choose and prioritise the task, I have just proposed some new things that I would like to add if given a chance to work on it. I have intensionally left coroutines and other features because I can't find any practical use of those features for uBLAS. If you have some ideas, how we can use it to improve then please its welcomed.
Cem and David are the mentors that I am seeking and I will be submitting my C++20 competency test to one of you very soon. Please consider this as official application email and we can always further discuss and finalize the direction of the work directly.
All in all I find the inclusion of most C++20 features very important - yet too early. We already made a huge step with C++17.
Therefore, my suggestion for ublas is to name this gosc project (stablizing and improving code quality ublas) :