Provide limited support for tensors of typed dimensions

[kaifox]

As noted recently by Andrea, one limiting factor, which might bring fear to new users, is the fact that dimensions are never typed and that also the number of dimensions is never known when using a tensor ....

In early designs such things were tried, but always led to horrible "generic" monsters, so it was decided to give this up at that time....

However, since now a core functionality is well established and proves to be useful.... probably it is time to rethink this approach and add limited 'typed tensors' sugar on top of the existing....

For sure we should follow an approach, where all the utility methods always only act on Tensors (only the value is typed). Otherwise, we will have an explosion of methods .... However, we could potentially have e.g. typed tensors (and builders) up to a limited number of dimensions...

[michi42]

Great effort! In principle I like the idea, however, there is one not-so-nice thing when using Java Generics for typing the dimensions - the type arguments for Generics are ordered, while (traditionally) our dimensions are not. For instance, a TypedTensor2D<C1,C2,V> is fully compatible with a TypedTensor2D<C2,C1,V> at the level of Tensorics, but obviously the two type signatures are not.

However, I don't have a clever solution for this yet. I'm wondering if compile-time annotation processing and Tensorbackeds could be a viable alternative to Generics for dimension typing ...

[kaifox]

I agree... The Ordering is artificial in this case ... However, one could accept this I think, by explicitely documenting this feature ... Indeed the two tensors you mention are equivalent (to be checked by the way .. I doubt that the equality holds at the moment).

BTW: I just tried and indeed, the following still works with the proposed implementation:

Tensor2D<C1, C2, V> tensor = ...// instantiation omitted

V value1 = tensor.get(c1, c2); // obvious; calls get(C1, C2)

V value2 = tensor.get(c2, c1); // this still works! Calls get(Object ... coordinates)

, because the Tensor1D inherits from Tensor ... and still provides the get(Object... coordinates) method.... I think its not that bad ;-)

Compiletime annotation processing is nice ... but always comes with the (in my opinion) big drawback that you need particular arguments for your compiler (and each ide...).... I finally always refrained from libraries requiring this .... so I fear that others do also ....
... but to be considered ...

Another problem, not mentioned yet in this thread, is one which was there all the time, but becomes much more prominent if we provide this typed coordinates, is this one (I dedicated a separate issueto it): #38 .
Indeed, I think this has to be solved together, otherwise things get unhandy ... but on the other hand, I think it opens things for future extensions....

[kaifox]

Another question is of course, where to stop the 'limited' support ...
Imagine reduction: A Tensor3D<C1, C2, C3, V> would be reduced to a Tensor2D ... however each reduction method would need 3 variants (assuming something like mentioned in #34) :

Tensor2D<C1, C2, V> t1 = reduce(tensor).avarage(C3.class).toTensor();
Tensor2D<C1, C3, V> t2 = reduce(tensor).avarage(C2.class).toTensor();
Tensor2D<C2, C3, V> t3 = reduce(tensor).avarage(C1.class).toTensor();

... not sure if this is handlable ... we always can exclude this from the 'support' ... but for sure it might come up ;-)

[kaifox]

As discussed today: I think we agree that we will give it another try to rather provide typed Tensorbacked support than typed Tensor support ... In these cases, the tensorbackeds will usually anyhow have dedicated classes (interfaces) and it might be less confusing to have ordered dimensions in them. Tensors will (for the moment) remain untyped in dimensions.

What we still can learn from the previous exercise:

• The concept to only base the hierarchy on interfaces seems to be promising.
• We will try to apply this to tensorbackeds: This should simplify tensorbacked classes and also avoids that tensorbackeds contain additional state (except the tensor itself).
• First try should be to refactor this branch into that direcion

[kaifox]

First Notes concerning the ongoing refactoring

In the end, the proposed treatment of tensorbackeds is as follows:

To be able to be instantiated as a tensorbacked object, the class has to either

• Inherit from AbstractTensorbacked and have an accessible constructor with one single argument of type Tensor. (This is status quo)
• Be a pure interface (this is new). In this case, the instance will be a pure proxy.

The required dimensions will be determined by either of the following

• @Dimensions Annotation (status quo)
• Inheriting from one of Tensorbacked1D, Tensorbacked2D, .... (This is new)
  This OR is exclusive! If both are given, then an exception shall be thrown, as the information might be redundant in the best case, but contradicting in the worst case....

In the tensorcis class we will have additional factory methods for builders of typed tensorbackeds:

TensorbackedBuilder1D<C1, V, A1DTensorbacked> builder = Tensorics.builderFor(A1DTensorbacked.class);
TensorbackedBuilder2D<C1, C2, V, A2DTensorbacked> builder = Tensorics.builderFor(A2DTensorbacked.class);
....

'Anonymous' tensorbackeds of typed dimensions could be built like:

TensorbackedBuilder1D<C1, V, Tensorbacked1D<V>> builder = Tensorics.builderBacked1D(C1.class);
TensorbackedBuilder2D<C1, C2, V, Tensorbacked2D<V>> builder = Tensorics.builderBacked2D(C1.class, C2.class);
....