Discussions in #1089 are hard to follow, and I have a naive question: why do we need to add a broadcastability constraints if we can do shape inference? Wouldn't it be enough to have something like np.broadcast_shapes as part of shape inference, in addition to a convention to represent unknown ranks/shapes?

Discussions in #1089 are hard to follow, and I have a naive question: why do we need to add a broadcastability constraints if we can do shape inference? Wouldn't it be enough to have something like np.broadcast_shapes as part of shape inference, in addition to a convention to represent unknown ranks/shapes?

Part of the issue is that shape inference (i.e. ShapeFeature and the associated rewrites) only really exists at compile-time (i.e. within our FunctionGraph and Function framework), yet issues like #1089 involve graphs that are constructed in places like Op.make_node, Op.grad, etc., which is something we should probably call "construction-time" (e.g. when a user constructs a graph). In those cases, we have no access to the shape inference framework. The only (shape/broadcast) information we have to work with is at the Type-level (i.e. in the TensorType objects) and that information is almost exclusively provided by and maintained by the Op.make_node implementations.

If we add a constraint to represent partial shape information, then we can continue to propagate and distinguish between the same information provided by TensorType.broadcastable and the "no shape information/None" case in TensorType.shape. Shape inference can also use that same information to its advantage, though, so it's a way to move forward in more than one direction, as well. I would much rather keep all of this in one place (i.e. compile-time), but the design of aesara.grad and its use of Op.grad doesn't allow that at the moment. As has been mentioned before, if we turned gradients into purely symbolic Ops and then expanded them at compile-time, then problems in #1089 would be entirely within compile-time scope.

The only (shape/broadcast) information we have to work with is at the Type-level (i.e. in the TensorType objects) and that information is almost exclusively provided by and maintained by the Op.make_node implementations.

By the way, this is also one of the primary reasons for actually supporting the "dynamic" broadcasting (i.e. broadcasting without the "required" static shape information) mentioned in #1089: we can't rely on every Op.make_node to correctly propagate that static shape information. Sometimes an Op won't do that correctly due to it being only partially implemented, sometimes it's due to a lack of information or information-gathering capabilities in the Op.make_node context (e.g. symbolic manipulation—i.e. "complete" shape inference—is needed), and other times it could be due to a definitional inability to make such shape inferences for a specific Op (e.g. we simply don't know how the inputs determine the output shapes).

If we simply say "no, we don't support this" across the board, then broadcasting will break in graphs containing such Ops, and I think we would rather have those graphs work whenever possible. Perhaps we'll need to say, "no, we don't support gradients" in these cases, but we definitely shouldn't say that we won't support anything when we absolutely can. This is the basic rational behind #928 and similar changes.