Issue of reusing epoch_iter introduced from the latest commit
See original GitHub issue@ngoyal2707 @myleott At this line from this commit, self.epoch_iter
will not be updated if not None, i.e., the iterator would be the same across epochs. However, we need different seeds for the epoch iterator in different epochs for shuffling; otherwise we will get the same batch order across epochs… So IMO returning same iterator across epochs might not be a good idea in any cases.
PS: This also made the validation log printing starting from epoch 2. I think it is because the training iterator will even be reused for validation when reusing self.epoch_iter
like that.
Issue Analytics
- State:
- Created 4 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Git: How to reuse/retain commit messages after 'git reset'?
After a git reset , this one-liner can do it: git commit --reuse-message=HEAD@{1}. or even shorter: git commit -C HEAD@{1}. You can use...
Read more >need a way to reuse previous commit logs · Issue #849 - GitHub
It used to be possible with magit-log-edit-mode to hit M-p to recall previous commit messages. I think git-commit-mode needs to support this ...
Read more >4. Undoing and Editing Commits - Git Pocket Guide [Book]
Git will present you with the previous commit message to edit if you like; then, it simply discards the previous commit and puts...
Read more >Undoing the last commit and keeping the changes for a next ...
In this pro tip I will teach you how to do two things: Undo the last commit so you can keep the changes...
Read more >same Change-Id in multiple changes - gerrit-review
The reason for rejecting such a commit is that it would introduce, ... Otherwise reviewers would not only have to review the latest...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
yeah, the reason to change this was similar to what you mentioned as we were seeing slightly different results between single and multi gpu setup because of this extra
rand()
call in multi-gpu case.I don’t think the right solution here is to keep the
rand()
call. DO you see big difference in your experiments with and without it? Worse case, I’d suggest add thatrand()
call in your task__init__
?(cc: @myleott )
@ngoyal2707 OK, I find the reason why my previous experiment was not reproducible: this commit replaced
torch.rand()
withtorch.zeros()
, affecting the state of RNG when doing multi-gpu training. It may sound strange, but is it possible to revert back to torch.rand() so that all the previous experiments are reproducible?