Add tf.repeat support equivalent to numpy.repeat

[yongtang]

(Most of the credit goes to RaggedTensor author, couldn't find the GitHub handle but the related commit is bad5d1a)

This PR tries to address the issue raised in #8246 to have tf.repeat equivalent to numpy.repeat.

Multiple attempts have been made in the past. The previous PR #15224 add the support with C++ which was closed, as a python implementation relying on existing ops is more desirable.

Now repeat has been added in ragged_util.py for RaggedTensor (the axis=None is not covered but this is fairly straight ward). The related commit is bad5d1a.

This PR

• moves the repeat implementation in ragged_util.py to array_ops.py so that it is possible to get exposed.
• adds additional logic to handle numpy.repeat with axis=None
• expose repeat_with_axis in ragged_util.py again so that existing logic in ragged tensor does not break
• expose tf.repeat in v1 and v2.

This fix fixes #8264.

Signed-off-by: Yong Tang yong.tang.github@outlook.com

[gunan]

I would not be the right reviewer for this.
You also need to have a TF API owner review this change, I think

[alextp]

@seanpmorgan I think this belongs in addons for now. WDYT?

[seanpmorgan]

Initial Thoughts:

1. Looks like a great contribution thanks @yongtang !
2. I'm struggling to find a location for this in addons. A key aspect that we're trying to push is addons must match an API pattern that we support (e.g. layers, optimizers, etc.) or it belongs to a sub-package that a reputable contributor or organization maintains (e.g. seq2seq). Is there a sub-package we could imagine this living under? It seems like a primative tensor transformation... so unless we make a tfa.transform or something it might be a little tough.

@karmel @facaiy thoughts?

[alextp]

@seanpmorgan should this be tfa.manip.repeat so it can conceivably end up in tf.manip.repeat?

[facaiy]

Looks like a great contribution

+1, good job!

Is there a sub-package we could imagine this living under? It seems like a primative tensor transformation... so unless we make a tfa.transform or something it might be a little tough.

Yes, we need to create a new sub-package if we think addons should accept the contribution. But I'm not sure if it's appropriate to put primitive ops in addons, because the requirements in https://github.com/tensorflow/addons are:

contributions that conform to well-established API patterns, but implement new functionality not available in core TensorFlow.

@karmel @dynamicwebpaige What do you think?

[seanpmorgan]

Yeah, my high level thought is that tfa.manip may not be an easily maintainable subpackage as it could be hard to define that expected API structure. Not impossible though and I'd be open to a subpackage submission (Currently working on the process of doing such a thing).

Apologies for the tepid answer, but obviously Addons will be in a forever battle with scope creep.

[karmel]

Maybe tf-text? I agree that it's not obvious that this fits inside the addons paradigm. Although, if it were an op for repeating with a python endpoint rather than python for the same, I guess that would be allowed.

[rthadur]

@yongtang gentle ping to check review comments.

[rmlarsen]

@yongtang could you please rebase?

[yongtang]

@rthadur @alextp Previously, Kokoro CI test failed because of some API change in test_util.TensorFlowTestCase.

I have fixed the build failure and all tests passes now, please take a look.

Sorry for not catching the test failure earlier.

[rthadur]

Merged internally , waiting for auto merge to happen.

[mellanox-github]

Can one of the admins verify this patch?

[yongtang]

Looks like the PR has been merged into master so I will close this PR. Thanks everyone for the help to make this happen 👍 ❤️ 🎉 !