Lightning no longer works with non-primitive types in hparams

🐛 Bug

I will often use things like a layer definition passed in, for things like changing from batch norm to group norm or using a custom layer. Now that lightning uses the hparams feature in tensor board it errors out with these in hparams.

Code sample

from pytorch_lightning.loggers import TensorBoardLogger
from argparse import Namespace
params = Namespace(foo = range(10))
logger = TensorBoardLogger(save_dir='.')
logger.log_hyperparams(params)

Expected behavior

Lightning should convert non primitive types to strings before passing to the summary writer. This worked fine when logging hparams as a text object

Environment

Pytorch 1.4 Ubuntu 16 pip install pytorch_lightning Python 3.7

[Borda]

Sounds good, would you mind sending a PR with these suggestions?

[monney]

@Borda Use Cases for various non-primitives: Sequences: Num Layers as one hparams, per layer filter size or stride for each conv. layer. I use this to test topology changes across different resolutions.

Current Alternative: passing in a string to decoded in model, something like ‘[3,5,3,5,3,5,5]’

Namespaces: Better organization of parameters

Current Alternative: prefix on names like “backbone_init”

Functions: Swapping out compatible layers such as BatchNorm and InstanceNorm or changing activation functions. BigGAN’s repo is a good example of doing this kind of thing: https://github.com/ajbrock/BigGAN-PyTorch

Current Alternative: Mapping within the model like “gn” for to use GroupNorm or “bn” to use BatchNorm

I try to make hparams as complete a description of the experiment as possible, so non-primitives are helpful for this, as the alternatives are messier.

Decoding:

I think it’s reasonable to use eval, and assume an appropriate repr for what is passed in. With a warning if something fails. Currently I manually reconstruct hparams, and construct the model from there.

Pickling the whole hparams or each non-primitive also seems reasonable to me for full reproducibility.