stecrotti / matrixproductbp.jl Goto Github PK

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Having a term $p_i^0(x_i^0)$ and a term $\phi_i^0(x_i^0)$ is redundant. Keep only the latter

I suspect that the functions needed to define a RecursiveBPFactor are not general enough if we want to do things like epidemics with heterogenous infection rates, or $\pm J$ Ising models.

Example: prob_xy(wᵢ::RecursiveBPFactor, yₖ, xₖ, xᵢ) computes $p(y_k^t|x_k^t,x_i^t)$ which for $\pm J$ Ising is
$p(y_k^t|x_k^t,x_i^t)=\delta(y_k^t, x_k^t J_{ik})$. But how do we retrieve $J_{ik}$?

Solution: re-define some functions including the index of k in the list of neighbors of i. That way we can access properties of wᵢ.

Something like (up to the correct change of variables between {+1,-1} and {1,2}:

prob_xy(wᵢ::PlusMinus1GlauberFactor, yₖ, xₖ, xᵢ, idx_k) = ( yₖ != xₖ*wᵢ.J[idx_k] )

Since we introduced LoopVectorization:

┌ Warning: #= /home/crotti/.julia/packages/Tullio/NGyNM/src/macro.jl:1093 =#:
│ `LoopVectorization.check_args` on your inputs failed; running fallback `@inbounds @fastmath` loop instead.
│ Use `warn_check_args=false`, e.g. `@turbo warn_check_args=false ...`, to disable this warning.
└ @ MatrixProductBP.Models /home/crotti/.julia/packages/LoopVectorization/m1H1K/src/condense_loopset.jl:1148

Looks totally harmless, but we could take a look at it at some point

Make BP iterations for SimpleBPFactors even more efficient by performing "all-but-one" computation the smart way.
Side effect: get message to dummy neighbor for free

Here https://github.com/stecrotti/MatrixProductBP.jl/blob/457068104f03d3e3fc8bb4d787def316733740c6/src/Models/epidemics/sis_heterogeneous.jl#L39 for a given site, all factors at times $0,1,\ldots,T$ are pointing to the same reference because we used fill.

Maybe it would be good to have simple MPEMs to store single node trajectory beliefs?

Get rid of square roots which are needed only because currently pair observations are placed half on outgoing messages and half on ingoing messages.
Will need to adjust pair beliefs accordingly.

Generalize to all those types of factors where

where $\bigoplus$ is an operation like sum, product, AND, etc

The BP update can be parallelized easily...

It would be good to see which parts of the code are covered by tests...