文件列表:

AOC_limit (0, 2017-11-22)
AOC_limit\运行结果 (443, 2017-11-22)
AOC_limit\test2.m (1394, 2017-11-22)
AOC_limit\test.m (523, 2017-11-22)
AOC_limit\print_data.m (1164, 2017-11-22)
AOC_limit\paper_exp.m (1928, 2017-11-22)
AOC_limit\AOC_limit.png (37044, 2017-11-22)
AOC_limit\AOC_01bagging_with_limit.m (5803, 2017-11-22)

1. 首先完成AOCbaggig的程序后,用第一组数据测试,发现不收敛,结果和纯粹的随机一模一样 原因是代码bug for it = 1:iterate_num deltaMone = zeros(obj_count, 2); [mone,chance] = update(mone, E, deltaMone, p, apha, beta); deltaMone的置零应该放到迭代的结束,而不是更新信息素和概率的前面,否则deltaMone的完全没有被使用 2. 修改后发现数据很难保持前面的结果,震荡太明显,将升华因子p=1/3 --> p=1/9,调高以往数据的作用 3. 对于二分的01背包问题,解空间较小, 复杂度2^n,效果较为明显,但是对于test2.m中的22种物品,上下限制为1和5的问题,解空间呈幂指数增长,始终不收敛,而且和最优解相差较大。 试着改动了p(升华因子), Q(deltaMone的影响常数), M(蚂蚁数), N(迭代次数),但是结果没有任何改进。 原因是逻辑bug 我的零一背包问题的搜索树的搜索顺序是按照物品种类顺序排列固定的,即先按概率选择添加几种第i类物品,再按概率选择添加几种第i+1类物品,但是有后面选择时背包容量变小了, 这样导致后面选择的物品坑能无法按照chance定义的概率来选择。 现象: 我发现一个奇怪的现象是:每次迭代的最优解中各类物品的数量总是要么是数量上限,要么是数量下限。这很符合贪心的规律。 另一个现象是:后面的物品即使value/weight很高,也几乎不会被大量选择。这很不符合贪心的规律,而更像是受到顺序的影响。 我将物品按照 v/w 降序排列作为输入,发现结果马上有原来的500+变成了***0+,最优解700+。 改进: 将搜索树的搜索顺序随机化,即每次蚂蚁运动前先随机出一个选择物品顺序的序列,再去运行。 PS: 同时我们发现信息素的更新函数比较影响收敛的效果,变化越陡的函数震荡相对较大,但是平均结果大致相同 比如dletaMone = sigma(Q / sum_value * totalValue_k) 和 deltaMone = sigma(Q / sum_value * totalValue_k) * it_best_value / best_value 依旧没有解决问题 “每次迭代的最优解中各类物品的数量总是要么是数量上限,要么是数量下限”

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：