ejmichaud/neural-verification

MI and Formal Verification of NNs on Algorithmic tasks!

neural-verification's Issues

Update MLP and RNN demos with new initialization best practice

I just did something evil, which is that I modified the MLP and RNN network implementations in neural_verification.py so that you initialize them with a config dataclass object. This is to maintain consistency between the Transformer implementation and the other architectures, and also so that trained networks in the future can be conveniently initialized with a more easily sharable config object. However, this means that our current demos will hit an error when we try to initialize the models with multiple kwargs as Ziming currently does it.

TODO: update the demos so that they actually run with the new code.

Convention: sharing datasets, models, and metrics

Our code will produce datasets, log metrics, and save model weights. Many of these files will be large and should not be committed to git. What should we use to? Note that we will want them in a place which will be easy for folks to access when they use our benchmark -- the whole point of the paper is to define a standard set of datasets and networks for people to analyze!

Some options:

• git LFS
• Dropbox folder
• wandb

Thoughts?

Add MLP and vanilla RNN model definitions to the `neural_verification` module

For the sake of consistency, it would be good if MLP and RNN model definitions were added to the neural_verification module. This would make them easily importable in people's scripts for their respective tasks.

Convention: should all `train.py` scripts save metrics?

I think that train.py scripts should save metrics (train and test loss and train and test accuracy if applicable) over the course of training. Good convention?

Clean up nanoGPT implementation in `neural_verification` module

There are a bunch of methods included in the GPT implementation in neural_verification that are unnecessary for our purposes. These have to do with loading up gpt-2 weights, etc. Get rid of them.

Make LayerNorm optional in GPT implementation

LayerNorms can make interpretability harder. Add a config in GPTConfig that specifies whether or not to use LayerNorms, and update the GPT implementation accordingly.