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

Space concept #15

Open
zsunberg opened this issue Jun 18, 2020 · 5 comments
Open

Space concept #15

zsunberg opened this issue Jun 18, 2020 · 5 comments

Comments

@zsunberg
Copy link
Member

We need to decide on a concept for spaces (e.g. the action space and observation space). One option would be to have an AbstractSpace type. I am against this. Instead, I think we should rely on duck typing, for example, spaces might support in, rand, eltype, iterate. In particular, I strongly suggest that [1,2,3,4] should be a valid action space.

@zsunberg zsunberg added the decision A decision that needs to be made label Jun 18, 2020
@zsunberg
Copy link
Member Author

Continuous spaces are a bit more difficult, but I think this would best be handled by a separate package called BoxSets or something. See also JuliaPOMDP/POMDPs.jl#301

@darsnack
Copy link

Yes, I would avoid introducing a type hierarchy unless it provides something via dispatch (usually performance). I think a good alternative to ensure consistency across implemented environments is to write out best practices. Many spaces have special names, but AFAIK that's a consequence of software not literature. On the other hand, many spaces are extremely generic concepts that are not tied to RL at all. I suggest we put some effort into collecting existing Julia implementations of these generic spaces. Most might just be in Base, but I think some might be from other packages (e.g. interval sets).

@zsunberg
Copy link
Member Author

Note that interval sets does not work like we want it to

@darsnack
Copy link

Yeah that's true. Maybe making a PR to add Cartesian products + rand would be either than writing the whole thing from scratch. Either way out of the scope of this package in my opinion.

@zsunberg
Copy link
Member Author

Ok, I think we agree that there should not be a type hierarchy, but we will need to answer some questions. The first is:

As an algorithm-writer, how do I tell if the set is discrete or continuous? (maybe something like IteratorSize?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants