Disambiguation input/output shapes about nir

[stevenabreu7]

I agree, right now the only use case for "free dimensions" is to have only convolution operations in sequence. For any other primitive, we need to know the input shape. To my mind, that is not a particularly common or interesting use case.

More generally, I think that having "parameterizable NIR graphs" (parameterising the input shape, or even number of layers, etc.) is interesting but should likely live outside of NIR - NIR as an intermediate representation should have full information to compile and execute a program it describes. But someone could build something like a "NIR Factory" which generates NIR graphs given some parameters, if that's useful enough to someone.

[sheiksadique]

Ok I will take the opposing side on this discussion and make my case.

Nodes are meant to be functional transformations on data and so "deterministic" in the relationship between inputs and outputs.

Therefore in most, if not all, cases, the input and output dimensions are inferable within a network given sufficient description of each of the nodes and the graph structure.

Forcing this intermediate information the way I see it is therefore redundant and can lead to bugs or inconsistent graph definitions where the dimensions don't match but could syntactically look accurate. Except for the "convenience" of having this information locally available to each node, this specification doesn't serve any purpose and introduces the possibility of introducing bugs.

For any scenario where this information is actually needed, like neuron instantiation, it is already available in the IR of these nodes.

[sheiksadique]

To be clear I am not opposed to specifying input dimension, in most cases this is necessary. I am only concerned with this being a requirement for every node, including those node types that are not necessarily bound by input shapes/dimensions.

[stevenabreu7]

I agree that it would be possible (and convenient) to defer the definition of some nodes' input/output types to when we initialise the whole graph. Perhaps in NIRGraph.post_init, we can compute the input/output types of pooling and convolution layers (i.e. start with nodes where input/output types are defined, and continually define the set of adjacent nodes). We can throw an error if the type of some remaining nodes cannot be inferred.

Would this be a good solution?

[Jegp]

Closing with #59