Proposal: Generalize broadcast_like

[sbodenstein]

Now that broadcast_like has been merged (#11820), I would like to discuss the extension discussed here by @taliesinb. Quoting it:

There is a generalization that would be extremely useful for this operator to have. The generalization is very similar to one that was discussed at https://discuss.mxnet.io/t/reshaping-broadcasting-without-hardcoding-target-dimensions/851/6 (you can skip to the last 4 comments, the thread contains an irrelevant proposal although the motivation is relevant).

In short, the generalization would allow only specific dimensions to be copied from the 'other' tensor. For example:

input.shape = (1, 2, 1, 3)
other.shape = (5, 6, 7, 8)
output = broadcast_like(input, other, input_axes:(0,2), other_axes:(1,3))
output.shape = (6, 2, 8, 3)
In other words, what's happening here is that the you can pick exactly which axes of the other tensor you want to use to "fill in" axes of the input tensor. This is how broadcast_axes works, except instead of providing the values via a size parameter, you are providing them from specific axes in the other tensor.

The reason this is so valuable is that it is common to have another tensor that contains the dimension you want to broadcast amongst a set of irrelevant dimensions. There is simply no other way of "extracting" the relevant dimension from elsewhere in the net, so currently you have to hardcode that dimension into a parameter list, which forces expensive workarounds like bucketing where otherwise cheap reshaping would work to make a net that is compatible with multiple sequence lengths, for example.

The current behavior of broadcast_like in the PR would be consistent with this generalization if the default value of input_axis is the empty tuple, which means "all axes".

I would like to open this design up for discussion.

@ifeherva

[ifeherva]

Sounds reasonable to me.

[rondogency]

@sbodenstein I was working on broadcast_like briefly a few weeks ago (#11443 ). This specs looks very reasonable. I am just wondering if you would be comfortable that I work on top of @ifeherva new broadcast_like, and generalize it as discussed above?

[sbodenstein]

@rondogency: @ifeherva had also expressed interest to implement it, but whoever has more time this week should probably do it (we need it for next Monday, so I would add it neither of you has time this week).

[rondogency]

I see. I won't be available for it until Saturday. If you need it by Monday, I may not be able to make it on time. Sorry for the inconvenience.