微网站是官网的手机站,2 如何写一份详细的网站开发方案,微软手机做网站服务器,600多个微信小程序源码rete我刚刚完成了有关新规则算法PHREAK的高级文档#xff0c;PHREAK是混合推理中的一个文字游戏。 它仍然有点粗糙和高水平#xff0c;但希望仍然很有趣。 它建立在ReteOO之上#xff0c;非常好阅读。 ReteOO算法 ReteOO是在3、4和5系列发行版中开发的。 它采用了RETE算法并… rete 我刚刚完成了有关新规则算法PHREAK的高级文档PHREAK是混合推理中的一个文字游戏。 它仍然有点粗糙和高水平但希望仍然很有趣。 它建立在ReteOO之上非常好阅读。 ReteOO算法 ReteOO是在3、4和5系列发行版中开发的。 它采用了RETE算法并应用了众所周知的增强功能现有的学术文献都涵盖了所有这些增强功能 节点共享 共享同时应用于Alpha和Beta网络。 Beta网络共享始终来自根模式。 字母索引 具有许多子级的Alpha节点使用哈希查找机制以避免测试每个结果。 Beta索引连接不存在节点和存在节点使用哈希索引它们的内存。 这减少了相等检查的联接尝试。 最近范围索引已添加到“不存在”中。 基于树的图 联接匹配不包含对其父项或子项匹配的任何引用。 删除将不得不再次重新计算所有联接匹配这涉及重新创建所有那些联接匹配对象以便能够找到应删除元组的网络部分。 这称为对称传播。 树形图提供了父级和子级引用因此删除仅需遵循这些引用即可。 这是不对称传播。 结果更快对GC的影响更小并且更健壮因为如果在未通知引擎的情况下发生值更改则不会导致内存泄漏。 就地修改 传统的RETE将修改实现为删除插入。 这将导致所有联接元组都经过GC处理其中许多作为插入的一部分再次被重新创建。 相反就地修改传播为一次通过检查每个节点 React性 也称为“新触发条件”。 允许更精细的React性来更新。 模式可以对特定属性的更改做出React而忽略其他属性。 这样可以减轻递归问题并有助于提高性能。 子网 否“存在”和“积累”可以各自具有嵌套的条件元素这些条件元素形成了子网。 向后链接 支持用于反向链接的Prolog样式派生树。 该实现是基于堆栈的因此对于大型图不存在方法递归问题。 懒惰真相维护 真相维护会产生运行时成本无论是否使用TMS都会产生运行时成本。 惰性TMS仅在首次使用时将其打开。 此外它仅针对该对象类型启用因此其他对象类型不会产生运行时成本。 基于堆的议程 议程使用二进制堆队列按显着性对规则匹配进行排序而不是使用任何线性搜索或维护方法。 动态规则 可以在运行时添加和删除规则而引擎仍将填充数据。 PHREAK算法 Drools 6引入了一种新算法试图解决RETE的一些核心问题。 该算法不是从头开始重写的方法它结合了ReteOO的所有现有代码及其所有增强功能。 虽然PHREAK是RETE算法的改进但它不再被归类为RETE实现。 就像动物进化超过特定点并改变关键特征一样该动物也被归类为新物种。 无论优化如何有两个关键的RETE特征可强烈识别任何衍生菌株。 这是一个渴望的面向数据的算法。 在插入更新或删除操作期间完成所有工作的地方 急于产生所有规则的所有部分匹配。 相反PHREAK被描述为一种懒惰的面向目标的算法。 部分匹配会被严重延迟。 RETE的这种渴望会导致大型系统中的大量用户流失并浪费大量工作。 浪费的工作归类为不会导致解雇的匹配工作。 PHREAK受到许多算法的启发。 包括但不限于LEAPSRETE / UL和面向集合的匹配。 PHREAK具有ReteOO部分中列出的所有增强功能。 此外它还添加了以下增强功能集将在以下各段中进行详细说明。 三层上下文记忆 节点段和规则存储器。 基于规则分段和节点的链接。 懒惰延迟规则评估。 孤立的规则评估。 面向集合的传播。 基于堆栈的评估包括暂停和继续。 当PHREAK引擎启动时所有规则都被认为是未链接的因此当规则未链接时将不会进行任何规则评估。 进入Beta网络之前插入更新和删除操作已排队。 根据最有可能导致解雇的规则使用一种简单的启发式方法来选择下一个评估规则 这会延迟评估和触发其他规则。 尽管尚未完成任何工作但只有在规则中填充了所有正确的输入后该规则才被视为已链接。 而是创建一个代表规则的目标并将其放入优先级队列。 这是由显着性命令的。 每个队列本身都与AngendaGroup相关联。 只有活动的AgendaGroup会检查其队列以最高显着性弹出规则的目标并将其提交评估。 因此完成的工作从插入更新删除阶段转移到fireAllRules阶段。 仅评估为其创建目标的规则而根据这些事实进行的其他潜在规则评估将被延迟。 在评估各个规则时仍然可以通过分段过程来实现节点共享这将在后面进行说明。 RETE中每次成功的加入尝试都会产生一个元组或令牌或部分匹配该元组将传播到子节点。 因此它被描述为面向元组的算法。 对于到达的每个子节点它将尝试与该节点的另一侧进行联接每次成功的联接尝试都会立即传播。 这将产生下降递归效果。 当节点网络从进入beta网络的点到所有可到达的叶节点上下左右波动时对节点网络进行处理。 PHREAK传播是面向集合或面向集合的而不是面向元组的。 对于正在评估的规则它将访问第一个节点并处理所有排队的插入更新和删除。 将结果添加到集合中并将该集合传播到子节点。 在子节点中所有排队的插入更新和删除都将被处理并将结果添加到同一集合中。 完成后该集合将传播到下一个子节点依此类推直到到达终端节点。 这将创建单程管道类型的效果该效果与正在评估的当前规则隔离。 这会产生批处理效果可以为某些规则构造提供性能优势 例如具有累积作用的子网。 将来它将依靠多种方式来利用多核计算机。 链接和取消链接使用基于网络分段的分层位掩码系统。 构建规则网络后将为由同一组规则共享的节点创建分段。 规则本身是由段的路径组成的尽管如果没有共享则将是一个段。 将位掩码偏移量分配给段中的每个节点。 另外将另一个位掩码分层分配给规则路径中的每个段。 当至少有一个输入数据传播时节点的位设置为on。 当每个节点的位设置为on时段的位也设置为on。 相反如果任何节点的位设置为关闭则该段也将设置为关闭。 如果将规则路径中的每个细分均设置为启用则将规则链接到该规则中并创建一个目标来计划该规则以进行评估。 相同的位掩码技术还用于跟踪脏节点段和规则。 如果自上次评估以来被认为是肮脏的规则则可以安排已经链接的规则进行评估。 这样可以确保没有规则会评估部分匹配如果由于其中一个联接没有数据而导致它无法导致规则实例的情况则不会评估。 在RETE中这是可能的并且即使最后一个连接为空也会为所有节点产生不必要的武术匹配尝试。 虽然增量规则评估始终从根节点开始但脏位掩码用于允许跳过不脏的节点和段。 使用每个节点至少存在一项数据是一种相当基本的启发式方法。 未来的工作将试图进一步延迟链接 使用诸如弧度一致性之类的技术来确定匹配是否会导致规则实例触发。 由于RETE仅具有一个单一的存储器单元节点存储器因此PHREAK具有3个级别的存储器。 这样可以在评估规则期间获得更多的上下文理解。 PHREAK 3分层存储系统 示例1显示了具有三种模式的一条规则 AB和C。它形成单个段节点的位1、2和4。 示例1单一规则不共享 示例2演示了添加另一个共享模式A的规则时会发生的情况。A放置在其自己的细分中每个规则导致两个细分。 这两段形成了各自规则的路径。 第一条路段由两条路径共享。 当链接A时该段将被链接然后迭代该段共享的每个路径将位1设置为on。 如果稍后打开B和C则链接到路径R1的第二段 这将导致R1的位2被打开。 将R1的位1和位2设置为打开后现在将链接该规则并创建一个目标以计划该规则以供以后评估和触发。 评估规则时正是可以共享匹配结果的细分。 每个段都有一个暂存存储器用于对该段的所有插入更新和删除进行排队。 如果要评估R1它将处理A并得到一组元组。 该算法检测到存在分段拆分并将为集合中的每个插入更新和删除创建对等元组并将它们添加到R2的暂存中。 这些元组将与任何现有的暂存元组合并并等待R2最终被评估。 示例2共享的两个规则 示例3添加了第三条规则并演示了共享A和B时发生的情况。 这次仅显示段的位。 证明R4具有3个段R3具有3个段R1具有2个段。 A和B由R1R3和R4共享。 而D由R3和R4共享。 示例3共享的三个规则 当“不存在存在或累积”节点包含多个元素时形成子网。 在示例4中“ B notC”形成子网请注意“ notC”是单个元素不需要子网并且在Not节点内部合并。 子网拥有自己的网段。 R1仍具有两个段的路径。 子网形成了另一个“内部”路径。 链接子网时它将链接到外部网段。 示例4单规则具有子网且不共享 示例5显示了可以通过不具有子网的规则对子网节点进行分片。 这导致子网段被分成两个部分。 示例5两条规则一条与子网共享 并非具有约束的节点和累积节点都具有特殊的行为并且永远无法取消链接段并且始终将其视为打开状态。 所有规则评估都是增量的不会浪费已经重新产生的工作重新计算匹配项。 评估算法基于堆栈而不是方法递归。 通过使用StackEntry表示正在评估的当前节点可以随时暂停和恢复评估。 当规则评估到达子网时将为外部路径段和子网段创建StackEntry。 首先评估子网段当集合到达子网路径的末尾时将其合并到其馈入的外部节点的暂存列表中。 然后恢复先前的StackEntry在其中可以处理子网的结果。 这样做还有一个好处就是所有工作在传播到子节点之前都将被批量处理。 这对于累积节点效率更高。 相同的堆栈系统可用于有效的反向链接。 当规则评估到达查询节点时它会通过将其放在堆栈上来再次暂停当前评估。 然后对查询进行评估生成结果集该结果集保存在存储位置中以供恢复的StackEntry拾取并传播到子节点。 如果查询本身调用了其他查询则该过程将重复当前查询被暂停并为当前查询节点设置新的评估。 关于性能的最后一点。 通常使用PHREAK的单个规则不会比使用RETE更快。 对于使用根上下文对象启用和禁用匹配的给定规则和相同数据集它们都尝试相同数量的匹配并产生相同数量的规则实例并且花费的时间大致相同。 除了带有子网的用例和积累。 但是可以认为PHREAK相对于RETE而言对于编写得不好的规则库更为宽容并且随着规则数量和复杂性的增加性能也会更加适度地下降。 RETE还将为不包含所有联接中数据的规则生产部分机器。 PHREAK会避免这种情况。 因此并不是说PHREAK比RETE快它不会随系统的增长而变慢。 AgendaGroups对RETE的表现没有帮助因为所有规则都在任何时候进行评估而与组别无关。 显着性也是如此。 这就是为什么经常使用根上下文对象来限制匹配尝试的原因。 PHREAK仅评估活动AgendaGroup的规则并且在该组中将尝试避免评估通过显着性不会导致规则实例触发的规则。 通过PHREAK AgendaGroups和显着性现在已成为有用的绩效工具。 根上下文对象不再需要并且可能对性能产生反作用因为它们会强制刷新和重新创建规则的匹配项。 参考在DroolsjBPM博客上可以从我们的JCG合作伙伴 Geoffrey De Smet 获得PHREAKY的RIP RETE时间 。 翻译自: https://www.javacodegeeks.com/2013/11/r-i-p-rete-time-to-get-phreaky.htmlrete
