Should we switch to pyro flows?

[michaeldeistler]

Currently, we are relying on nflows for our flows. I think that pyro's flows look pretty great, see e.g. here for NSF.

They very nicely separate the transformer from the conditioner, see e.g. here for autoregressive splines.

Any reasons to stick to nflows?

[jan-matthis]

I agree but we'd have to make sure that performance and speed are matched. One step in that direction could be to check performance and speed of Pyro-based MAFs and NSFs on experiments/uci.py of https://github.com/bayesiains/nsf

[michaeldeistler]

We will move to flowtorch after the hackathlon

[francois-rozet]

Hello 👋

I noticed you wanted to switch from nflows to flowtorch for your normalizing flows. I must warn you that flowtorch is still missing important features. Notably, there is currently no way to build conditional normalizing flows, as required for NPE.

Initially, our package lampe was relying on nflows for its normalizing flows, but we ran into some issues that we couldn't fix. We wanted to contribute to nflows but the project seemed abandoned. As alternatives, we considered pyro and flowtorch but neither of them were actually usable. Eventually, we chose to implement normalizing flows from scratch within lampe, with an approach similar to that of pyro but relying more on distributions and transformations provided by PyTorch.

Since then, the flow implementations have improved and new ones were added such as NSF, NAF and UMNN (both coupling and fully autoregressive). Recently, we decided to export our normalizing flows to a standalone package named Zuko. If you still want to switch from nflows, you might consider zuko 🔥

[michaeldeistler]

Hi Francois,

thanks for the pointer, and we are indeed on the lookout for a good repo for flows. We'll have a look!

Michael PS: amazing package name and logo

[plcrodrigues]

Hi, I was wondering whether this issue could be considered as relevant to the SBI Hackathon 2024.

I think it would be great to have a flows backend base on @francois-rozet's awesome work on zuko. The package is actively maintained by François and would benefit from having more contributors.

Also, this migration could eventually lead to people switching between sbi and lampe more easily. In the long term, maybe the former could be seen as a package for end-users in applications while the latter as a package for prototyping new algorithms in the sbi literature ?

I don't know, maybe this sounds infeasible and not even pertinent to the current discussion, but I feel that relying on nflows (last update in 2020) or flowtorch (last update in 2022) would mean relying on code that is no longer actively maintained and putting the sbi package in a precarious situation.

[janfb]

Hi Pedro, thanks for your input!

Yes, it's relevant for the hackathon indeed! we are currently preparing to abstract away the dependency on only nflows (keep them, but allow for other density estimator packages, e.g., zuko). See #952 and #957

Our plan is to get this done before the hackathon to be able to integrate new density estimators during the hackathon more easily.

[janfb]

Is addressed in #957

[janfb]

interface zuko is done. See also #1116