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.

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.

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...

_______________________________________________

ublas mailing list

[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublasSent to:

[hidden email]