Survey for Tensor Type names

[karl.l...@gmail.com]

Having trouble viewing or submitting this form?

Fill out in Google Forms

I've invited you to fill out a form:

Survey for Tensor Type names

In TF Java, we are now using our own classes for identifying the datatype of a tensor or an operand instead of relaying on Java boxed types (e.g. `Tensor<TInt32>` instead of `Tensor<Integer>`). The main reason is that these tensor types now carry more information that allows us to access directly the tensor data in a n-dimensional space directly from Java. Currently, float32 and float64 have preserved their former boxed type name (i.e. `TFloat` and `TDouble` respectively), while int32 and int64 has been renamed to `TInt32` and `TInt64` from `Integer` and `Long` to match the type names in Python, which is now a bit inconsistent. As I'm about to add a new datatype (float16), I would like to fix this inconsistency as well and rename `TFloat/TDouble` to `TFloat32/TFloat64`, which also match Python type names. But since they are very frequently used data types, I would like to know your opinion before applying this change. NOTE: The `T` prefix in the type class names stands for `Tensor of`, since an instance of one of these classes is a full n-dimensional array of data and not a single value.

Should we still try to match tensor types with Java equivalent types when they exist or should we try to match typenames in Python? * Match Java types whenever possible, so rename `TInt32/TInt64` to `TInteger/TLong` Match Python names, so rename `TFloat/TDouble` to `TFloat32/TFloat64` Other: Never submit passwords through Google Forms. Powered by This content is neither created nor endorsed by Google. Report Abuse - Terms of Service - Additional Terms

Create your own Google Form

[Karl Lessard]

Hi everyone,

So here's the result of the survey, it looks like having explicit floating-point type names like in Python (float32, float64...) is preferred (by close) by the group. I'll apply the changes now, thank you for your participation!

- Karl

--
You received this message because you are subscribed to the Google Groups "SIG JVM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jvm+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/jvm/000000000000f9a152059bbfbf01%40google.com.

[Samuel Audet]

One question: The types in Python are not prefixed with "t". Why do we need it in Java?

2020年1月15日(水) 0:50 Karl Lessard <karl.l...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/jvm/CAKr7cSmcS1V5_ME8YBL1iJxzYz_bnPk5s_MMaB3PZf%3DDe9Pt_A%40mail.gmail.com.

[Karl Lessard]

While we should ultimately end up with the same list of types in Java and in Python, their usage is a bit different. 

In Python, variables are not typed, so float32 is only used as a datatype identifier, like an enum (e.g. at tensor creation). In Java though, we also use it as a concrete type for accessing the tensor data directly from the JVM, like in here:

Tensor<TFloat32> tensor = TFloat32.ofShape(2, 2);

TFloat32 data = tensor.data(); // data is a 2-dimensional array of float32

Since data is a multi-dimensional array, it would not make sense that its type be simply Float32. 

The usage of a simple prefix is less explicit but reduces considerably the verbosity of the code since this type appears very often in common TensorFlow Java code (i.e. Tensor<TFloat32> vs. Tensor<Float32TensorData>).

Also, we might intuitively think that the tensor.data() method could return a generic type, like NdArray<T>, but for various reasons that is not possible neither. Let me know if you want me to go more in details explaining why.

- Karl

[Samuel Audet]

Hum, I must be missing something about the design of the API, but it sounds like there's a good reason behind this, so I'll leave it at that :)

Samuel