Expression template support?

[pfeatherstone]

Is that on the agenda ?

[mhoemmen]

One can use mdspan's accessor policy to implement elementwise expression templates. P1673 does this in a limited way with conjugated and scaled.

[mhoemmen]

I'll close this for now. Please feel free to reopen or to open a new issue if you have more questions. Thanks!

[pfeatherstone]

Thanks. This work is fantastic! But I don't understand why someone hasn't got the confidence to propose a full numpy style library with linear algebra support and expression templates. Xtensor isn't perfect but it's a start.

[mhoemmen]

WG21 has limited time for reviewing large proposals. Even mdspan took a lot of time; we submitted the first version of the mdspan proposal in 2014. A good strategy for making best use of their time is to break large proposals into smaller proposals. mdspan is useful by itself. It's a common vocabulary type that many libraries can use, including the many existing C++ libraries that already do what you propose.

Given WG21's limited time, it's also important to ask why a proposal needs to be in the Standard, instead of in an easily available software library with a liberal license. We think mdspan needs to be in the Standard because

• it's a common vocabulary type that many different libraries can use to work together; and because
• putting it in the Standard gives vendors the freedom to optimize for it (in the same ways that they already optimize std::vector::operator[], such as ensuring that it can always inline).

For a discussion of expression templates, please refer to our paper P1417, "Historical lessons for C++ linear algebra library standardization." Traditional expression templates (as in Blitz++ or POOMA) imply dynamic memory allocation (unless the return type's extents are all known at compile time), because they mix container types with view types. Using auto with expression templates can also lead to dangling references. Current C++ design guidance prefers keeping views and containers separate. This is why mdspan proposes a view type, and our separate paper P1684 proposes mdarray, the corresponding container type. Our linear algebra library proposal P1673 limits the use of expression templates to read-only views, so that they cannot cause "more" dangling.

[pfeatherstone]

Thank you for your explanations. You're right that there is nothing wrong with using a library. It's just there are so many libraries out there that do matrix algebra. It's not obvious which is the best. Only a couple support tensors. Having one in the standard library sets an industry standard and it would encourage everyone to use the same thing. One might argue that's not a good thing but I think it is. These days, if you do data analysis or machine learning, having something like numpy is indispensable. It is by far the most useful tool. If on top of that, it's well optimized using techniques like expression templates, it wraps BLAS routines under the hood, and even better it supports heterogeneous platforms like GPU then that would be awesome. Even when doing more specific things like audio processing, signal processing or computer vision, at some point you will want to manipulate tensors. Having std::mdspan is a great first step ! But it only really helps library implementers, not real users. The Eigen developers will probably won't care. XTensor people probably already have something similar implemented. Maybe the Pytorch or Tensorflow folks will peak a look, but they are pretty committed to only requiring C++14, maybe at a stretch C++17. So the only way to kick things off is to target users directly. I'm not convinced a view type alone hits the mark. I can appreciate it's a huge amount of work. But it doesn't need to be perfect first time round. Just settle on an ABI, then library vendors can optimize with every release. Maybe it will be useful for brand new libraries. But I don't see organizations or tools changing their underlying tensor dependency from Eigen or whatever to yet another new library. It works so why change. IF however, it's in the standard, then obviously, the best practice would be to use what's in the standard library.

But I don't know. I'm not a language or library expert, so what do I know. I got excited about this initially, then i noticed it still doesn't allow me to write something resembling real maths and concluded it would only affect library implementations. In my view, the only way this kind of stuff is going to directly impact and benefit users, is to have something like numpy in std.

Increasingly, it seems the standard library is being filled with things that only language experts will use. What's wrong with having useful things for day-to-day users.

As for the dangling reference thing, the answer is easy, don't use auto. Always evaluate to a tensor object not tensor_expression or whatever the library calls it.

Sorry if this comes across as a negative rant. I think this is great! It's just, it will take another 30 years before a full linear algebra tool is in the library.