| Thread Previous • Date Previous • Date Next • Thread Next |
<ari.heljakka@xxxxxxxxxxxxxx> wrote:From my understanding of the code, the validate methods don't actuallycheck the order of < L2, L1 > is invalid. Just that the types are correct since it only checks one handle/Vertex at a time and I don't see how it would share any binding information between calls to weak_atom...Correct.Would it not make sense to try and validate the order and that they fit. Or would this be too costly?
The question cannot be answered outside the context of the overall dynamics of your algorithm.
[1] whereas the o2iMeta functions DO ensure that the shared atoms of links are correct, but I could be completely wrong. I'm confused about whether these output-to-input functions can be used for forward chaining too.o2i function do check the variable consistency, but the method for doing that is rather tightly integrated with the whole binding scheme. Basically, you don't actually check for consistency in the o2i approach at all; instead, you start out with the correct formula with variables (eg. DeductionRule($1=>$2, $2->$3) and then create a new instance of the whole Rule (or rather, the BITNode that embodies the Rule) by binding one of the variables to some Atom, eg. resulting in DeductionRule($1=>MyAtom, MyAtom->$3). This way, consistency is guaranteed. This does cost space and time for cloning the BITNodes, but then again ensuring consistency across large trees by other means is a hairy problem.So you're saying that in order to check the consistency we need to wrap the Rule in a BITNode and use that? Does that BITNode then represent the result of the rule application (sorry if this is exceedingly basic, I just want to confirm that my understanding is correct)?
Yes, and partially yes. The BITNode is a rather bulky class, allowing you also to store the inference results in the object, which the bw chainer does. (The bulkiness is a result of numerous successive changes in design.)
But, BITNode was not designed to be modular enough so that it'd lend itself for forward-chaining; the most useful part here is to understand the algorithmic idea, whereas the cost of the adaptation of the existing code to implement that idea in fw chaining is unknown to me.
If the BITNode is the result, then for forward chaining, could I just make a BITNode with the rule but without a specific target and still use it for checking rule variable consistency?
Perhaps, but I'm not sure if it's the best way to do it...Overall: the BITNode class simply was not designed to support fw chaining in any way. OTOH, the Rules and Formulas were explicitly designed to be usable for both fw and bw chaining.
-- Ari Heljakka CTO Dream Broker Ltd Tekniikantie 14 ari.heljakka@xxxxxxxxxxxxxx 02150 Espoo +358 40 568 2420 Finland www.dreambroker.fi
| Thread Previous • Date Previous • Date Next • Thread Next |
