You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should we add functions parse_state(env, string) and parse_action(env, string) to help building interactive debugging tools?
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.
Any thoughts?
The text was updated successfully, but these errors were encountered:
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
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?
The text was updated successfully, but these errors were encountered: