"Big Data" and the Future of DevOps

Recorded at:

I took a look at the source code for both Seresye and eresye. If I understand the code correctly, both do not implement RETE algorithm properly. I've been studying RETE since 2000 and implemented RETE algorithm. The design and implementation in Seresye and Eresye do not appear to be correct. RETE network isn't a tree, it's a directed acyclic graph (DAG). In a classic tree structure, each node has 1 parent and multiple children. Nodes in a DAG on the otherhand can have 1 or more parents. In the case of RETE, join nodes have 2 parents, and alpha nodes have 1 parent. Each join node has 1 alpha memory and 1 beta memory. Neither Seresye or Eresye appear to follow that design, which would mean it doesn't implement RETE.

Just about every open source rule engine that has attempted to implement RETE has made this mistake. The other thing I noticed is it appears both implementations only support ordered facts, which is known to be less efficient than unordered facts. When you use ordered facts, it severely limits node sharing. There are ways around it, but it doesn't appear Seresye or Eresye use those techniques to optimize for ordered facts.

As far as I can tell, it's a simple forward chaining rule engine and not a RETE implementation.

I don't know what SERESYE implements, but tree graphs as enhancements to RETE are well known. There are three recognised network types:
linear
bi-linear
binary

title: "Advances in Rete Pattern Matching" from 1986:
chapter: "Arbitrary Grouping of Pattern Condition Elements
www.aaai.org/Papers/AAAI/1986/AAAI86-037.pdf

title: "Efficient Matching Algorithms for the SOARlOPS Production System"
chpater: Non-Linear Networks
reports.stanford.edu/pub/cstr.old/reports/cs/tr...

There are use cases where non-linear helps, but also where it hinders - as discussed in the last paper.