[Dune-devel] Tensor data structures and operations on tensors

[Simon Praetorius]

Thanks Christoph for your feedback.

> year suggestion reads neat! I would like to get a unified data type 
> for vectors and matrices. Just be sure: The core of the data structure 
> is an unmodified mdarray/mdspan as it is proposed to C++23 or some 
> later version. You just added some helper functions to get 
> mathematical operations done, right? Thanks for all the effort you put 
> into this!
First of all, you are right. As also mentioned in the README, I have 
started to implement the proposals mdspan and mdarray, very closely. 
These utilities are in itself already very useful. And it is not yet 
clear when they will be in the c++ standard and then when it will be 
implemented by the standard libraries. It looks like mdspan will be in 
c++23, not yet sure about mdarray (I hope so too), but, e.g., submdspan 
will probably not be in 23, maybe in 26. Until we can use these tools in 
the core modules it will be another 5 years.
>
> In the long run, this could lead a central data structure to be 
> compatilbe across the C++ world compared to a bunch of Dune-specific 
> classes.
Yes. It need to be checked how well the proposals (and later the actual 
specification) is followed by the Tensor implementation. Then, maybe it 
can be a drop-in replacement by mdspan and mdarray and so on.
>
> In general, I support your suggestions. I would wait with adding it to 
> Dune core until mdarray/mdspan are voted into the standard. Not sure 
> how to make a transition. Could be, that we have the old and the new 
> classes living peaceful side by side for a long time. Would we okay 
> for me.

Currently we are using std::vector and std::array and so on in our own 
data structures. It is not needed to reimplement all this. I hope in the 
future we could simply drop some of the Tensor implementation and use 
the standard implementation instead. That is why I tried to be close to 
the proposal. But, currently there are a few differences

- I have implemented extents with signed integer. This allows to have 
something like co-/contravariant tensors by positive/negative "extents", 
I called it "types". Note, the actual extents are always >= 0. This 
change also means that the 
`tag::dynamic=std::numeric_limits<int>::min()` has a different value 
than `std::dynamic_extent=size_t(-1)`
- The `TensorSpan` does not have an AccessorPolicy (yet). This might be 
a useful extension later, e.g., to have atomic access, maybe unit-aware 
access.
- I have not included all the very recent changes in the proposals, 
e.g., replace size_type by (possibly signed) index_type
- The utilities are not yet tested with and prepared for SIMD/Vc types, 
but this is something that should be investigated.

Also, the repository contains some implementation of ranges utilities 
and span, like std::span. All these are in c++20, but we do not yet have 
this in the support list of the compilers. It is useful to have these 
utilities to implement operations with tensors. Some replacements we 
have in the dune-common repository (e.g. transformedRangeView) but this 
is incomplete, e.g. you cannot implement a 
zip-iterator-adapter/zip-range-view with this.

I have learned a lot from these standard library proposals. For some of 
our dune utilities, it would be helpful to also have a more precise 
specification. E.g., the ReservedVector can learn something from the 
`std::static_vector` proposal, or the corresponding boost 
implementation. All this should be combined with proper (performance) 
testing.

>
> Bye
> Christoph
>
-- 
Dr. Simon Praetorius
Technische Universität Dresden
Institute of Scientific Computing
phone: +49 351 463-34432
mail: simon.praetorius@​tu-dresden.de