Audit: `TensorGeneratorFactory` dispatch arms with no `tensorflow.xml` class binding fire never

[khatchad]

Summary

Investigating #510 surfaced that tf.sparse.from_dense's SparseFromDense generator never fired because tensorflow.xml had no <class name="sparse_from_dense"> block bound for it (closed in ponder-lab#270). Auditing the rest of the dispatch table for the same pattern turned up 5 more dispatched arms with no matching XML class binding:

Dispatched arm in TensorGeneratorFactory	TypeReference target	XML status
DIVIDE	Ltensorflow/math/divide	Missing
SUBTRACT	Ltensorflow/math/subtract	Missing
FLATTEN	Ltensorflow/functions/flatten	Missing
MAX_POOL	Ltensorflow/functions/max_pool	Missing
SOFTMAX_CROSS_ENTROPY_WITH_LOGITS	Ltensorflow/functions/softmax_cross_entropy_with_logits	Missing

The SparseFromDense precedent (ponder-lab#270) shows what each of these means: the Java generator and dispatch arm both exist, but without the XML binding the dispatch arm never fires — calls to these ops produce ⊤ output instead of the precision the dedicated generator would compute. None of these is currently exercised by a fixture that asserts non-⊤ shape/dtype, which is why CI hasn't surfaced the silent precision loss.

Audit Method

Cross-referenced (a) the isType(calledFunction, X.getDeclaringClass()) arms in TensorGeneratorFactory.getGeneratorBody, (b) the corresponding TypeName.string2TypeName("L...") strings in the matching TensorFlowTypes constants, and (c) the <new def="..." class="L..."> declarations in tensorflow.xml plus numpy.xml. Anything dispatched but not declared is in the table above.

Suggested

For each of the 5 ops:

1. Verify the ground-truth API (some may have been renamed / moved upstream — e.g., tf.flatten is tf.keras.layers.Flatten now; tf.divide/tf.subtract are real top-level aliases under tf.math).
2. Add the missing <putfield> aliases (mirroring the sparse_add / sparse_from_dense pattern) and the <class> block.
3. Add a fixture exercising the op with a kwarg form so the dedicated generator's Parameters#getName() is also covered.

Mirror the diff shape from ponder-lab#270 (3 file changes: tensorflow.xml aliases + class block, tf2_test_<op>.py fixture, test<Op> JUnit method).

Why This Matters

Each silent gap is precision loss on real TF ops — e.g., tf.divide(x, y) should currently dispatch to a divide-aware generator (likely ElementWiseOperation semantics), but instead produces ⊤ because the call site doesn't resolve to Ltensorflow/math/divide. Real-world code using these ops won't get the typing the Ariadne engine is theoretically capable of.

Cross-Refs

• Wire tf.sparse.from_dense through dedicated SparseFromDense generator (wala/ML#510) ponder-lab/ML#270 — the SparseFromDense precedent.
• Investigate which of Cast/ReadDataSets/SparseFromDense Parameters#getName() are dispatch-bypassed vs. missing fixtures #510 — the investigation that surfaced the audit.

[khatchad]

Per-op probe results. Each probe = a fixture calling the op on a known-shape input, tested against a (deliberately-wrong) expected type to surface what the analyzer actually produced. count = 0 means the result was not classified as a tensor at all (function call resolved to nothing modeled in tensorflow.xml); count = 1 means a generator fired.

Op	Function-call form	Binop form (where applicable)	Verdict
DIVIDE	tf.divide(x, x) → count=0 (silent ⊤)	x / x → correct via ElementWiseOperation	Real precision loss; fix is XML-only
SUBTRACT	tf.subtract(x, x) → count=0	x - x → correct via ElementWiseOperation	Real precision loss; fix is XML-only
FLATTEN	tf.layers.flatten(x) → N/A (TF1 API)	—	Dead code in TF2. TF 2.9 has no tf.layers module. Current TF2 path uses tf.keras.layers.Flatten() which dispatches via FLATTEN_LAYER_CALL → FlattenCall (working XML at lines 2284–2319 of tensorflow.xml). Recommend deleting Flatten.java + the FLATTEN constant + the dispatch arm rather than adding XML.
MAX_POOL	tf.nn.max_pool(x, ksize=2, strides=2, padding="VALID") → count=0	—	Real precision loss on a real TF2 API; fix is XML-only
SOFTMAX_CROSS_ENTROPY_WITH_LOGITS	tf.nn.softmax_cross_entropy_with_logits(labels, logits) → count=0	—	Real precision loss. Sparse variant has working XML (lines 211–212 + 2118 of tensorflow.xml); non-sparse variant is missing the same wiring. The SoftmaxCrossEntropy generator handles BOTH variants via the dispatch arm at TensorGeneratorFactory.java:1213-1214. Mirror-the-sparse-pattern fix.

Summary

• 4 of 5 are real precision losses on currently-supported TF2 APIs (DIVIDE, SUBTRACT, MAX_POOL, SOFTMAX_CROSS_ENTROPY_WITH_LOGITS).
• 1 of 5 is dead code (FLATTEN). Suggest a separate cleanup PR removing it; not a precision regression.
• All 4 real-loss fixes are XML-only (no Java change). The SOFTMAX_CROSS_ENTROPY_WITH_LOGITS fix has the closest precedent (the existing sparse-variant block); DIVIDE/SUBTRACT mirror tensorflow.xml:217-225 (the add/multiply block); MAX_POOL mirrors any function whose generator reads its value arg via getArgumentPointsToSet.

Fix-PR Risk Assessment

• DIVIDE/SUBTRACT: low risk. tf.add/tf.multiply already work the same way through ElementWiseOperation; adding the same dispatch for divide/subtract reuses that path.
• MAX_POOL: low risk. The MaxPool generator already exists; only the XML wiring is missing.
• SOFTMAX_CROSS_ENTROPY_WITH_LOGITS: low risk. The sparse variant precedent is exact — same generator class, same factoring.
• FLATTEN cleanup: trivial code-removal PR.

Suggested Sequence

If we want to land these:

1. One PR per op (DIVIDE, SUBTRACT, MAX_POOL, SOFTMAX_CROSS_ENTROPY_WITH_LOGITS) — each is a small XML diff + one fixture + one JUnit test. Mirror Wire tf.sparse.from_dense through dedicated SparseFromDense generator (wala/ML#510) ponder-lab/ML#270's diff shape.
2. One small cleanup PR removing the FLATTEN dead code.

Or one bundled PR for all 4 XML additions if you prefer fewer review cycles — the diffs are independent enough that a single PR is reasonable, since each adds different <class> blocks.

[khatchad]

Correction on the FLATTEN verdict: I framed it as "dead code in TF2" because TF 2.9 removed the tf.layers module from the runtime surface. But Ariadne analyzes user source code, which can include TF1 patterns — and tf.compat.v1.layers.flatten exists in TF 2.x as the backwards-compat path, so user code targeting that API is still in-scope.

Reclassifying FLATTEN from "delete" to "add the missing XML binding", same bucket as the other 4. The fix mirrors the tf.keras.layers.Flatten precedent already in tensorflow.xml (lines 2284–2319), but routes to the existing Flatten generator rather than FlattenCall. Flatten.java's arg resolution already targets (0, "inputs") — the TF1 keyword — so no Java change needed.

Wiring needed:

<putfield class="LRoot" field="flatten" fieldType="LRoot" ref="layers" value="flatten" />

plus a <class name="flatten" allocatable="true"> block matching Flatten's expected arg signature.

Updated tally: 5 of 5 are real precision losses, all fixable with XML-only changes. The "1 dead code" framing was wrong.

(Side note: this also raises the question of whether other tf.layers.* surfaces have the same gap — tf.layers.dense, tf.layers.conv2d, tf.layers.max_pooling2d, etc. Worth a separate audit pass, but out of scope for this issue.)