tensorflow

Framework

tensorflow/tensorflow

End-to-end open source platform for building and deploying ML models.

Overview

TensorFlow is an end-to-end open source machine learning platform originally developed by Google Brain. It offers a flexible ecosystem of tools and libraries with stable Python and C++ APIs, supporting research and production deployment across CPUs, GPUs, and distributed environments.

README Preview

\n  \n\n\n[](https://badge.fury.io/py/tensorflow)\n[](https://badge.fury.io/py/tensorflow)\n[](https://doi.org/10.5281/zenodo.4724125)\n[](https://bestpractices.coreinfrastructure.org/projects/1486)\n[](https://securityscorecards.dev/viewer/?uri=github.com/tensorflow/tensorflow)\n[](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened&can=1&q=proj:tensorflow)\n[](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened&can=1&q=proj:tensorflow-py)\n[](https://ossrank.com/p/44)\n[](CODE_OF_CONDUCT.md)\n\n**`Documentation`** |\n------------------- |\n[](https://www.tensorflow.org/api_docs/) |\n\n[TensorFlow](https://www.tensorflow.org/) is an end-to-end open source platform\nfor machine learning. It has a comprehensive, flexible ecosystem of\n[tools](https://www.tensorflow.org/resources/tools),\n[libraries](https://www.tensorflow.org/resources/libraries-extensions), and\n[community](https://www.tensorflow.org/community) resources that lets\nresearchers push the state-of-the-art in ML and developers easily build and\ndeploy ML-powered applications.\n\nTensorFlow was originally developed by researchers and engineers working within\nthe Machine Intelligence team at Google Brain to conduct research in machine\nlearning and neural networks. However, the framework is versatile enough to be\nused in other areas as well.\n\nTensorFlow provides stable [Python](https://www.tensorflow.org/api_docs/python)\nand [C++](https://www.tensorflow.org/api_docs/cc) APIs, as well as a\nnon-guaranteed backward compatible API for\n[other languages](https://www.tensorflow.org/api_docs).\n\nKeep up-to-date with release announcements and security updates by subscribing\nto\n[announce@tensorflow.org](https://groups.google.com/a/tensorflow.org/forum/#!forum/announce).\nSee all the [mailing lists](https://www.tensorflow.org/community/forums).\n\n## Install\n\nSee the [TensorFlow install guide](https://www.tensorflow.org/install) for the\n[pip package](https://www.tensorflow.org/instal

FAQ (5)

Troubleshooting
How to fix XLA compilation error 'Seen floating point types of different precisions, mixed precision is disallowed' for tf.image.non_max_suppression with float16 inputs?

This is a TensorFlow bug: tf.image.non_max_suppression passes iou_threshold/score_threshold as Python floats (float32), so with float16 boxes/scores the op runs with T=float16, T_threshold=float32, which XLA rejects at compile time under tf.function(jit_compile=True).

**Workaround:** call tf.raw_ops.NonMaxSuppressionV3 directly and cast the thresholds to float16 so T == T_threshold:

def nms_f16(boxes, scores):
    return tf.raw_ops.NonMaxSuppressionV3(
        boxes=boxes, scores=scores, max_output_size=2,
        iou_threshold=tf.constant(0.3, tf.float16),
        score_threshold=tf.constant(float('-inf'), tf.float16))

tf.function(nms_f16, jit_compile=True)(boxes, scores)  # compiles, returns [0 1]

**Alternatives:**
- Cast boxes/scores to float32 before calling tf.image.non_max_suppression, then cast results back if needed.
- Run the op eagerly (without jit_compile=True), since eager mode handles the mixed dtypes correctly.

Confirmed on tf-nightly 2.23.0-dev (CPU, device-independent). Track the upstream fix in tensorflow/tensorflow#128614.

GitHub Issue #128614
Troubleshooting
Why does tf.subtract(5, float_tensor) work in eager mode but fail with 'TypeError: type float32 does not match type int32' inside tf.function or XLA?

Known TensorFlow bug (nightly 2.22.0-dev, issue #127911): PR #125387 added Python-scalar dtype coercion to tf.multiply/tf.pow/tf.divide but missed tf.subtract, so eager coerces the Python int to the tensor's float32 dtype while graph mode and XLA (jit_compile=True) convert it to int32, causing a Sub(int32, float32) mismatch. Workaround until the fix lands: convert the scalar explicitly so all execution modes agree — tf.subtract(tf.cast(5, t.dtype), t) or tf.subtract(tf.constant(5, dtype=t.dtype), t). Avoid passing bare Python scalars to tf.subtract inside tf.function. For custom builds, patch tensorflow/python/ops/math_ops.py by adding to subtract() the same coercion used in multiply(): if not tensor_util.is_tf_type(x) and tensor_util.is_tf_type(y): x = ops.convert_to_tensor(x, dtype=y.dtype.base_dtype, name='x').

GitHub Issue #127911
Troubleshooting
How to fix 'Protobuf gencode version 5.28.3 is exactly one major version older than the runtime version' warning in TensorFlow?

This warning appears because TensorFlow 2.20 was compiled with protobuf gencode 5.28.3, but pip installed the newer protobuf runtime 6.x (e.g., 6.31.1). Fix by downgrading the protobuf Python package to match the gencode major version:

pip install "protobuf<6.0"

or pin the exact version:

pip install protobuf==5.28.3

If you use Pipenv/Pipfile, add protobuf = "<6.0" explicitly to your Pipfile and run pipenv install, since protobuf is pulled in as a transitive dependency of TensorFlow. Alternatively, to silence it without downgrading, suppress the warning in code:

import warnings
warnings.filterwarnings("ignore", message="Protobuf gencode version")

Downgrading is the recommended fix, as the gencode/runtime mismatch may cause compatibility violations in future runtime releases.

GitHub Issue #98980
Troubleshooting
Why does tf.signal.kaiser_bessel_derived_window return fewer samples than window_length?

This is a known bug: for odd window_length values, the implementation builds two halves of window_length // 2 samples each, so the output has window_length - 1 samples (e.g., window_length=5 returns shape (4,), and window_length=1 returns an empty tensor). Workaround: only pass even window lengths, since Kaiser-Bessel Derived (KBD) windows are mathematically defined for even lengths only. Round odd lengths to the nearest even number before calling, e.g., n += n % 2, to avoid downstream shape mismatches when pairing the window with signal frames.

GitHub Issue #129235
Troubleshooting
Why does tf.signal.kaiser_window return [nan] for window_length=1 inside tf.function?

This is a known TensorFlow bug (tensorflow/tensorflow#129234, confirmed in tf-nightly 2.23.0-dev). kaiser_window only special-cases a length of 1 when the length is a static Python constant. When window_length is a dynamic tensor (e.g., a tf.function argument), the internal halflen_float becomes 0, the expression arg / halflen_float evaluates to 0/0, and the result is [nan] instead of [1.]. Workaround: guard the length-1 case yourself with tf.cond, e.g. tf.cond(tf.equal(n, 1), lambda: tf.ones([1], dtype=tf.float32), lambda: tf.signal.kaiser_window(n, beta=beta)). Alternatively, compute the window in eager mode for n=1, since eager mode and np.kaiser(1, beta) both correctly return [1.]. Note that hann_window and hamming_window already handle this case correctly via an internal cond on window_length == 1, so they can be used as reference behavior until the fix lands.

GitHub Issue #129234