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
Leaving a note here to ensure we address @hyeok9855's ideas:
Here, we define GraphActions as action class, but I think here we need to output Actions as in RingGraphBuilding.make_actions_class.
Thoughts on Actions and GraphActions
I believe the most complicated part w.r.t. Graph is the actions, where we have two kinds of actions - Actions, a class to take flat tensors from the policy, and GraphActions, another class to take steps in the GraphEnv. So we need a clear rule in designing these.
For example,
make_actions_class should always output the Actions so that it can take flat tensor,
Enforce users to implement convert_actions by making it as abstractmethod
Leaving a note here to ensure we address @hyeok9855's ideas:
Here, we define
GraphActions
as action class, but I think here we need to outputActions
as inRingGraphBuilding.make_actions_class
.Thoughts on
Actions
andGraphActions
I believe the most complicated part w.r.t. Graph is the actions, where we have two kinds of actions -
Actions
, a class to take flat tensors from the policy, andGraphActions
, another class to take steps in theGraphEnv
. So we need a clear rule in designing these.For example,
make_actions_class
should always output theActions
so that it can take flat tensor,convert_actions
by making it as abstractmethodstep
inGraphEnv
should always takeGraphActions
etc.
Originally posted by @hyeok9855 in #210 (comment)
The text was updated successfully, but these errors were encountered: