Venturecxx
Venturecxx copied to clipboard
Feature request: Be able to interactively increase the number of samples
distributed according to the current distribution. @vkmvkmvkmvkm envisions this as an interactivity feature.
User story (reconstructed from memory):
- I'm noodling around with Venture in the console or notebook, with a handful of particles in place (so my computer can handle it); I am liberally using observe, forget, force, taking steps with various inference strategies, etc.
- I come to an interesting state, which I would like to know more about.
- I type "abracadabra 100" and 100 new particles appear (after some computation) that are iid with the particles I have now, so I have better resolution on the next plot I make.
- Ideally, without losing to compute spent to create however many particles I currently have (in case that is a significant number compared to 100).
- If we have custom plot widgets, can this be used to make a "refine this plot" button?
To accomplish this effect at the console now, I have to
- Scroll through my interaction transcript and copy it into a file
- Increase the number of particles in all my resample steps (or add an initial resample)
- Run the file from scratch (forgetting all the particles I already have)
The above is significantly easier in an iPython notebook. Does that use channel obsolete this feature?
Possible implementation strategy:
- Wrap the inference trace in a
engine.trace.Trace
to record all the inference expressions that happen - Add a console command that replays the recorded inference commands on a model with the desired number of particles
Issues:
- Does keeping the currently extant particles require saving them in a
in_model
and then merging? - What if I have been resampling? Actually running my program with more particles to begin with will not produce new particles that are iid from the currently extant ones. Is there any coherent story for retroactively adding particles to resample steps that have happened in the past? How do I adjust the target numbers of particles for the in-flight resamples to meet the user's intent of additional information? Should we just punt?
- Can an operation like this be anything other than an extra-linguistic top-level command? "Rerun until here" doesn't make much sense if the "here" could be embedded in a subexpression of something, especially if that thing might occur in one but not another branch of some
if
.
Alternative: don't try to record the inference program, but do record all inference commands that touch every model (including history of observes, forgets, freezes, forces, resamples, etc). Then it should be conceptually easy to multiply the number of particles by k, by running k-1 additional models and merging them in.
- This plan actually doesn't lead to completely iid particles: the new ones will be coupled to the old ones through all random choices made in the inference program that determine which of the recorded operations to actually perform (as opposed to choices internal to those operations, like M-H acceptance tests, which would be rerolled).
- The eventual per-particle inference interpreter would exacerbate the above problem by making such external choices separately for each of the original particles.
My notes say that this feature would enable a construct @vkmvkmvkmvkm called estimate
, but I no longer remember what that construct was supposed to be (just the name).
"I type "abracadabra 100" and 100 new particles appear (after some computation) that are iid with the particles I have now, so I have better resolution on the next plot I make. "
What does "iid" mean in this sentence?
Independent and Identically Distributed.