-
Notifications
You must be signed in to change notification settings - Fork 183
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
atari-py is based on old version of ALE #2
Comments
Agreed. It is not wise to keep an independent branch and not updating with the upstream. This will discard a lot of available options in atari. For example, ALE recently introduced the option "repeat_action_probability" that is used by some latest papers. Same thing for doom-py, it's not tracking upstream either. |
I agree there's a real and somewhat unfortunate issue with snapshotting upstream. However, there's a deeper issue here, which is that sometimes upstream changes will causes changes in semantics. This could break comparability across an environment version. I'm not sure what the right balance is here. Perhaps we should publish different libraries (such as "atari_py_1" or something) corresponding to frozen versions of upstream. @joschu what do you think? |
I think there's no reason to update ALE, as it already works. |
I have two arguments for updating ALE (at least once, but presumably every now and again):
For mechanism, I think a submodule is reasonable. This is what I've been doing in my own projects and it hasn't been any trouble. I'd be happy to help with this switch-over. Furthermore, the submodule preserves the versioning and authorship information from upstream, and so gives full attribution to the work. @joschu @gdb what are your latest thoughts on updating the ALE? |
@shelhamer I like it. We can always keep around the current version of atari-py for comparison with the existing algorithms. (Worst case, we'll end up creating multiple atari-py packages, so it's easy to have multiple version installed at once.) If you're up for doing the work, I'd be very happy to support you. (Happy to give you commit bits!) |
(Started doing some work in the above commit, but it's definitely not working properly.) |
Hi, I also was comparing current gym ALE with last ALE when I was trying to implement planning in atari games. I also fount that for latest ALE in order to obtain screen RGB you should provide buffer with size wh3, not 4 like in gym's ALE. And I noticed that pixel values are slightly different for latest ALE compared to gym's ALE, when creating two environments with the same parameters and doing same actions, RAM states in that case are the same. |
Right, sorry for the hold-up on this. As the parts of ALE pulled into atari-py made it via another project—and discarded versioning—the fix isn't free of hassle. I'll take another stab at this soon all the same since I have experiments that make use of |
Thanks for working on that :) |
See #15 to track the status of |
The code of ALE, which is included in atari-py package is based on an old version of ALE.
One difference I observed is in the file ale_interface/src/games/supported/Breakout.cpp, which was changed in ALE nearly a year ago, but I am sure there are more discrepancies.
I feel hesitant to change this one, as then the two repos'll diverge and things will get only worse.
Could you think of the way to keep the two repositories synchronized? (e.g. by including ALE as a git submodule and possibly updating it every half a year or so)
The text was updated successfully, but these errors were encountered: