Periodic parameters

[mreboud]

When a parameters is described with an angle (eg the argument of a complex number), MCMC and PMC have trouble describing the periodic boundaries of the parameter range.
I see two possible solutions:

• Allow parameters to be periodic. This may require a bit of work for the correlations and correct distributions though.
• The user can provide an extended range, eg [-100*pi, 100*pi], but it would be nice if pypmc could wrap the parameter space when estimating certain quantities

[fredRos]

@mreboud In the core of pypmc, we use Gaussians or STudent's T distributions forMCMC proposals or density estimation. This implies an infinite support. Adding angle wrapping to that core is not very promising. Instead, one could transform parameters at an interface layer such that the user gets values in[0, 2*pi]` and the core only sees unbounded ranges. This can be done but can also get a bit complicated, I have contributed such ideas to Bat.jl a while back and I see the transformation code has grown quite a bit. I will ask there how periodic parameters are handled these days

[fredRos]

bat/BAT.jl#340

[mreboud]

From the Discord pypmc channel:
@dvandyk: I would prefer the periodic boundary condition, implemented in the indicator function
@pluegh: It looks like he proposes a third option: the result interface handles the periodicity, while the sampler stays unaware

@dvandyk Ok, so you let your MCMC/PMC propose new points in a wider range and the indicator outputs the "corrected" proposed sample, correct?

@pluegh Is this also what you had in mind?

[mreboud]

@mreboud In the core of pypmc, we use Gaussians or STudent's T distributions forMCMC proposals or density estimation. This implies an infinite support. Adding angle wrapping to that core is not very promising. Instead, one could transform parameters at an interface layer such that the user gets values in[0, 2*pi]` and the core only sees unbounded ranges. This can be done but can also get a bit complicated, I have contributed such ideas to Bat.jl a while back and I see the transformation code has grown quite a bit. I will ask there how periodic parameters are handled these days

I have the impression that if you fit a Gaussian or Student's T mixture on an infinite support and wrap the result to your periodic parameter, you will have a descent description, no? Concerning the transformation layer, I am afraid that you will completely loose the gaussianity of you posterior distribution...

[fredRos]

@mreboud I have to correct what I said above. The topology from [0, 2pi] to [-inf,inf] is too different.

Looks like it's not handled in BAT.jl currently.

I checked how it's done in Stan. They have a put a lot of thought into these problems, so it's good to listen to them. On their forum, it's recommend to use the unit_circle, or when you also care about the amplitude, just stay in 2D and transform to angle/amplitude when needed
https://discourse.mc-stan.org/t/results-from-playing-with-periodic-models/18882/2

That's also what Danny and I always used to to, prefer Cartesian coordinates. Perhaps if you just want a phase, add an artificial Gaussian-constrained parameter to augment to 2D

Otherwise you get artifical multimodality because 0 and 2p seem like different values. using -100pi to +100pi will just add even more modes that are actually identical. In that case, you would have to start wrapping angles in the proposal for MCMC. I just don't know if extra care needs to be taken about covariances. Obviously one can't interpret them literally but only use them as a tool for generating new proposals. One needs to check if they proposal is still symmetric, I would assume so but it would need a closer look.

Presumably one can do the same for the proposal in importance sampling, just have to make sure one correctly evaluates the probability of proposing a point given that one can come from different directions:

say for a unit Gaussian, the probability to propose the state associated with pi is the sum to propose all values leading to the same state: -pi, 3pi, -3pi, +5pi, -5pi,... I don't think that's easy to compute for a multivariate Gaussian but it certainly can be approximated.

[mreboud]

@fredRos Thanks for your inputs. Our initial problem is that Cartesian coordinates are sometimes just not the good way to describe the posterior. In one project we have Gaussian constraints on the modulus and phase of a parameter and PMC just fails in describing the corresponding posterior with a Gaussian mixture.

What Danny suggested is that the indicator function could output a corrected sample, where angles are shifted to the correct range. For MCMC this should be enough to implement periodicity properly. For the other algorithms, I can't say for the moment is this is enough to adjust everything.

[fredRos]

@mreboud There is nothing preventing you from applying a constraint in a transformed space and still let the sampler work on cartesian coordinates. But if you want to apply the constraints as prior constraints, then you would need to multiply with the Jacobian. And this would be more involved 👎