Conversation
The GTIR 'concat_where' type synthesizer derives the result dims via
'type_info.promote(tb, fb)', which asserted that the promoted dtypes are
'ScalarType'. A local field carries a 'ListType' dtype at the GTIR
level, so any 'concat_where' with a local-field branch failed with a
bare 'AssertionError' during type inference -- and it did so even though
both branches have the identical dtype, since the assertion is on the
dtype's kind, not on the operands differing.
Let 'promote' handle 'ListType' the same way it handles 'ScalarType':
both promote only between equal types, so the two cases collapse into a
single check. The docstring records that a 'ListType' only ever reaches
'promote' from the ITIR level, because the frontend represents the same
concept as a field with a local dimension in 'dims' and a scalar dtype.
The combination was previously untested ('test_concat_where.py' had no
local-dimension coverage), so the latent assert never fired in CI.
5e0d111 to
f462cdc
Compare
…length tuples with one tree_map
|
@SF-N #2931 parameterizes how 'tree_map' enumerates a node's children ('collection_elements', living alongside 'collection_type' and 'result_collection_constructor' as the membership/decomposition/reconstruction facets of a traversable collection) and removes the 'iter'/'len' container dunders from the type specs; type-tree traversal now goes through 'type_info.tree_map_type', which is also usable as a parametrized decorator. This PR should adopt that instead of the length-1 view via 'XVarArgType.iter'/'len': as a dunder, "a variable-length tuple has length 1" is observable by any code that happens to iterate or 'len()' a type, while as a 'collection_elements' policy it is explicit and local to the traversal that wants representative-element semantics. Concretely, after rebasing onto main with #2931: drop 'iter'/'len' from 'XVarArgType' (note 'XTupleType' also loses the inherited ones), and let '_deduce_elementwise_binop_type' call 'type_info.tree_map_type' with a 'collection_elements' that yields the representative 'element_type' for 'XVarArgType' and '.types' otherwise — the 'broadcast_leaves' zipping semantics (same kind, same length, leaves repeated) stay as they are and compose with it. |
This branch has not been deployed
3 participants
See https://hackmd.io/PxqTkA4rSGCgCmUAPq15SA for some unsorted discussion.