Re: [ublas] Proposal

Subject: Re: [ublas] Proposal
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-03-24 02:00:21

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

Stefan

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