Error in documentation of `regenerate`?

[ztangent]

I just tested this on Gen 0.4.5, and this particular claim about choices being retained by regenerate seems to be wrong?

https://github.com/probcomp/Gen.jl/blob/262f96f0311841b4edb96c73c95e1ee892a15f59/docs/src/ref/gfi.md?plain=1#L290

In particular, if a choice is sampled within an if statement, and the ancestor choice is regenerate s.t. that branch of the if statement no longer gets executed, it seems like regenerate discards that choice, rather than retaining it.

I'm not entirely sure what's meant to be the correct behavior here, but it seems to me that the actual behavior is what we want, and the documented behavior is wrong.

[fsaad]

Are the semantics of the default internal proposal (i.e., ancestral sampling from the prior) well-defined for this program? Mutual absolute-continuity appears required from Def 4.1.1 of MCT thesis (or more loosely https://www.gen.dev/docs/stable/ref/gfi/#Internal-proposal-distribution-family-1?) I think an analogous situation is calling Gen.generate with the program:

function model()
    x ~ bernoulli(1e-5)
    if x
        y ~ normal(0,1)
    end
end

When calling Gen.generate(model, (), choicemap(:y=>0), the internal proposal will w.p. 1 - 1e-5 return choicemap :x => false (and returned log-weight will be 0), even though p(:x = false | :y = 0) = 0 for the right-hand event in Eq (2.1) of MCT thesis. The conditioning choicemap :y => 0 is not existentially sound (Def 2.1.4), because there exists traces that have positive measure in which address :y does not appear.

I do not think that Gen defines semantics for GFI methods (generate, regenerate, etc.) with the default internal proposal in such cases.

On Sun, May 7, 2023 at 7:11 PM ztangent @.***> wrote:

I just tested this on Gen 0.4.5, and this particular claim about choices being retained by regenerate seems to be wrong?

https://github.com/probcomp/Gen.jl/blob/262f96f0311841b4edb96c73c95e1ee892a15f59/docs/src/ref/gfi.md?plain=1#L290

In particular, if a choice is sampled within an if statement, and the ancestor choice is regenerate s.t. that branch of the if statement no longer gets executed, it seems like regenerate discards that choice, rather than retaining it.

I'm not entirely sure what's meant to be the correct behavior here, but it seems to me that the actual behavior is what we want, and the documented behavior is wrong.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>