Core tools

Core tools

Link to the source files:


The geometry.jl code exports the following immutable types:

and a function

Any geometry type needs to have a nextboundary function associated with it of the form nextboundary(g, x, v) where g refers to a geometry object, x to the position and v to the velocity. The aim of that function is to:

So for example, the Unconstrained is an empty type and the associated nextboundary function just returns (NaN, NaN) indeed a boundary will never be crossed and there is no normal. These NaN are processed by calling functions.

The Polygonal domain requires the definition of the normals and the intercepts. The nextboundary function is pretty simple (intersection of lines). Note a few tricks for numerical stability:

Sampling from an IPP

The ippsampler.jl exports the following immutable types:

and the following functions

The NextEvent type encapsulates an object returned when sampling from the IPP is required. It contains:

The functions nextevent_* are overloaded for the different possible sampling cases.

Exact sampling

Exact sampling is possible for specific distributions. In that case, the dobounce function returns true all the time. An example is the MvGaussian model for which we can indeed sample from the corresponding IPP analytically. See for example the definition of

nextevent_bps{T<:Vector{Float}}(g::MvGaussian, x::T, v::T)::NextEvent

Note the signature of the function. The first parameter indicates how the sampling should be done and the information to do so. The second and third parameters indicate the ray along which the bouncing time should be produced.

Sampling via thinning

The LinearBound type allows to define a linear upper bound on the intensity of the IPP when you have access to a global bound on the eigenvalues of the Hessian (see this paper for more details). An accept reject step can then be performed in the nextevent_* function (dobounce).

An example is the Bayesian logistic regression for which you do have such a bound.

In that case the nextevent_bps returns a bouncing time computed thanks to the upper bound and the dobounce corresponds to a simple accept/reject step.


The kernels.jl code exports a few functions, all of which define how the velocity should be updated in a variety of circumstances. Some of these functions have an exclamation mark attached to them indicating that the transformation is done in place (for efficiency). The refresh_* functions help indicate how the velocity should be refreshed (e.g. drawn from a spherical gaussian). The reflect_* indicate how the velocity should bounce (e.g. specular reflection).