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

Flexible Policy Definition #293

Open
josephdviviano opened this issue Feb 28, 2024 · 1 comment · May be fixed by #327
Open

Flexible Policy Definition #293

josephdviviano opened this issue Feb 28, 2024 · 1 comment · May be fixed by #327
Assignees
Labels
enhancement New feature or request

Comments

@josephdviviano
Copy link
Collaborator

  • Policies were originally MLPs.
  • Now we need to be able to use arbitrary function approximators.
  • This will be a library-level change that will affect all projects.
@alexhernandezgarcia
Copy link
Owner

To add more details:

  • The policy classes are currently under ./gflownet/policy/.
  • Currently, the base class in [base.py] implements an MLP.
  • There are two more classes implementing tree architectures that I am not sure if they are well maintained (Michał might know)
  • There is also a class for the State Flow model in state_flow.py used by the DB loss.
  • An inconvenient aspect of the current implementation is how the combination of loss and architecture is handled in the configuration files. Currently, there needs to be a configuration file for every architecture/loss combination.

The new implementation should satisfy, in my opinion, the following desiderata:

  • It should be easy to create new architectures for the policy models, say a CNN, GNN, Transformer, etc.
  • The use of policy should not be entangled with the loss.
  • There could be generic architectures (MLP, CNN, etc.) whose specific main properties can be specified via the config. For example, the number of layers and units of an MLP.
  • Additionally, it should be easy to add a new class with a specific architecture that would be available to use with any loss.

@alexhernandezgarcia alexhernandezgarcia pinned this issue Jun 4, 2024
@engmubarak48 engmubarak48 linked a pull request Jun 18, 2024 that will close this issue
@engmubarak48 engmubarak48 linked a pull request Jun 18, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants