Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🚚🪞Make sure inductive representation is on same device #1229

Merged
merged 5 commits into from
Feb 22, 2023

Conversation

dobraczka
Copy link
Contributor

Contributing to bug fixes

  • Fill out the template below
  • The pull request should only fix existing bug reports
  • The pull request should comply with these points mentioned in the contribution guidelines

Link to the relevant Bug(s)

#1228

Description of the Change

Before returning entity_representation for the right mode, sent them to the same device as model.

Possible Drawbacks

None?

Verification Process

I tested this on the code in the original issue and also on https://github.com/pykeen/ilpc2022 for the small dataset. Both previously failed, but now run through as expected.

Release Notes

  • Make sure inductive representation is on same device

@dobraczka
Copy link
Contributor Author

Maybe it might be more consistent to simply override .to. I also tried the following, which worked:

def to(self, *args, **kwargs):
    for mode in [TRAINING, VALIDATION, TESTING]:
        self._mode_to_representations[mode] = self._mode_to_representations[mode].to(*args, **kwargs)
    return super().to(*args, **kwargs)

@mberr
Copy link
Member

mberr commented Feb 20, 2023

Why are the representations not a torch.nn.ModuleDict? To avoid having to move all of them to the device? 🤔 If this was the case, both suggested solutions would not mitigate this, since torch.nn.Module.to is in-place, and the other suggested alternative essentially does what torch.nn.ModuleDict would do 😅

I tend towards making _mode_to_representations a torch.nn.ModuleDict, but I am happy to hear additional opinions on this, in particular from @migalkin @dobraczka .

@dobraczka
Copy link
Contributor Author

Looks like the decision to not make it a torch.nn.ModuleDict was made in #1106, but there was no reason provided. But I guess it probably was to avoid having to move them all to the device.
I would also tend towards making _mode_to_representations a torch.nn.ModuleDict. Since the combination in the Representation is shared anyway this would only mean to additionally move the assignments, which shouldn't be big enough to cause problems.

@dobraczka dobraczka changed the title Make sure inductive representation is on same device 🚚🪞Make sure inductive representation is on same device Feb 21, 2023
@mberr mberr self-requested a review February 22, 2023 16:22
@mberr mberr enabled auto-merge (squash) February 22, 2023 16:57
@mberr mberr disabled auto-merge February 22, 2023 17:05
@mberr mberr enabled auto-merge (squash) February 22, 2023 17:06
@@ -97,8 +100,9 @@ def _get_entity_representations_from_inductive_mode(
raise ValueError(
f"{self.__class__.__name__} does not support the transductive setting (i.e., when mode is None)"
)
if mode in self._mode_to_representations:
return self._mode_to_representations[mode]
key = f"{mode}_factory"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this mode_factory and not just mode?

Copy link
Member

@mberr mberr Feb 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a (key, value) pair torch.nn.ModuleDict registers value as an attribute with name key (cf. here). Since ModuleDict is a Module, too, it already has an attribute training, which is why we cannot have the key training in the dict. Thus, I suffixed them with _factory. I did not want to change the InductiveMode constants though, thus we need to derive a key different from the mode.

EDIT: the relevant commit is a086760 and there is a small note above the declaration of the dictionary.

EDIT2: we could have refactored key = f"{mode}_factory" into a helper method, but I thought this would make the code less readable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay just making sure you thought about this. feel free to merge when ready

@cthoyt cthoyt disabled auto-merge February 22, 2023 17:24
@cthoyt cthoyt merged commit 89ec31f into pykeen:master Feb 22, 2023
@dobraczka dobraczka deleted the inductive-device-bug branch February 22, 2023 17:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants