Generality via Inheritance vs. Usability via exact return types

[upsj]

Mike's discussion reminded me that I had written up some thoughts on how our interfaces (Permutable, Transposable, AbsoluteComputable, ...) are implemented:

We have some inconsistencies in Ginkgo, which I would like to collect here:

Interface vs. Mixin vs. both

We have a trade-off between generality and type-safety built into our type hierarchy. Transposable::transpose() returns a LinOp, but if we call it on a specific MatrixType, we know that it will in almost all cases return MatrixType::transposed_type. This often leads to additional as<...>(...) calls cluttering the user code.

On the other hand, we have things like get_absolute and get_absolute_linop where we explicitly provide two different return types for the same interface. I would like to find a uniform solution to address this, either by

• using a suffix LinOp operation_linop() everywhere and implementing this virtual function in terms of the type-safe local ConcreteType operation() from a mixin or
• using a more hacky "pseudo-hiding" approach with a defaulted parameter (ConcreteType operation(int = 0) hiding virtual LinOp operation()), which would lead to much nicer user code, but some warnings during compilation.

Create vs. Modify vs. Write-To vs. all of them?

We have some functions that

• create new instances like transpose() , row_permute(...) or get_absolute()
• write into an existing object like apply(..., output)
• modify an object in-place like get_absolute_inplace(...)´, add_scaled(...)`
• have multiple possible interfaces like row_gather(...), get_real/imag(...).

The perfect combination of these would look to me as follows:
We could have the best off all worlds by adding a create_operation_result(...) function that can be used to build a creating version out of a modifying version:

Result operation(...) {
    auto result = create_operation_result(...);
    operation(result);
    return result;
}

but this means adding a significant amount of additional functions, all of them in core though.

Possible solution: Free-standing functions

auto gko::transpose(const T*) -> T::transposed_type {
    return as<T::transposed_type>(T->transpose());
}```
Plus some additional SFINAE to alternatively return gko::LinOp if T::transposed_type doesn't exist

[yhmtsai]

Interface vs. Mixin vs. both

I prefer the second way if this behavior is not undefined behavior in some compiler. Does compiler have specific flag to ignore this warning?

Create vs. Modify vs. Write-To vs. all of them?

x = A->apply(b) is available for A->apply(b, x)
but is not available for advanced apply.
I do not like create_operation_result because it will lead the pretty long function name.
maybe change partial name to distinguish two version, like get_operation for returning object and compute_operation for inplace, apply_operation for apply to existing object?

Free-standing functions

It is a good idea. we can put it without any issue, but I think we still need the member function for those class.