Open jonathan-laurent opened 4 years ago
Hmm... my initial thought is that Julia is simple enough that interaction should be in terms of Julia syntax rather than typing in strings, and providing this alternative will add more things to explain. It also seems like this will be very application-specific, so maybe should not be a part of the interface. An alternative would be to provide a convenience constructor or function that accepts a string representation, for example
ConnectFourState("""
| |x| |x|
| |o| |o|
|x|o|x|o|
|o|x|o|x|""")
Of course a domain-specific solution like this means that solvers cannot use it in a generic way, so we should think about it some more.
Can you give a specific example of the debugging case you had in mind?
It would be tempting to just let the user define parse_state by overloading Base.parse. However, the state is often not represented using a dedicated type and it would not make sense in those cases.
Yes, I agree - my experience says that information from the environment would be needed for this.
Sorry for the late reply, I had missed your answer.
Can you give a specific example of the debugging case you had in mind?
In AlphaZero.jl, from the moment you implement the GameInterface
, you can use a small console CLI to explore your agent behavior out-of-the-box. This CLI relies on function parse_state
to enable the user to jump to a specific state.
But I can happily agree with you that maybe CommonRLInterface.jl is not the right place to include such functions.
Should we add functions
parse_state(env, string)
andparse_action(env, string)
to help building interactive debugging tools?It would be tempting to just let the user define
parse_state
by overloadingBase.parse
. However, the state is often not represented using a dedicated type and it would not make sense in those cases.Any thoughts?