Delay log density computation in pyro.factor
See original GitHub issueIn several places (e.g. NeuTra reparam) that we used pyro.factor
or dist.Delta
, log_density is computed explicitly. This computation is not needed, e.g. when making predictions. It would be nice to add a mechanism to defer this computation, only until some inference algorithms that need the log probability.
Proposed solution
Allow log_factor to be a callable in pyro.factor
. In dist.Unit.log_prob
, if log_factor
is a callable, we will call it to get the required value (similar to the behavior in pyro.param
).
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Distributions - Pyro Documentation
Evaluates log probability densities for each of a batch of samples. Parameters. x (torch.Tensor) – A single value or a batch of values...
Read more >Pyro Solver 2.0 dynamics node - SideFX
A scaling factor for time inside this solver. 1 is normal speed, greater than 1 makes the pyro sim appear sped up, less...
Read more >Analysis of 6.4 million SARS-CoV-2 genomes identifies ...
The spread of the virus into human populations in late 2019 and early 2022 was marked by periods of rapid evolution in fitness...
Read more >(PDF) High-Resolution Porosity-Permeability Logs Driven by ...
Matrix permeability was directly computed from the 3D FIB-SEM images using ... DE density and ZEFF logs and Core Gamma logs provide early ......
Read more >Pyro‐Phyllobilins: Elusive Chlorophyll Catabolites Lacking a ...
Retention of configuration at the C10‐position was verified by the basically similar CD spectra of 4 and of the YCC in MeOH. The...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Looking at more real-world models, I see there is often other code surrounding
pyro.factor
, including plates and poutines:One advantage of a check like
is_masked()
is that we could use it around entire sections of model code. In particular plates and poutines would not be able to be embedded inside alambda
passed topyro.factor
.Here’s a possible solution that avoids the need for non-tensors in distributions (which would complicate typing):
What if we use
poutine.mask(mask=False)
to control whether various computations are needed? During prediction we can install amask(False)
handler to disable computation of log density. A brute force way to consult the mask would be to add a primitiveis_mask_false()
or something. Or instead of a newpoutine
, we could inNeuTra
add tracing logic like this: