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...

[belledon]

thanks for the post! we should talk more about this after the cogsci daedline..

i don't agree with the second green box labelled distribution component. fundamentally, i believe that thinking of a wordly generative process (hence the k ways to make the set) is a crutch. These are sets. it is not necessary to describe them as being generated from permutations.

i think there is a misunderstanding in what i was trying to do here with GenRFS, generalizing random finite sets, that i can clear up in your other thread.

still happy to discuss more soon but for now, i would appreciate no major changes to the math. namely that the support over cardinality is independent over the support over observation elements

[belledon]

(whoops accidently posted the following comment to the wrong issue)

hey @eivinasbutkus , just wanted to let you know that there was an update on this front.

In MOT, we noticed that the pdf of an RFS was changing as a function of cardinality alone, even when the rfs was a good explanation of the observation. That finally made this thread click for me. A RFS that is a good explanation of a large observation should have a similar log score to an RFS that is a good explanation of a small observation.

You were spot on that the discrepancy in logscore would be due to using the standard poisson pdf.
however the formula above is not the proper normalization.
According to https://youtu.be/sRnVZVdKXLA?t=397 there is a lambda raised to the mk power that needs to be removed. rahter than using Gen's full logpdf and dividing by that factor, i chose to just compute the proper logpdf directly (and understanding a cool trick with loggamma. see ccaf785