[ublas] Proposal

Stefan Seefeld via ublas

2018-03-24 02:00:21 UTC

Post by Cem Bassoy via ublas
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.

Post by Cem Bassoy via ublas
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.
- 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.

Post by Cem Bassoy via ublas
- 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.
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.

Post by Cem Bassoy via ublas
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
<https://arxiv.org/abs/1711.10912>

Thanks, I'll have a look.

Post by Cem Bassoy via ublas
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,

Stefan

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