|
|
Ublas : |
From: Cem Bassoy (cem.bassoy_at_[hidden])
Date: 2020-03-16 10:49:53
Hi Ashar,
happy to have you back.
While 20++-ification is a necessary step for uBLAS, we have to be cautious
as many features of the 20++ standard are not even implemented yet, see
https://en.cppreference.com/w/cpp/compiler_support.
Am Fr., 13. März 2020 um 19:10 Uhr schrieb Ashar via ublas <
ublas_at_[hidden]>:
> 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) :
1. (not part as gsoc) make a final decision about yapp
2. stablilize and improve the code from the previous gsoc implementation
(static rank and extents, subtensor)
3. improve code quality using advanced and modern toolchains like cmake,
clang-static-analyzer, clang-tidy, etc.
4. improve code quality by enhancing the code-covarge percentage for
tensor only
5. improve the constexpr-ness of tensor and subtensor (finalization with
C++17)
6. prepare a matrix and vector data structures as an instance of
tensor<T,rank=2> and tensor<T,rank=1>
7. using a different branch, improve code quality using c++20 contracts
and attributes for tensor, using (expects,ensure,assert) contract
<https://www.modernescpp.com/index.php/c-core-guidelines-a-detour-to-contracts>
8. prepare concepts
Best,
Cem
> Regards
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: cem.bassoy_at_[hidden]
>