Boost logo

Ublas :

Subject: Re: [ublas] Deciding on tensor parameters
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-09-13 18:34:14

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_at_[hidden] <mailto:ublas_at_[hidden]>>:
> 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  ! :-)




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