|
|
Ublas : |
Subject: Re: [ublas] Deciding on tensor parameters
From: Cem Bassoy (cem.bassoy_at_[hidden])
Date: 2018-09-13 19:44:24
Am Do., 13. Sep. 2018 um 20:35 Uhr schrieb Stefan Seefeld via ublas <
ublas_at_[hidden]>:
> 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]>:
>
>>
>> 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.
>
Yes. I think it would be mostly adjusting the free functions the alias
template.
>
> 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.
>
Hmmm, backward compatibility could be a bit more difficult in this case.
There are so many iterators inside those classes. We do not need them. At
least only, not on this level I think. So if we agree on tensor class
template with a static rank using alias templates for matrix and vector,
means that we would provide a new api with the same functionality but
better usability?
>
>
>
>>
>> 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 ! :-)
>
So I will wait for more opinions before continuing to adjust the tensor
class template.
Cheers
C
