【机器学习】关联规则与FP-Tree

FP-Tree算法

  FP-Tree算法只需要遍历一次事务,然后可以建立FP-Tree树形数据结构来表征事务项目出现的关系。FP-Tree相比原始事务,将各个事务压缩到一个树,保存了项目之间的关系和出现频数,但是规模小得多。我可以直接根据FP-Tree来获取所有事务项目集合出现的次数。
  下面是初始化步骤:
  1、事务项目排序。假设我获取了事务T,首先计算每个事务项目出现的次数,把单个事务项目次数少于阈值的事务项目去掉,因为这些事务项目的父集合一定不是频繁集。剩下的事务项目都是1元频繁集,按照出现次数降序列表,称为F1。设F1表为:A,B,C,D
  2、根据F1的顺序,重新对每个事务进行排序。设某条事务为:C,D,A,则重排序为A,C,D。
  3、每个排好序的事务都是一条路径,我可以根据路径构建一棵树,书的根节点设为NULL。如项目事务为ACD,ABC,BC,那么可以构建树,树节点冒号跟着出现次数:
  【机器学习】关联规则与FP-Tree_第1张图片
  FP-Tree算法从这里开始进入递归步骤,算法为(http://www.cnblogs.com/zhangchaoyang/articles/2198946.html):
  

输入:事务集合 List> transactions
输出:频繁模式集合及相应的频数 Map,Integer> FrequentPattens

初始化 PostModel=[],CPB=transactions
void FPGrowth(List> CPB,List PostModel){
    if CPB为空:
        return

    统计CPB中每一个项目的计数,把计数小于最小支持数minSuport的删除掉,对于CPB中的每一条事务按项目计数降序排列。
    由CPB构建FP-Tree,FP-Tree中包含了表头项headers,每一个header都指向了一个链表HeaderLinkList,链表中的每个元素都是FP-Tree上的一个节点,且节点名称与header.name相同。
    for header in headers:
        newPostModel=header.name+PostModel
        把加到FrequentPattens中。
        newCPB=[]
        for TreeNode in HeaderLinkList:
            得到从FP-Tree的根节点到TreeNode的全路径path,把path作为一个事务添加到newCPB中,要重复添加TreeNode.count次。
        FPGrowth(newCPB,newPostModel)

   假设当前已知频繁集B,我要找包含B且为频繁集的父频繁集,需要找到从根节点到B的所有路径来构建一个新的FP-Tree。B就是postmodel后缀模式,简写为PM;根节点到B的所有路径的集合就是CPB条件模式基。CPB中可能有重复的路径,或者不同路径有重复部分,迭代过程中按照上面的方法,用CPB来构建包含支持度信息的FP-Tree。FP-Tree中单根分叉的子节点的支持度,一定小于等于父节点的支持度;不过子节点总的支持度,可能比该子节点的某个父节点要多(情况二)。这是对事务进行排序后获得的有序结果。假设支持度阈值为最少出现3次。
  上述迭代函数FPGrowth,第一步的输入,CPB是原始的、排除了1元非频繁集的事务路径,PM是空,写作NULL,可以认为根节点到NULL的路径是所有的初始化事务路径;header表头项理所当然是就是F1表。第一步我遍历F1表,表上的项目已经满足支持度条件了,因此我将NULL和这些项目组合,这样就找出了所有的1元频繁集。然后遍历这些1元频繁集,倒序依次取表头项Headers的元素X作为newPM,找到当前FP-Tree中根节点到X的所有路径作为newCPB,进行下一次关于X的迭代FPGrowth;关于X的搜索完成后,再回来进行X上一个元素W的搜索。整个过程类似深度搜索。
  假设D频繁集(含有N个元素,N>0)为PM,已知CPB,那么我重新构建FP-Tree,以及一个新的表头项Headers,Headers保存当前FP-Tree中存在的元素的总出现次数。次数少于支持度阈值的节点可以预先排除。我画出情况(1):
  【机器学习】关联规则与FP-Tree_第2张图片
  由于我的CPB是根节点到D的所有路径,如果FP-Tree中只有一条路径,那么这条路径上的节点,都可以到D三次,彼此之间也都可以共存3次,ABC任意组合都满足支持度阈值。因此ABC可以任意组合,然后末尾加上D后缀模式组成频繁集,出现次数为3,加入置信度计算队列中,关于D的搜索结束。注意真实事务中,如A->B的路径可能大于3,多出来的路径是不会到D,我构建D的CPB时,多余的路径被排除了;这一轮分析中,只能得出包含D的频繁集以及频数,比如A->B的实际路径频数可能大于3,虽然我可以认定AB是频繁集,但是不能获得该频繁集的真实频数,必须在之后的迭代中才能计算得到。
  如果新FP-Tree有多条路径,那么我必须用Headers表头统一分析,不能沿着树的分叉进行分析。我画出情况二:
  【机器学习】关联规则与FP-Tree_第3张图片
  可以看出,第一条和第二条路径中项目的支持度都为2,但是CD是频繁集。如果单纯分析每个分叉,那么会得出没有频繁集的错误结论。这时候我需要使用刚刚建立的新表头项Headers:
  A:2 B:2 C:4 (D:4)
  根据表头项,C的支持度为4,即后缀模式D可以和C组合成为支持度为4的频繁集,然后作为新的后缀模式CD。在下一轮迭代中,新CPB的第一条路径的节点(A:2->B:2)的支持度不满足条件,第二条路径为空,包含D的频繁集搜索完毕。
  现在我来看看这个迭代过程是否能完全搜索所有的频繁集。在一次FP-Tree迭代中,我们的搜索从Header表头中支持度低的事务项目开始,这样就可以保证搜索的有序。新FP-Tree的构建严格遵循第一次构建FP-Tree时的表头Header的各个事务项目的顺序,表头中排序靠后的事务项目,在树的单根分叉中永远不可能出现在排序靠前的事务项目的前面。这样,假设事务项目有ABCD,从D开始迭代搜索,可以扫描包含D的所有候选频繁集;从C开始搜索,会扫描包含C且不包含D的候选频繁集,这样就不会重复。经过迭代搜索后,所有可能的候选频繁集都会被扫描到。

你可能感兴趣的:(模式识别与机器学习,数据挖掘)