Un-hardcode the number of splits in Split
Currently the tensor.Split op has an internal parameter that is the number of splits to make. This is ugly, because it makes it impossible to return a variable number of splits.
Better would be for Split to return a symbolic list of splits.
We can emulate the current behaviour by hardcoding element-access into that list, but we can support run-time changes to the number of splits.
Better would be for Split to return a symbolic list of splits.
We can emulate the current behaviour by hardcoding element-access into that list, but we can support run-time changes to the number of splits.
Leave a comment
Dynamically changing the number of splits mean changing the number of Variables, and the structure of the graph. I don't think it's a good idea, and anyway it's not feasible for the moment.
It might be feasible if splits were returned in a Generic (or a type that supports a list), but then this list would have to be used as one Variable, not several.
It might be feasible if splits were returned in a Generic (or a type that supports a list), but then this list would have to be used as one Variable, not several.