On 23.03.2018 17:43, Cem Bassoy wrote:

Hi Stefan,

thanks for your interest.
actually I did not want to really change any type system but only follow the taxonomy of uBLAS.

I took the definitions provided by uBlas docu for matrix and vector concepts and adjusted those for tensors. See http://www.boost.org/doc/libs/1_66_0/libs/numeric/ublas/doc/container_concept.html.

Yes, it seems well compatible with those concepts. But as far as the actual `vector` and `matrix` class templates are concerned, it differs significantly. (New template parameter signatures, notably.)
Again, I'm not at all opposed to what you are proposing. I'm simply asking how you envision to incorporate your changes into the existing code.

A multiarray concept has been already developed in http://www.boost.org/doc/libs/1_63_0/libs/multi_array/doc/reference.html#MultiArray I think the only new concept is the multidimensional iterator. This will be difficult to develop. But we do not need it for first shot of the library. It would just be consistent with the current uBlas version. If I am not wrong even matrix operations provide iterators, see http://www.boost.org/doc/libs/1_66_0/libs/numeric/ublas/doc/matrix_expression.html#41UnaryOperationDescription. Not sure if we need that.
So I only wanted things to be consistent, at least for the proposal.

In short, programming-wise I think:

- tensor template class is a must.

Note that there is a potential terminology mismatch: You are using the term `tensor` as an abstract multi-linear container, of which `vector` and `matrix` are one- and two-dimensional specializations respectively. The other use of the term (which I thought was the intent in the original project) was the three-dimensional specialization of the generic term, i.e. a three-dimensional extension of vectors and matrices.

Again, I actually like the idea of an abstract multi-dimensional base, such that `vector` merely becomes a "template alias". But it's important to consider the implications for such a profound change in terms of code stability, backward compatibility, and simply the amount of work that's involved.

- tensor expression templates, entry wise tensor operations and tensor unfolding are a must.

- iterators are nice to have.

- tensor slices and views are a nice to have.

- in-place tensor contractions are also nice to have.

- efficient in-place tensor contractions are really hard to implement.

We would need to agree on :

what tensor parameter do we want to be compile-time or runtime variable?

do we want the same flexibility as boost::numeric::matrix or boost::numeric::vector?

Right, as well as other questions.

I have already implemented a tensor library without expression templates (runtime-variable rank, dimensions and even storage format). However almost all of the tensor operations I have described in the proposal are implemented. However, the interface needs to be adjusted really as I did not use expression templates. You can read about the library and concepts in: https://arxiv.org/abs/1711.10912

Thanks, I'll have a look.

I would like to start to contribute to the boost community and hopefully try to write a paper about it, similar to the authors of Boost.MultiArray. See https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.630
I think this might be a good start. Of course in future, I would love to add a full library which will cost more time.

I hope I could answer some of your questions.

You did, thanks. I suggest you cast your ideas into a project proposal, submit it as a draft, then we can discuss there how to frame that in a way to maximize chances that this will succeed as a GSoC project.

Cordially,

-- 

      ...ich hab' noch einen Koffer in Berlin...