Reputation: 398
I recently found a proof of concept implementation, which prepares features in a one-hot encoding using numpy.zeros
:
data = np.zeros((len(raw_data), n_input, vocab_size),dtype=np.uint8)
As could be seen above, the single ones are typed as np.uint8
.
After inspecting the model, I realized that the input placeholder of the tensorflow model is defined as tf.float32
:
x = tf.placeholder(tf.float32, [None, n_input, vocab_size], name="onehotin")
My particular question:
How does tensorflow deal with this "mismatch" of input types. Are those values (0/1)
correctly interpreted or casted by tensorflow. If so, is this somewhere mentioned in the docs. After googling I could not found a answer. It should be mentioned that the model runs and values seems plausible. However, typing the input numpy features as np.float32
would cause a significant amount of memory needed.
Relevance: A running but falsely trained model would behave differently after adopting the input pipeline / rolling out a model into production.
Upvotes: 1
Views: 844
Reputation: 53758
Tensorflow supports dtype conversion like that.
In operations, such as x + 1
, the value 1
is going through tf.convert_to_tensor
function that takes care of validation and conversion. The function is sometimes called manually under the hood, and when the dtype
argument is set, the value automatically gets converted to this type.
When you feed the array into a placeholder like that:
session.run(..., feed_dict={x: data})
... the data is explicitly converted to a numpy array of the right type via np.asarray
call. See the source code at python/client/session.py
. Note that this method may reallocate the buffer when the dtype is different and that's exactly what's happening in your case. So your memory optimization doesn't quite work as you expect: the temporary 32-bit data
is allocated internally.
Upvotes: 1