Posterior query without non-negative constraints (ApproxLP)

[rcabanasdepaz]

When running a posterior query without nonnegative constraints and without the epsilon perturbation of 0.0 values, the inference could fail. The reason is that the factor in the denominator contain zeros. This produces many NaN values, which cannot handled by the optimiser.

One possible solution is to keep non-negative constraints and perturb them by adding an epsilon value. However, this can make inference untracktable in large networks. Find a solution that allows omitting non-negative constraints.

Code example:

      double eps = 0.0000001;
        String prj_folder = ".";

        SparseModel model = (SparseModel) IO.read(prj_folder+"/models/chain3-nonmarkov.uai");
        for(int v : model.getVariables()) {
            SeparateHalfspaceFactor f = (SeparateHalfspaceFactor) model.getFactor(v);
            f = f.mergeCompatible();
            f = f.removeNormConstraints();
            //f = f.removeNonNegativeConstraints();   // Not working WITH this
            f = f.getPerturbedZeroConstraints(eps); // Not working WITHOUT this

            model.setFactor(v, f);
        }

        for(int v : model.getVariables()) {
            ((SeparateHalfspaceFactor) model.getFactor(v)).printLinearProblem();
        }

        CredalApproxLP inf = new CredalApproxLP(model);
        SparseModel infModel = (SparseModel) inf.getInferenceModel(1, ObservationBuilder.observe(2,0));

        System.out.println(
                inf.query(1, ObservationBuilder.observe(0,0))
        );

[rcabanasdepaz]

This has been solved (only in posterior queries) in the following way:

• When sampling from the neighbourhood, zeros in sampled factors are replaced by an epsilon value (ch.idsia.crema.inference.approxlp.Neighbourhood::sample)

• After running the optimisation, zeros are also replaced from solution factors. (ch.idsia.crema.inference.approxlp.Posterior::eval)

Modified factors are not normalised to sum 1.