-
Notifications
You must be signed in to change notification settings - Fork 49
Troubleshooting
Why do I get this "Skipping duplicate fact at context_dep_bow.cfacts:4791862:
hasCloseContext s_155766_15_part10 righttok=accompany"?
I have checked, there is only one line of
hasCloseContext s_155766_15_part10 righttok=accompany
in the .cfacts file.
We use a bloom filter to check for duplicate facts, since unintentional duplicates can cause unexpected results (their weight in the graph gets doubled, or tripled, or...). Since ProPPR does this with a bloom filter and not an exact set-membership check, sometimes we can get false positives (hash collisions). The best thing to do in this case is just turn off duplicate checking.
You can turn off duplicate checking using --duplicateCheck -1
The following features are reserved for use by the ProPPR provers:
id(restart)id(trueLoop)id(trueLoopRestart)id(alphaBooster)
QueryAnswerer and Grounder do similar things (prover-based inference) but for different purposes. QueryAnswerer lists all the solutions to a query, labelled or not. This output can be used for things like sampling negative examples and computing accuracy metrics. Grounder lists the proof graph for a query, including markers for postive-labeled and negative-labeled solution nodes. This output is generally only used for training. A query that don't hit any of the labeled solutions won't have any effect on the gradient at training time, so Grounder skips queries like these. QueryAnswer doesn't care about labels, so it does print output for these queries.
edu.cmu.ml.praprolog.prove.LogicProgramException: Error converting features of rule ...
This happens because ProPPR couldn't bind the variables used in the features of a rule. Remember that the variables in a feature must be bound in the head of the rule -- the body is too late.
Let's say we want to be able to call associatedWith(bear,X) and learn whether the word "bear" is associated with each of our categories, which will be subbed in for X. We have a facts file that lists all the categories, called isCategory.
This rule won't work:
associatedWith(Word,Category) :- isCategory(Category) # f(Word,Category) .
...because Category isn't being bound until the isCategory lookup in the body of the rule.
To fix it: move the feature down a level.
associatedWith(Word,Category) :- isCategory(Category),learn(Word,Category) .
learn(Word,Category) :- # f(Word,Category) .
Now when we call associatedWith(bear,X), X is bound by isCategory, and then we call e.g. learn(bear,zoology) and can use those values for the feature f.
edu.cmu.ml.praprolog.prove.MinAlphaException: minAlpha too high! Did you remember to set alpha in logic program components? dpr minAlpha =0.1 localAlpha=0.08333333333333333 for state ...
This can happen if (1) you're using the default prover and (2) your graph has a fanout of 10 or more.
Background: alpha is the probability of reset, and minAlpha is the bound on that probability that makes our pagerank approximation possible. Unfortunately, if you get this error it means our pagerank approximation is no longer accurate and any results you get are basically garbage.
The default minAlpha is 0.1, or 1/10. This means if any node in the graph has more than 10 outgoing edges, the reset probability is going to fall below 1/10, and violate the constraint.
To fix it: Set minalpha according to your graph in your prover specification. If you know the maximum fanout of your graph (i.e. the maximum out-degree of a node), you can use 1/that for minalpha. Otherwise, look at the localAlpha part of the error message, and pick a number lower than that to use for minalpha. In the example above, 0.08 would be fine. It's a good idea to use the same minalpha value for all your examples, so if you see multiple errors like this, pick the lowest localAlpha value to base your new minalpha off of.
To set minalpha on a dpr prover (the default), use --prover dpr:{epsilon}:{minalpha} on the command line. [epsilon is the error bound on the approximation; if you're not sure what to put there use 1e-5]