poisson factorial issue

[eivinasbutkus]

will put equation down later

[eivinasbutkus]

So I think PPP should have the pdf according to Chalmers people. The only difference is division by factorial. I believe the pdf is multiplied by the factorial because the order doesn't matter (around 8:30min mark).

[belledon]

isnt this what we have already in the src?

GenRFS/src/elements/poisson.jl

Lines 12 to 14 in 7d67949

	function cardinality(rfe::PoissonElement, n::Int)
	Gen.logpdf(poisson, n, rfe.λ)
	end

where the pdf is

function logpdf(::Poisson, x::Int, lambda::Real)
    x < 0 ? -Inf : x * log(lambda) - lambda - loggamma(x+1)
end

or is the -loggamma(x+1) incorrect

[belledon]

i didnt have a chance to re-watch the video but i'm not sure why the current implementation is overcounting order

[belledon]

yeah i just watched the video. we are not operating over random matrices. To calculate the partial probability of a poission element with a particular schema, we do not need to multiply by the factorial since we are not treating the internal partition as a vector but as a set

[belledon]

i think this is difference is due primarily in the difference in the construction of their correspondence table and the partition table in our code.

[eivinasbutkus]

It could very well be that I'm missing something. But if you're operating within random matrices/vectors, then you need to divide by the factorial to get the pdf for a particular permutation, and to get the pdf of the set, you need to multiply the pdf of one permutation by the factorial.

[eivinasbutkus]

in the last line, if you multiply both sides by the factorial, you get the pdf of the set, right?

[eivinasbutkus]

the difference between the two pdfs is important because if the Swedish one sums to 1, then the other will sum to something <1.

[belledon]

but what is the domain that needs to sum to one?
Later in the video they have a bit where the order matters in their pdf that isnt true on this implementation
. Lets try and work it out with this example:

r1 = 3
p1 = PoissonElement{Float64}(r1, normal, (0., 1.0))
r2 = 0.4
b1 = BernoulliElement{Float64}(r2, uniform, (-1.0, 1.0))
pmbrfs = RFSElements{Float64}(undef, 2)
pmbrfs[1] = p1
pmbrfs[2] = b1
julia> s = rfs(pmbrfs)
3-element Array{Float64,1}:
  0.7104383645798223
 -0.9575397317240311
  0.8250133413056314

julia> logpdf(rfs, s, pmbrfs, record)
-4.294921071221889

julia> display(collect(zip(record.table, record.logscores)))
4-element Array{Tuple{Array{Array{Int64,1},1},Float64},1}:
 ([[1, 3], [2]], -1.24100135244485)
 ([[1, 2], [3]], -1.359119014693774)
 ([[2, 3], [1]], -1.4470811864264883)
 ([[1, 2, 3], []], -1.5197687658964778)

for the first partition the logpdf goes something like

ls = 0
ls += logpdf(poisson, 2, 3) + logpdf(normal, 0.710, 0.0, 1.0) + logpdf(normal, 0.825, 0.0, 1.0)
ls += logpdf(r2) + logpdf(uniform, -0.957, -1, 1.0)

i'm having a hard time seeing how anything here is ordered other than the random finite elements themselves

[eivinasbutkus]

What needs to sum to one are the pdfs of all possible sets. I think that's important in the context of normalizing the amount that the PPP component adds to the explanation in relation to the MBRFS component. Like if you do not normalize PPP pdf (say multiply it by 1e200), then you will end up with a likelihood where MBRFS does not matter at all.

[eivinasbutkus]

if what I'm saying is correct (not completely sure), then I think you need to add:

ls += logpdf(poisson, 2, 3) + logpdf(normal, 0.710, 0.0, 1.0) + logpdf(normal, 0.825, 0.0, 1.0) + log(2!)

[belledon]

is that true for the example we have here of one brf + one poisson ?

[belledon]

I think that's important in the context of normalizing the amount that the PPP component adds to the explanation in relation to the MBRFS component. Like if you do not normalize PPP pdf (say multiply it by 1e200), then you will end up with a likelihood where MBRFS does not matter at all.

i'm really not sure about this. wouldnt adding log(k!) increase the "representation" of the poisson component?

[eivinasbutkus]

true, I guess it's the other way now -- underrepresenting the poisson

[eivinasbutkus]

Ok, I think I figured this out by thinking about GenRFS in relation to tracked distractors -- I'll lay out the general concern/thought after this PPP factorial issue because I think it's related.

The key was a mistake in the likelihood of the set given a sampled cardinality and given the "support" distribution used in the PPP:

So you may think that a solution would be to add log(k!). But the question is where would you add it. The cardinality equation for the PPP is correct, i.e. it's poisson distributed. But there is no clear to incorporate it into the support either (perhaps add log(root_k(k!)) in each support call??).

To be continued in a new thread...