ponder-lab / Hybridize-Functions-Refactoring / #2942

88%

push

github

Decline a conversion whose boundary dtype cannot be written (#917)

* Decline a conversion whose boundary dtype cannot be written

A parameter can be fed a dtype its consumers do not impose. Eagerly the
argument converts at each operation, against the partner's dtype. Under
tracing there is no boundary to convert at unless a specification names the
imposed dtype, so the argument materializes at the dtype it was fed and the
operation that converted it eagerly raises instead.

The repair therefore lives inside an emitted specification, and is
unavailable exactly when none is written: inference off, or inference on
with the specification absent for an unrelated reason. Both routes reach the
same bare decorator and the same raise, so the decline covers both.

Distinct from the conflicting-coercion precondition in what is available
rather than in the hazard. There the consumers disagree and no specification
preserves them all. Here one specification would preserve the function
exactly; what is missing is the specification, not the answer.

The predicate reads the fed dtype against the imposed one. Comparing the
parameter's REPORTED dtype instead cannot see this: for an operator spelling
the analysis applies the coercion and reports its result, so the reported
dtype already equals the imposition and the divergence with the fed dtype
stays invisible. That comparison is why an earlier attempt at this decline
missed the case it was written for.

An unresolved reading is deliberately not folded in with a changed one. It
means the fed side could not be established, not that it diverges, and
declining on it would cost working functions their transformation.

Each arm is verified by executing the form rather than asserting it. Bare,
`changed` raises; a specification naming the imposed float32 runs; one naming
the fed float64 raises exactly as the bare decorator does. `unchanged` is fed
what it is imposed, converts nothing, and runs bare, so declining it would be
a... (continued)

21 of 21 new or added lines in 2 files covered. (100.0%)

3520 of 4133 relevant lines covered (85.17%)

0.85 hits per line