tensorflow

これはTensorFlowのバグです：tf.image.non_max_suppressionはiou_threshold/score_thresholdをPythonのfloat（float32）として渡すため、float16のboxes/scoresを指定すると、opはT=float16, T_threshold=float32で実行され、tf.function(jit_compile=True)のもとでXLAがコンパイル時にこれを拒否します。

**回避策:** tf.raw_ops.NonMaxSuppressionV3を直接呼び出し、T == T_thresholdとなるようにしきい値をfloat16にキャストします：

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]

**代替案:**
- tf.image.non_max_suppressionを呼び出す前にboxes/scoresをfloat32にキャストし、必要に応じて結果を元にキャストし直す。
- eagerモードではdtypeの混在が正しく処理されるため、jit_compile=Trueを付けずにopをeagerで実行する。

tf-nightly 2.23.0-dev（CPU、デバイス非依存）で確認済みです。上流の修正はtensorflow/tensorflow#128614で追跡してください。

TensorFlowの既知のバグ（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にパッチを適用し、multiply()で使用されているのと同じ強制変換をsubtract()に追加してください：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 ランタイム 6.x（例: 6.31.1）をインストールしたために表示されます。protobuf Python パッケージを gencode のメジャーバージョンに合わせてダウングレードすることで修正できます:

pip install "protobuf<6.0"

または、正確なバージョンを固定します:

pip install protobuf==5.28.3

Pipenv/Pipfile を使用している場合、protobuf は TensorFlow の推移的依存関係として取り込まれるため、Pipfile に protobuf = "<6.0" を明示的に追加して pipenv install を実行してください。あるいは、ダウングレードせずに警告を消すには、コード内で警告を抑制します:

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

gencode とランタイムの不一致は、将来のランタイムリリースで互換性の問題を引き起こす可能性があるため、ダウングレードが推奨される修正方法です。

これは既知のバグです。window_length に奇数の値を指定した場合、実装は window_length // 2 サンプルずつの2つの半分を構築するため、出力は window_length - 1 サンプルになります（例えば、window_length=5 は形状 (4,) を返し、window_length=1 は空のテンソルを返します）。回避策：Kaiser-Bessel Derived (KBD) 窓は数学的に偶数長に対してのみ定義されているため、偶数の窓長のみを渡してください。窓を信号フレームと組み合わせる際に下流で形状の不一致が発生するのを避けるため、呼び出し前に奇数長を最も近い偶数に丸めてください（例：n += n % 2）。

これは既知の TensorFlow のバグです（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 と評価され、結果が [1.] ではなく [nan] になります。回避策：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 モードと np.kaiser(1, beta) はどちらも正しく [1.] を返すため、n=1 の場合は eager モードでウィンドウを計算することもできます。なお、hann_window と hamming_window は、window_length == 1 に対する内部の cond によってこのケースをすでに正しく処理しているため、修正が適用されるまで参照動作として使用できます。