tensorflow

这是一个 TensorFlow 的 bug：tf.image.non_max_suppression 将 iou_threshold/score_threshold 以 Python float（float32）形式传入，因此当 boxes/scores 为 float16 时，该算子会以 T=float16, T_threshold=float32 运行，而 XLA 在 tf.function(jit_compile=True) 下编译时会拒绝这种类型组合。

**临时解决方案：** 直接调用 tf.raw_ops.NonMaxSuppressionV3，并将阈值转换为 float16，使 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)  # 编译通过，返回 [0 1]

**其他替代方案：**
- 在调用 tf.image.non_max_suppression 之前，先将 boxes/scores 转换为 float32，如有需要再将结果转换回原类型。
- 以 eager 模式运行该算子（不使用 jit_compile=True），因为 eager 模式能正确处理混合数据类型。

已在 tf-nightly 2.23.0-dev（CPU，与设备无关）上确认。可在 tensorflow/tensorflow#128614 跟踪上游修复进展。

已知的 TensorFlow bug（nightly 2.22.0-dev，issue #127911）：PR #125387 为 tf.multiply/tf.pow/tf.divide 添加了 Python 标量 dtype 强制转换，但遗漏了 tf.subtract，因此 eager 模式会将 Python int 强制转换为张量的 float32 dtype，而图模式和 XLA（jit_compile=True）则将其转换为 int32，导致 Sub(int32, float32) 不匹配。在修复合入之前的临时解决方案：显式转换标量，使所有执行模式行为一致——tf.subtract(tf.cast(5, t.dtype), t) 或 tf.subtract(tf.constant(5, dtype=t.dtype), t)。避免在 tf.function 内部向 tf.subtract 传递裸 Python 标量。对于自定义构建，可修补 tensorflow/python/ops/math_ops.py，在 subtract() 中添加与 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')。

出现此警告是因为 TensorFlow 2.20 是使用 protobuf gencode 5.28.3 编译的，但 pip 安装了更新的 protobuf runtime 6.x（例如 6.31.1）。通过将 protobuf Python 包降级到与 gencode 主版本匹配来修复：

pip install "protobuf<6.0"

pip install protobuf==5.28.3

如果你使用 Pipenv/Pipfile，请在 Pipfile 中显式添加 protobuf = "<6.0"，然后运行 pipenv install，因为 protobuf 是作为 TensorFlow 的传递依赖被引入的。或者，如果不想降级，可以在代码中抑制该警告：

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

降级是推荐的修复方法，因为 gencode/runtime 不匹配可能会在未来的 runtime 版本中导致兼容性冲突。

这是一个已知的 bug：对于奇数的 window_length 值，该实现会构建两个各包含 window_length // 2 个样本的半段，因此输出只有 window_length - 1 个样本（例如，window_length=5 返回形状 (4,)，而 window_length=1 返回一个空张量）。解决方法：仅传入偶数窗口长度，因为 Kaiser-Bessel Derived (KBD) 窗口在数学上仅针对偶数长度定义。在调用前将奇数长度舍入到最接近的偶数，例如 n += n % 2，以避免在将窗口与信号帧配对时出现下游形状不匹配。

这是一个已知的 TensorFlow bug（tensorflow/tensorflow#129234，已在 tf-nightly 2.23.0-dev 中确认）。kaiser_window 仅在长度为静态 Python 常量时才对长度为 1 的情况做特殊处理。当 window_length 是动态张量（例如 tf.function 的参数）时，内部的 halflen_float 会变为 0，表达式 arg / halflen_float 的计算结果为 0/0，最终返回 [nan] 而不是 [1.]。解决方法：使用 tf.cond 自行处理长度为 1 的情况，例如 tf.cond(tf.equal(n, 1), lambda: tf.ones([1], dtype=tf.float32), lambda: tf.signal.kaiser_window(n, beta=beta))。或者，在 eager 模式下为 n=1 计算窗口，因为 eager 模式和 np.kaiser(1, beta) 都能正确返回 [1.]。请注意，hann_window 和 hamming_window 已经通过内部针对 window_length == 1 的 cond 正确处理了这种情况，因此在修复发布之前可以将它们用作参考行为。