This is a cool use case, but unfortunately I think is too large a project to take on at this time. I think this would be a difficult feature to fully implement, because we'd have to make sure that every integer operation has a proper gradient function defined. Gradient functions are currently written with the assumption that we don't need to handle integers (e.g. we always return None for the indices param of a gather op). The result of this is, without careful auditing and/or testing, many gradients() calls over integers would silently return None or even the wrong answer. This is a big enough feature that we'd probably want close collaboration with someone on the TF team.

If there's enough demand in the future it might be worth the effort, but for now I don't think we can properly deliver on this.

cc @alextp @ebrevdo @martinwicke -- maybe I'm missing something that makes this more tractable?

I agree with @skye . It might be easier for you to bypass TF's gradient code entirely if you want to go this route, since our ops have gradients which don't behave well at all with integers.

@skye to understand the problem better and out of curiosity, would you mind pointing to a place where the assumption on returning None is used?

Here's one I happen to run into recently: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/ops/array_grad.py#L410
Note that we always return None for the indices grad of gather. This is a niche case, but if you were attempting to take the gradient w.r.t. a variable that determines the indices, this grad function would silently return the wrong answer (None corresponds to zero gradient more or less). There are likely more, part of the difficulty is combing through all the gradient functions and finding them :)

I have this need for integer tensor and their gradients too ... it’s disappointing nothing seems to be happening with this, I think this will restrict future innovation in some interesting areas

Hi @jvmncs !

It is not throwing any error in 2.8 version. Attached gist for reference.

Thank you!

Hi @mohantym, thanks for the response. It's nice to see that the error is no longer being thrown, but unfortunately I don't think that suffices to consider this issue solved. In particular, the check that forces a jump out of the backprop logic seems to be the same, just moved to a new location here. Thus it's still not possible for integer-typed tensors to have non-None gradients, even when defined explicitly with a tf.custom_gradient.

FWIW, I think my understanding of TF's goals & aims has evolved. I would not be surprised if this feature were considered a non-goal for the project. It's a relatively niche request. Anyway, I think Jax might be a bit better fit for something so experimental.

@jvmncs !
I just checking for a update from your side. Thanks for the reply.

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.