Ug. You're correct that the gradients are wrong, but I don't see how to fix it without a dramatic performance hit. Do you have any suggestions?

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!

The bug still exists, meaning that the tf.dynamic_stitch gradients are incorrect. Is there any other information I can provide that would be helpful?

Let's leave this open. Anyone interested should refer to the comments in #7487. The next step would have been to add a new C++ kernel to speed up the bookkeeping required by accurate gradients.

Can we close this?

The gradient implementation is still incorrect, as of TF 2.5.0rc. Here is an updated example showing the same error

import tensorflow as tf

x = tf.zeros((1, 3))

analytic, numeric = tf.test.compute_gradient(
    lambda x: tf.dynamic_stitch([[0], [0]], [x, tf.ones((1, 3))]), [x]
)
print("analytic")
print(analytic)
print("numeric")
print(numeric)

gives

analytic
(array([[1., 0., 0.],
       [0., 1., 0.],
       [0., 0., 1.]], dtype=float32),)
numeric
(array([[0., 0., 0.],
       [0., 0., 0.],
       [0., 0., 0.]], dtype=float32),)

/cc @rthadur Can we update the label?

I was able to replicate issues in tf-nightly 2.10.0-dev20220714. Please find the gist for reference. Thank you

Hi @drasmuss !
Just trying to put my observation based on yesterday's trials.
Actually @drasmuss has used same indices [0] , [0] to stitch to two tensors ([0,0,0] and [1,1,1]. So while trying to allocate a tensor at same index , it is taking the max of two tensors and failing the dynamic stitch.

If we use two different indices like [0] , [1] or [0],[2] then results for analytical and theoritical from test.comput_gradient is same.
@yongtang @bhack
May be we can put assertion condition in code itself to check whether user is putting different indices or not .

Attached gist for reference.

Thank you!

Yes, this bug is caused by having duplicate indices. But that is defined and supported behaviour for dynamic stitch (e.g., see the documentation):

Values are merged in order, so if an index appears in both indices[m][i] and indices[n][j] for (m,i) < (n,j) the slice data[n][j] will appear in the merged result

Ok @drasmuss !
Thanks for the update.

I was able to reproduce this issue in TF Nighly 2.12.0-dev20221218. Please find the gist here. Thank you.

I was able to replicate this issue in TF Nighly 2.13.0-dev20230419. Please find the gist here. Thank you.

Hi,

Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.

The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.

Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.

Thank you!

This bug is still present in TensorFlow 2.16.1. The code from #7397 (comment) is still valid, and reproduces the bug. I have edited that into the original post for clarity.