Re: [ublas] Deciding on tensor parameters

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  ! :-)

[...]

Thanks,

Stefan

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