Strange Behavor for Reverse and Forward in Contional NF about freia

[www3cam]

Update 2: I think the problem is when I pickle and unpickle the model. When I remove this line the problem goes away (but is no longer the correct optimization routine).

The reason I do this is that I want to backpropagate through the inputs of the reversible net but I don't want to modify the weights of the reversible net in that instance. It's basically an EM algorithm where the maximization is a minimization of the KL divergence of two distributions and I don't want to modify the weights of the expectation of the model, but I do want to backpropagate through the samples generated by the P distribution. I'm curious about what my options are to perform this task (like for example a way to perform a deep copy with FrEIA) or if you have a good way to fix the numerical instability that comes with pickling and unpickling repeatedly.

Edit: I tried using model2.load_state_dict(model.state_dict()) instead of pickle, but that still resulted in the same numerical instability

[www3cam]

Actually correction. It's likely a numerical error because even though: print(torch.all(torch.eq(rev1,samp_t2))) returns false, the numbers are the same up to 3 decimal places. However when I run the optimization routine in this colab notebook: https://colab.research.google.com/drive/1Ng2TshNYmtloeiUyjQpDeCNxhc_R_2_c?usp=sharing and then forward and reverse, the errors are much more noticeable.

[ardizzone]

Hmm, I'm not quite sure what level of numerical difference is acceptable.
In deep neural networks in general, and also in INNs, something on the order of 10^-4 relative error is not surprising (which it sounds like you are getting)

I didn't quite get what you did with the pickling and unpickling (i.e. if you just checked the numerical inversion error of an untrained model), but as the weights get larger (more specifically the jacobian determinant), the numerical errors tend to grow.
Here is an interesting read on the topic: https://arxiv.org/pdf/2006.09347.pdf
Otherwise, it might also have to do with tranferring the model and weights from and back to the gpu.

Your application sounds very interesting, but maybe it would still work with the currect level of numerical accuracy?
The inaccuracies have never given us big trouble in practice.

I will close the issue for now, seeing as it is over a year old and it is likely your work has moved on, but don't hesitate to re-open it if you want us to go into more detail!

[www3cam]

Thanks. Yea I don't even remember what this code was for to be honest. I might have found pyro code that helped with it.