(What is this? Check the lab notebook's table of contents)
Created 2024-02-09
At this point, I can plot PDFs of continuous variables sufficiently well to understand the result of the tug-of-war simulation with even more fidelity than the original MCMC-based implementation on probmods.org (which hangs long before it creates graphs anywhere near as smooth as mine).
I'd originally assumed that to get this far, I'd have to use a more complicated algorithm than rejection sampling. That would require the code to be broken up into a continuation-passing style and sampled. If I had to do that, then I might as well create a node-and-wire-based language to implement it, since that seems to fit the problem domain better: tiny models in which you want to visualize pretty much every variable, and are willing and able to do so by moving nodes around to support it.
I see a few options:
I could implement more and more complex models to see when, if ever, rejection sampling stops being sufficient. I've added ~6 hard conditions to the tug-of-war example without noticing even a drop of framerate when generating 100,000 completed samples in Safari. How many conditions (or, correspondingly, how much data) would I need before this implementation strategy stops working? I'm pretty sure that soft factors require passing around likelihood values, which would be annoying without some form of compilation, and it might make the computation less tractable since low-probability paths can't be exited early, but it doesn't seem on its face like a blocker.
Or I could invest in the technology to layer visualizations into textually-specified models, sprucing up the programming primitives (I don't even need objects to represent distributions if all I'm going to do is rejection sampling), and making a glorified text editor.
I can take a leap of faith and switch to nodes and wires now. This would be the most interesting to me and to the broader future-of-coding community, even if it isn't strictly necessary for the models that I've been interested in to date.
I am less interested in this environment as a practical modeling environment for today as I am as a practical modeling environment tomorrow. Therefore, I will move on to the node-and-wire programming model I've sketched out in my notebook and leave textual programming behind.
I don't think I lose much by not going down the first two paths. Now that I know the power of rejection sampling on a fast machine, the next time I am dissatisfied by WebPPL's capabilities, I know that I can rewrite the model in JavaScript and generate far more data, faster. For plotting, I can always restore the current git version and fork from here (the same way I switched from coin-flipping to tug-of-war), or I can dump the data and plot with another library without referring to this project at all. I think that I could make some interesting visualizations even with text as the medium, but that they wouldn't be as good a fit for this Three.js-based environment as something I can make for the more visual language that I've started to imagine.
So, onward to visual programming!