JuliaMath / JuliaMath/MeasureTheory.jl

Normalization constants

Open
#103 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Julia
Stars
401
Forks
31
PR merge metrics
No merged PRs in 30d

Description

This is a general question/concern, illustrated through a special case. So, starting with that special case, ...

In https://github.com/cscherrer/MeasureTheory.jl/pull/101, we're adding an "LKJL" measure. This is adapted from https://github.com/tpapp/AltDistributions.jl, and looks like this:
```julia
using LinearAlgebra
using Tullio

function logdensity(d::LKJL{k, (:η,), T}, L::Union{LinearAlgebra.AbstractTriangular, Diagonal}) where {k,T}
# Note: https://github.com/cscherrer/MeasureTheory.jl/issues/100#issuecomment-852428192
c = k + 2(d.η - 1)
@tullio s = (c - i) * log(L[i,i])
return s
end
```

The simplicity here is really appealing; this ought to be very fast to compute. The normalization constant is the same as for the LKJ distribution. Distributions.jl has [several functions](https://github.com/JuliaStats/Distributions.jl/blob/master/src/matrix/lkj.jl) for computing this, depending whether we need the general or "uniform" (eta==1) case. For context, a comment in that file says,
> If f(R; n) = c₀ |R|ⁿ⁻¹, these give log(1 / c₀).

The computation looks like this:
```julia
function lkj_onion_loginvconst(d::Integer, η::Real)
# Equation (17) in LKJ (2009 JMA)
sumlogs = zero(η)
for k in 2:d - 1
sumlogs += 0.5k*logπ + loggamma(η + 0.5(d - 1 - k))
end
α = η + 0.5d - 1
loginvconst = (2η + d - 3)*logtwo + logbeta(α, α) + sumlogs - (d - 2) * loggamma(η + 0.5(d - 1))
return loginvconst
end
```

It would be nice if this depended only on the dimensionality `d` and not on `η`. Since we would write this as `LKJL{d}((η=η,))`, that would allow the normalization constant to depend only on the type, and not its value.

Unfortunately, this is not the case. This means we'll need to split this into two terms. one depending only on `d`, and the second including `η` as well. The former can be absorbed into the base measure, which should speed things up a bit.

# The actual question

It's very common for `η` to be fixed, usually at `η=2.0`. In that case, it would be better to have all of `lkj_onion_loginvconst` in the base measure, which may never need to be computed at all.

One possibility is to drop the standard of the base measure depending only on the type. In some cases, for example in superposition, we'll need to be able to compute a common base measure across several measures. Would something like that help us here?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.