Expose input and output types from Signature

[jbentleyEG]

Currently you can get the names of the inputs and outputs from a Signature, but there is no publicly accessible method that allows you to get the return types other than toString().

I was unable to get the tests building on my machine, but hopefully this change is small enough that it won't be an issue.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[karllessard]

Thanks @jbentleyEG , looks good but do you have an example on how you actually use it? (maybe adding a small unit test could be great)

Also I'm wondering what is better: return types mapped to their tensor name, like you did, or simply return the whole TensorInfo input/output list, which would also expose their shape, wdyt? Would it also fit in your use case?

[jbentleyEG]

Agreed, I will re-write it to expose the shape as well. That isn't required for my use case, but I imagine that others will need that.

How about just making it a pass-through to the signatureDef method:

/**
* Returns the names of the inputs in this signature mapped to the expected tensor
*/
public Map<String, TensorInfo> getInputs() {
return signatureDef.getInputsMap();
}

[jbentleyEG]

@googlebot I signed it!

[karllessard]

Agreed, I will re-write it to expose the shape as well. That isn't required for my use case, but I imagine that others will need that.

How about just making it a pass-through to the signatureDef method:

/**
* Returns the names of the inputs in this signature mapped to the expected tensor
*/
public Map<String, TensorInfo> getInputs() {
return signatureDef.getInputsMap();
}

That is what I had initially in mind as well, but now I'm thinking that we might want to wrap up that TensorInfo class for our own so we can return a Shape instead of a TensorShapeProto, since the former is being used everywhere in the Java client.

For example we could wrap and convert this in a inner class, like Signature.TensorInfo or Tensor.Metadata? Just throwing some ideas. And to limit the amount of work, I would simply focus on datatype() (returns the DataType enum found in the protos) and shape() (returns a Shape build from a TensorShapeProto), leaving the other available fields for later. Wdyt?

[jbentleyEG]

That makes sense. My original concern about just exposing the whole thing is that it's a mutable object, an inner class bypasses that. I'll submit an update later today.

[rnett]

For tests, did you try running maven with the target integration-test instead of test (in tensorflow-core-api, with the dev profile)? I ran into the same thing earlier.

[karllessard]

Btw @jbentleyEG , do you still intend to push a new PR for this?

[rnett]

@jbentleyEG@karllessard I can take this over, if necessary.

[jbentleyEG]

Sorry, got pulled onto another task and got distracted away from this. Yes, I still plan to do a PR for this.

[jbentleyEG]

@karllessard PR updated

[karllessard]

Hi @jbentleyEG , looks good but as we discussed, can we return the shape as a Shape object to the users instead of a long[]?

[karllessard]

Hi @jbentleyEG, just checking, do you agree to make the proposed change above?

[jbentleyEG]

Sorry for the flakiness, I keep getting pulled away by other tasks. I wasn't able to generate the Shape directly from the TensorShapeProto, but I was able to recreate it from the dimensions.

[karllessard]

Thanks @jbentleyEG !