Introduction

This TensorFlow error happens when code tries to reuse a variable name but asks for a different dtype than the one already stored in the graph. In practice, the fix is to make variable creation and reuse agree on one dtype, then cast inputs at the edges instead of letting mismatches leak into get_variable.

Why the Error Happens

tf.compat.v1.get_variable looks up variables by name inside the current variable scope. If a variable already exists and you reuse it, TensorFlow expects the shape and dtype to match the original definition. If you created var as float64 and later request var as float32, TensorFlow refuses because that would silently change the graph contract.

Here is a small example that reproduces the problem:

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5graph = tf.Graph()
6with graph.as_default():
7    with tf.compat.v1.variable_scope("demo"):
8        tf.compat.v1.get_variable(
9            "var",
10            shape=[2],
11            dtype=tf.float64,
12            initializer=tf.compat.v1.ones_initializer(dtype=tf.float64),
13        )
14
15    with tf.compat.v1.variable_scope("demo", reuse=True):
16        tf.compat.v1.get_variable("var", shape=[2], dtype=tf.float32)

The first block creates the variable as float64. The second block tries to reuse the same name as float32, which triggers the error immediately while the graph is being built.

Fix the Variable Definition, Not Just the Symptom

The right fix is usually to standardize the variable dtype at creation time and make the rest of the graph conform to it. In most TensorFlow models, float32 is the best default because it is faster and more memory-efficient than float64.

1import tensorflow as tf
2
3tf.compat.v1.disable_eager_execution()
4
5graph = tf.Graph()
6with graph.as_default():
7    with tf.compat.v1.variable_scope("demo"):
8        weights = tf.compat.v1.get_variable(
9            "var",
10            shape=[2],
11            dtype=tf.float32,
12            initializer=tf.compat.v1.ones_initializer(),
13        )
14
15    with tf.compat.v1.variable_scope("demo", reuse=True):
16        same_weights = tf.compat.v1.get_variable("var", shape=[2], dtype=tf.float32)
17
18    print(weights.dtype)
19    print(same_weights.dtype)

Once the dtype is consistent, reuse works as intended.

Cast Incoming Data Before It Touches the Variable

Sometimes the variable is correct and the real problem is that upstream NumPy data defaults to float64. That is common because NumPy arrays created from plain Python floats usually become float64 unless you specify otherwise.

1import numpy as np
2import tensorflow as tf
3
4tf.compat.v1.disable_eager_execution()
5
6x_np = np.array([[1.0, 2.0], [3.0, 4.0]], dtype=np.float64)
7x = tf.cast(x_np, tf.float32)
8
9with tf.compat.v1.variable_scope("demo"):
10    w = tf.compat.v1.get_variable(
11        "w",
12        shape=[2, 1],
13        dtype=tf.float32,
14        initializer=tf.compat.v1.ones_initializer(),
15    )
16
17    y = tf.matmul(x, w)

Casting inputs at the boundary is cleaner than letting mixed dtypes spread through your model code.

Watch Variable Scopes and Reuse Logic

This error often appears in old TensorFlow 1.x style code where helper functions create variables under reusable scopes. The problem is not always the visible dtype= argument. Sometimes one helper creates a variable with float64 because it inherits a tensor dtype, while another helper later tries to access the same name with an explicit float32.

A defensive pattern is to pass the dtype as a function argument and use it consistently:

1import tensorflow as tf
2
3def dense_weights(name, in_dim, out_dim, dtype):
4    return tf.compat.v1.get_variable(
5        name,
6        shape=[in_dim, out_dim],
7        dtype=dtype,
8        initializer=tf.compat.v1.glorot_uniform_initializer(),
9    )
10
11tf.compat.v1.disable_eager_execution()
12
13with tf.compat.v1.variable_scope("model"):
14    w1 = dense_weights("hidden", 4, 3, tf.float32)
15
16with tf.compat.v1.variable_scope("model", reuse=True):
17    w2 = dense_weights("hidden", 4, 3, tf.float32)

This makes dtype decisions explicit instead of accidental.

Prefer Modern TensorFlow Patterns in New Code

If you are writing new TensorFlow code, avoid building around tf.compat.v1.get_variable unless you are maintaining a legacy graph-based model. Keras layers manage variable creation for you and reduce the chance of scope and dtype conflicts.

1import tensorflow as tf
2
3layer = tf.keras.layers.Dense(4, dtype="float32")
4x = tf.constant([[1.0, 2.0]], dtype=tf.float32)
5y = layer(x)
6
7print(y.dtype)

That does not remove dtype issues entirely, but it moves variable management into a more structured API.

Common Pitfalls

The most common cause is NumPy creating float64 data while the model expects float32. Another repeated issue is reusing a variable scope in helper functions without making dtype a deliberate parameter. Developers also copy old TensorFlow 1.x snippets that mix tf.float64 initializers with tf.float32 placeholders, which builds a graph that is inconsistent from the start. Finally, some fixes only change the second get_variable call and leave the original variable definition untouched, so the error returns as soon as that code path runs again.

Summary

• This error means TensorFlow found an existing variable name with a different dtype than the one you requested.
• Pick one dtype for the variable, usually float32, and keep reuse calls consistent with it.
• Cast NumPy arrays and other inputs before they flow into the graph.
• Make dtype an explicit part of helper APIs when variable scopes are reused.
• Prefer modern Keras layers for new code so TensorFlow manages variables more safely.