Issues when translating from TType to TNumber and parameterized types within methods.

Many of the Java TF Ops use parameterized types for either TType, TNumber or both. Sometimes an Op uses <T extends TType> and sometimes another Op is using <T extends TNumber>. When writing a method that uses two different Ops that declare <T> differently, the compiler complains that T cannot be converted to the other type. It is interesting that TNumber is a subclass of TType. I have searched "Professor Google", but have not found an answer to this kind of problem.

TType to TNumber conversion is very common, especially if you are creating a base class with a common method signature across many similar objects. Sometimes, the subclass calls for a TType, sometimes a TNumber. The real problem, is when you have a common method such as public <T extends TType> Operand<T> call (Operand<T> input).

As a work around, let's say that you cast a TType to a TNumber (where <U extends TNumber>) as in:

@SuppressWarnings("unchecked")
Operand<U> uInput = (Operand<U>)input;

Now when you call something like tf.math.greater(uInput, otherValue);, the compiler complains:
no instance of type variables(s) exists so that T conforms to TNumber. That is because tf.math.greater uses <T extends TNumber> while other ops, like tf.nn.relu defines <T extends TType>.

Another way around this is to force erasure as in (Operand)value.

At a minimum, it would be nice if there were a convention like <T extends TType> and <U extends TNumber> consistently, but this may not solve all these kind of issues, as I have seen <U extends TType, T extends TType>, and <V extends TType, T extends TType, U extends TType>

The main issue that contributes to this problem is that the Ops require a mixture of types, so a higher level user is artificially juggling the situation by casting like above, or by forcing an erasure of the type.
IMO this situation is going to be confusing to the API user. I still haven't figured out a clean way to get around the issue when two method signatures use the same generic parameter in different ways.

Perhaps there is a better way. My gut feel is this is going to become a larger headache down the line.

The specific example I am running into at this time this problem is:

@Override
    public Operand<T> call(Operand<T> input) {
        @SuppressWarnings("unchecked")
        Operand<U> uInput = (Operand<U>)input;
....
        Operand<U> greater = tf.dtypes.cast(
                    tf.math.greater(uInput, 
                            tf.dtypes.cast(tf.constant(threshold),  
                            input.asTensor().dataType())), input.asTensor().dataType());
         uInput = tf.math.mul(uInput, greater);
         input = (Operand<T>)uInput;
...

Aucun fichier ni test n’est nommé. Commencez par retracer les signatures Java TF Ops de tf.math.greater, tf.nn.relu, tf.dtypes.cast et tf.math.mul, ainsi que Operand, TType et TNumber dans l’exemple. Le travail est terminé lorsque l’incohérence de l’API générique est résolue ou clairement documentée avec une approche qui compile et évite les casts non sûrs et l’effacement des types.