- (not part as gsoc) make a final decision about yapp
- stablilize and improve the code from the previous gsoc implementation (static rank and extents, subtensor)
- improve code quality using advanced and modern toolchains like cmake, clang-static-analyzer, clang-tidy, etc.
- improve code quality by enhancing the code-covarge percentage for tensor only
- improve the constexpr-ness of tensor and subtensor (finalization with C++17)
- prepare a matrix and vector data structures as an instance of tensor<T,rank=2> and tensor<T,rank=1>
- using a different branch, improve code quality using c++20 contracts and attributes for tensor, using (expects,ensure,assert) contract
- prepare for concepts
Hey Cem,
Are you sure to add contracts in uBLAS. Contracts was proposed for C++17 and did not made it up to C++20 and I have no idea when it will come to but there are some implementation of contracts TS draft by some third party compiler hackers who implement things, So I will have to compile the compiler with contract support and then test it during development. I have no problems doing it, I can see all the great places it will be used.
Will it be worth doing something that can't be directly used by other?
you are right about contracts.
In addition to the above, I was thinking of also having complete compile time tensor. c++20 has new and delete marked constexpr, so we can use std::vector container which is now compile-time and modify current to have a complete compile time tensor class. With examples and how to use it, this will be easy, if I use Amit's static extents. This is I believe an extension to the list of ideas you presented above.
yes. doumenting and stablizing the software and preparing it for matrix and vector templates would be the number one priority.
I still need your view on if I should go ahead with the contracts? Concepts are okay and So is constexpr thing!
for now, I would like to put concepts at the very end of the
Also I believe eventually if I follow up your list of ideas tensor<2, rank> can be matrix and tensor<1, rank> can become a vector and in a long run it can replace the specially designed matrix and vector of ublas. (backward compatibility could be provided thought).
yes. according to the list that is the way we should go.
We will have one expression template (YAP), C++17 or 20 everywhere, it will also make maintaining the library easy because currently tensor is a separate things and matrix and vector of ublas are separator thing.
agree.
This will also eventually give us many performance boost that David was talking about from modern paradigms of C++.
Regards
Ashar
ublas mailing list
ublas@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: cem.bassoy@gmail.com