The boundary condition problem for slice sampling

[axch]

Slice sampling suffers from a milder version of #384. Consider doing slice sampling on a variable with a beta prior. While looking for the region to slice over, the slice sampler may propose a negative value, or one above 1. The Lite beta PSP's reaction to this is to throw VentureTypeError: Number is not positive, which causes a crash.

Possible solutions:

• Teach beta to accept out-of-bounds proposed values, and just claim their probability is 0. In the case of slice sampling (as opposed to gradient ascent or HMC, per #384), this should lead to the right thing happening. Issue: Could mask model errors where a non-probability shows up in the output position of a beta variable for some other reason. How much do we care about detecting this circumstance and crashing?
  • Sub-option 1: Accomplish this by broadening Beta's declared output type from Probability to Number. Issue: This loses some quantity of runtime type information about the values beta can return.
  • Sub-option 2: Accomplish this by avoiding the crash caused by type mismatch. For example, TypedPSP.logDensity could check whether the proposed output is in the expected type, and always return -inf if not.
• Teach the slice sampler to treat exceptions as "probability 0". Issue: Which exceptions? May mask all sorts of Venture implementation bugs.
• Do some version of Stan's parameter transformations so that they move the boundaries to infinity.
• Broaden the SP interface so that SPs may tell the slice sampler what their bounds of validity are, such that it avoids overstepping them.
  • Pro: This is what the Puma slice sampler does already
  • Con: More junk in the SP interface
  • Con: Only handles the prior's range constraints (but those are the current trouble spot anyway, and the likelihood being more restrictive than the prior would be a problem for M-H and forward simulation as well).