On 2018-09-13 02:06 PM, Cem Bassoy via ublas wrote:

Am Do., 13. Sep. 2018 um 18:12 Uhr schrieb Stefan Seefeld via ublas <ublas@lists.boost.org>:

On 2018-09-13 11:34 AM, Cem Bassoy via ublas wrote:

We would only need to specify and implement one data structure ' tensor ' and if needed provide optimized functions for matrices. This simplifies the maintenance.

A big advantage (which has been my main motivation for pushing for this solution) is that such a scenario would be fully in line with the existing Boost.uBLAS API, so your work becomes a natural extension of what we already have.

I think, just the contrary is the case. There would be no extension to the old dense matrix class template, as the new alias template would replace the old one because we cannot have the identifier in the same namespace. In the above case, we need to port all vector and matrix functions for the new tensor type. The vector and matrix class templates are not alias templates but are distinct class templates. If I am not mistaken, adding the tensor as a class template as it is right now would be the uBLAS way.

I think I may have expressed myself poorly. Yes, I agree: with your approach you would introduce new "matrix" and "vector" types (as template aliases). It is my hope however that we could use those as drop-in replacements for the old matrix and vector classes, i.e. I would like to simply replace those (assuming of course that they are sufficiently API-compatible to make this possible). In that case, no other code (such as stand-alone functions / operators taking vector and matrix arguments) would need to change.

Of course, if we need to port code over, it's a sign that the old and new types aren't API-compatible, so this becomes a bigger question (as it also affects users). Again, my assumption was that we could come up with a new API that was backward-compatible.

Alternatively, if you keep the rank a runtime parameter, you are basically proposing an entirely new API, which means that Boost.uBLAS users will have to decide whether to use the old or the new API, which I'm afraid will result in a fragmentation of the community. Likewise, many existing operations only support existing vector and matrix types, so maintainers will have more work to do to support both APIs.

That, to me as library maintainer, is a very high cost, so I'm reluctant to such a change, even if the proposed API with runtime ranks is otherwise sound.

Yes agree with you on that point.

Glad to hear that ! :-)

[...]

Thanks,

--

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