🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/rl/2442

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 2 New Failures, 12 Unrelated Failures

As of commit 48f1606 with merge base e294c68 ():

This comment was automatically generated by Dr. CI and updates every 15 minutes.

Hi @thomasbbrunner!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

The tests are currently failing. Before I dive into them, could you take a look at the changes @vmoens and let me know if my assumptions are correct?

Sure having a look now
Do you mind signing the CLA? Otherwise I can't merge it

Thanks!

Do you mind signing the CLA? Otherwise I can't merge it

Currently clarifying this with my employer. Should not be a blocker, but could take a couple of days.

I edited the PR a bit, to comply with the logic of in_keys_inv and out_keys_inv as explained by this figure:

Hope that makes sense. Happy to provide a version of this in the docstrings in that helps understanding what the transform is doing.
LMK if in its current form you still see issues with the transform.

Hope that makes sense.

Yes, it does! And thanks for the diagram. Really useful to understand.

LMK if in its current form you still see issues with the transform.

IMO there's some room for improvement in the docstrings:

    A transform to rename entries in the output tensordict.

    Args:
        in_keys (sequence of NestedKey): the entries to rename
        out_keys (sequence of NestedKey): the name of the entries after renaming.
        in_keys_inv (sequence of NestedKey, optional): the entries to rename before
            passing the input tensordict to :meth:`EnvBase._step`.
        out_keys_inv (sequence of NestedKey, optional): the names of the renamed
            entries passed to :meth:`EnvBase._step`.
        create_copy (bool, optional): if ``True``, the entries will be copied
            with a different name rather than being renamed. This allows for
            renaming immutable entries such as ``"reward"`` and ``"done"``.

Can I suggest something along the lines of (unformatted):

   A transform to rename entries in the output tensordict (or input tensordict via the inverse keys).

    Args:
        in_keys (sequence of NestedKey): the entries to rename.
        out_keys (sequence of NestedKey): the name of the entries after renaming.
        in_keys_inv (sequence of NestedKey, optional): the entries to rename
            in the input tensordict, which will be passed to :meth:`EnvBase._step`.
        out_keys_inv (sequence of NestedKey, optional): the names of the entries in the
            input tensordict after renaming.

This way it is clear:

• Which name is going to ultimately going to be passed to the _step method.
• What the original and what the renamed keys are.

Hope that this was helpful!

Yeah sure feel free to add this to the PR

Done!

Hi @vmoens, we've signed the CLA. I guess this should be ready to merge! (Together maybe with #2443)