You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each of them has their specific 'uglyness':
(1) is just annying for tensors with only a few arguments, where the chaining of the methods would be simply convenient ... assigning to a dedicated variable is just boilerplate.
(2) for example does not allow to have a static import to the builer() method ... it always requires the 'Tensorics' class in front ....
Both now become much more prominent, in case we decide to introduce limited support for typed coordinates (#36). In this case in both cases the lines will be polluted by a lot of generics arguments ... so in this cases, it would give more value to work on this problem.
One idea, which also plays in the direction of other issues would be something like explicitly giving the type of the value of a tensor. Imagine something like:
This might not look like a gain at the first glance... however... imagine, we introduce a shortcut, so that the first put(....) method further specifies the value type (lets call the returned object beforehand a 'PreBuilder` for the moment:
Tensor<Double> tensor = Tensorics.builder(C1.class, C2.class) // <PreBuilder<Object>> (or not type parameter at all )
.put(at(c1a, c2a), 0.0) // Builder<Double>
.build();
... still does not look impressing, I know ...
However, if we look at other issues we have, for example that we are considering introducing specific tensor implementations for certain types (e.g. preferred dimensions - #11 - or even for certain value types - e.g. double array backed -) ... this could be a potential solution: Whenever the first put() method is called, the PreBuilder manifestates into a builder of an appropriate implementation as best guessed by the arguments given so far (e.g. max number of values, ordering of dimensions ...)....
... just thoughts ;-)
The text was updated successfully, but these errors were encountered:
kaifox
changed the title
Builder Value Type is not well defined after builder(Class<?> ...) method ...
Builder Value Type is not well defined after builder(Class<?> ...) method ... Consider PreBuilders
Dec 2, 2018
Unfortunately, with the current implementation, it is not possible to create a tensor by writing something like:
The reason for this is that the compiler cannot guess the type of the value after calling the builder(..) method.
Currently, there exist 2 workarounds:
Each of them has their specific 'uglyness':
(1) is just annying for tensors with only a few arguments, where the chaining of the methods would be simply convenient ... assigning to a dedicated variable is just boilerplate.
(2) for example does not allow to have a static import to the builer() method ... it always requires the 'Tensorics' class in front ....
Both now become much more prominent, in case we decide to introduce limited support for typed coordinates (#36). In this case in both cases the lines will be polluted by a lot of generics arguments ... so in this cases, it would give more value to work on this problem.
One idea, which also plays in the direction of other issues would be something like explicitly giving the type of the value of a tensor. Imagine something like:
This might not look like a gain at the first glance... however... imagine, we introduce a shortcut, so that the first
put(....)
method further specifies the value type (lets call the returned object beforehand a 'PreBuilder` for the moment:... still does not look impressing, I know ...
However, if we look at other issues we have, for example that we are considering introducing specific tensor implementations for certain types (e.g. preferred dimensions - #11 - or even for certain value types - e.g. double array backed -) ... this could be a potential solution: Whenever the first put() method is called, the PreBuilder manifestates into a builder of an appropriate implementation as best guessed by the arguments given so far (e.g. max number of values, ordering of dimensions ...)....
... just thoughts ;-)
The text was updated successfully, but these errors were encountered: