回测防撞训练继续觅食训练 & Canset迁移增强 & 测TCCanset和TCScene竞争机制 & 识别二次过滤器 CreateTime 2023.03.20
在n28末，做了Canset迁移性,本节通过防撞训练来回测;
29011
回测迁移性挂在所有pFos下: pFos有不全的问题
训练
根据防撞前两步训练;
问题
发现canset挂在所有pFos下,竟然不包含触发者selfPFo本身;
调试
经查,构建pFo时,pFo在baseRDemand下,只是后来应该什么时候被删了,需要明天继续查下;
查明
在forecast中,pFo先失效,后调用的生成Canset,导致生成时此pFo已经失效未加上Canset;
修复
改为先生成Canset,再设pFo为失效后好了 T;
29012-关于Canset迁移效率太低的问题
测试: 经29011测试中发现: 其实每条pFo都会生成一次Canset;而它们生成的Canset也大致是相同的,只是触发有先后而已;
回测失败: 那我们上节中,将新Canset挂到所有pFos下,作用其实不大……(改动前的问题会依旧);
分析原因: 现通过pFos传递经验的方案,只能邻近传递;
反证观点: 那么在试错时,如果不邻近呢?肯定传递失败…即:我们假设能成功并且大胆尝试不够;
本质问题: 即迁移效率不够 (总不能等被撞死几十回,才普及这个可能有效的经验到各处);
解决方案: 所以,我们还是需要用特征影响不大,来构建抽象方案… (其实相邻宏微带来的定义不一致问题,大可以通过EFF来辅正);
名词说明: 本文构建抽象的问题,在下面统一命名为:"Canset迁移性增强";
29013 -在29012中 ,第1 ,2 ,3 ,4 是猜想 ,本表先实训 `防撞前两步 `验证如下 :
R新Canset :F562 [A559 (高100 ,皮0 ,向19 ,距117 )] (状态 :无反馈 fromPFo :F336 帧 :1 ) 挂pFos下 :(F489 ,F415 ,F557 ,F336 )
R新Canset :F563 [A559 (高100 ,皮0 ,向19 ,距117 )] (状态 :无反馈 fromPFo :F557 帧 :1 ) 挂pFos下 :(F489 ,F415 ,F557 )
R新Canset :F564 [A559 (高100 ,皮0 ,向19 ,距117 )] (状态 :无反馈 fromPFo :F489 帧 :1 ) 挂pFos下 :(F489 ,F415 )
R新Canset :F565 [A559 (高100 ,皮0 ,向19 ,距117 )] (状态 :无反馈 fromPFo :F415 帧 :1 ) 挂pFos下 :()
结果 : 如上日志 ,验证猜想成立 ,执行29012 -6 的解决方案 ;本节测得上节做的Canset迁移性没什么用,我们回滚下代码,然后经分析: Canset迁移不足的问题,还是要通过构建"Canset迁移性增强"来解决,转下节继续;
n29p02 Canset迁移性增强1: 场景Fo外类比、Canset外类比(未完成) CreateTime 2023.03.21
本节针对上节29012-解决方案,本节做"Canset迁移性增强"的方案分析与代码实践;
警告: 本节将面临大改,因为要将外类比Canset迁移性增强打开,整个网络抽具象层级,和决策时下向性,也要相应的兼容多层;
大改原由: 触发本次大改的原因,是Canset的迁移性不足: 即,我们要对各种距离段都训练一次正确的canset才工作顺利,这显然不行,所以提升迁移性是必须要做的,这里记录一下本次大改的原因;
29021
执行前的准备工作-反思下做抽象会不会有什么问题
问题1
这会不会导致过度抽象问题 (参考28186-方案2-追问);
答: 抽具象多层多样性一直在生效,所以不可能过度抽象;
证: 而现在的情况,洽洽是(缺少Canset迁移性增强)抽象的缺失问题;
问题2
这会不会太复杂? (参考28186-方案2-追问);
答: 会复杂,但必要性大,需求明确,可做;
结果
28186-方案2-追问,提到的问题,在本表都做了解答,下表可以正式放开干了;
29022
Canset迁移性增强-方案规划
方案1
根据Canset反推抽象概念 5%;
自辩
1. 正向(左向右)是很难获取无距棒的,因为输入端必定各特征齐全;
2. 要想得到无距棒除非特征一致,但输入端几乎没有一致的情况;
3. 全在决策端,根据强化统计的一致性,来反向判断特征有类似功效却是可以的;
4. 反推抽象概念方案,以增强Canset迁移性,就是利用这一方式来达成的;
优点
更精准;
缺点
但也更复杂;
缺陷
这里比对Canset的共同点,但并不表示也是场景的共同点
缺陷说明: Canset的共同点,与场景的共同点,二者间的衔接是个未接上的坑;
点评
此方案不符合向性原则,且缺陷也难以填上 5%;
方案2
用以前的外类比来达成 95%;
自辩
1. 用原来的外类比: 相近度高的计做sames,然后抽象之;
2. 想得到无距棒并不必须特征一致,只要码相近也是ok的;
3. 共右向性在认知期来实现Canset迁移性增强,更符合认知层是右向性的原则;
4. 以认知期Canset迁移性增强,来带动Canset时的迁移性,此方案看来更好;
优点
效果更广而全面，迁移性更强,也符合认知的向性原则。
缺点
带来混乱度也高 (但好在决策期的竞争机制就是专门克服这里的混乱度的);
缺陷
场景变抽象,但它下面的Canset却并不抽象,本方案需要连带解决此问题;
缺陷说明: 如果Canset不抽象,它的EFF计数就很难累加;
点评
本方案符合向性原则,缺点可解,缺陷看起来也更容易解决 95%;
结果
参考二者的点评,选定方案2,但需要先解决缺陷 转29023;
29023
Canset迁移性增强-方案2-缺陷解决分析
分析1
可以将Canset改成由protoFo的抽象来构建?
a. matchFo下包含的,用matchFo的帧来即可;
b. matchFo下不包含的,则使用matchAlgs中较为抽象的alg来? 转示例-2问题
解析: 即最好是层级跟随: 即在怎样的场景抽具象层级上,Canset就是怎样的抽具象层级
方案
将Canset由protoFo构建改为使用抽象来组建 (抽象层级跟随matchFo);
疑问1
有些帧,不在matchFo中,是层级跟随不到的,需要分析下此问题,如下:
示例
比如: 想吃苹果的时候就买个苹果,想吃水果的时候只要是个水果就行;
1. 可跟随: 上例中的苹果和水果,在场景fo中有包含,所以能够向场景跟随;
2. 问题: 无法跟随问题: 但买的动作是无法向场景跟随的,因为场景fo中,没有买;
思路
此问题场景Fo不包含的,可以用protoAlg,然后在使用Canset时: 此思路采纳
1. 场景Fo包含的严格要求isCansetAlg(是它);
2. 而场景Fo不包含的,反馈cansetAlgIs(它的抽象)即可;
3. 场景不包含的: 也可考虑存成matchAlgs数组 (protoAlg识别到的matchAlgs)?
追加: 此思路-2判为错误,见以下做饭例子,即是反例 此思路错误,废弃;
追加: 平反,此思路-2并不错误,只是它需要从具象向抽象的成长流程 转29024-步骤;
例1
遇到危险时,躲开即可,这里的躲就在canset中,却不在场景fo中;
例2
具象场景fo[想吃批萨]->对应Canset[做批萨],抽象场景fo[想吃饭]->对应Canset[做饭];
分析: 我们尝试去自省这里的躲和做是什么,却很难自省明白 (因为它很抽象);
说明: 做饭的"做"在批萨时是烤,在凉菜时是拌,而躲开的躲在防撞时是飞,在打游戏时是按左;
所以
1. 抽象Canset不执行,真正执行的是具象canset;
2. 基于抽具象canset的关联: eff计数时具象canset和抽象canset都+1;
结果
matchFo在pLearning时触发外类比抽象,那Canset什么时候触发类比抽象? 转29024
结果2
构建新Canset时,场景包含的用matchAlg,不包含的用protoAlg 转29024-步骤3&5;
28923总结,29024前说明:
29023中,构建新Canset时,场景fo不包含的帧,暂用了protoAlg;
但29023的例中可见:做和躲都是抽象的,并不具象;
那是因为它们一开始确实是具象的,只是后面又在别的流程中抽象了而已;
在29024中,重点分析Canset的这一抽象流程;
29024
那Canset什么时候触发类比抽象?
问题说明
参考上表结果,抽象Canset不执行,只是执行具象Canset,那么什么时候构建抽具象Canset的关联?
步骤
以下模拟一下HE跑起来的步骤,重现一下Canset会什么时候类比抽象;
1.
pLearning触发外类比,构建抽象matchFo: F1[想吃饭];
2.
下一次识别到具象些的F2[想吃批萨],和更抽象的F1[想吃饭];
3.
烤批萨吃后,此时F1触发器发现没更饿,生成新Canset F3[烤饭吃] (其中饭在F1含,烤不含);
4.
下二次识别到具象些的F4[想吃拌凉菜],和更抽象的F1[想吃饭];
5.
拌凉菜吃后,此时F1触发器又没更饿,又生成新Canset F5[拌饭吃] (其中饭在F1含,拌不含);
6.
将F3和F5进行类比,得到抽象Canset F6[做饭吃];
总结
其中步骤6,前段时间正好在28182-todo6写了cansetFo识别算法,改改就能用;
设想: 判断烤和拌有没有共同的抽象absAlg,有的话即二者全含;
比如: 新[1,3,5,7,9a]和旧[1,5,9b]和场景[1,5] = 是全含的,并最终返回<1:1, 2:3, 3:5>; //其中9a和9b有共同抽象
类比: 然后在识别完成后: 类比时,直接将二者做类比即可,有哪些共同点算哪些;
结果
本表彻底解决了29022-方案2的缺陷,后面可以转29025进行实践规划了 转29025;
小结: 29024通过模拟跑起来的步骤,明确了Canse识别部分,和触发类比 (但类比并未深入,只写出了有哪些共同点算哪些)
29025
Canset迁移性增强-方案2-实践前规划
说明
本轮实践分为: 场景fo外类比,Canset抽象,决策时兼容多层抽具象几大部分;
(一)
场景fo外类比部分 T:
11. 恢复外类比
现在的外类比是无效状态，可以在这次尝试打开它！T;
12. 概念类比
在Analogy中,支持概念类比,概念类比再计算每个码分别为匹配度担多少责任 T;
13. V的责任计算
如果一个码责任>50%,为主要责任,那么就把它抽象掉 T;
> 比如:三个码:1x0.8x0.7时,当前码=0.7时,它的责任比例=(1-0.7)/(1-0.8 + 1-0.7)=60% T
(二)
Canset抽象部分:
21. 用抽象生成新Canset
场景包含的: 层级跟随的用matchAlg填充 参考29023-思路1 T;
22. 用抽象生成新Canset
场景不包含的: 用protoAlg填充 参考29024-步骤3&5 T;
23. 迭代Canset识别
将Canset时序识别算法迭代下,支持下新旧Canset的全含判断 参考29024-设想 T
23a. 新Canset必须全含旧的Canset,缺一帧都不行 T;
23b. 全含判断: 新旧帧都被matchFo场景的同一帧包含,则此帧全含通过 T;
23b2. 新旧帧其中之一被场景包含,则整体全含判断失败 T;
23c. 新旧全不被matchFo包含时,应判断新旧帧有没有共同的抽象,有则此帧全含 T;
23c2. 如果没有共同抽象,继续找newCanset的下一帧,看能不能有共同抽象 T;
23c3. 直到下帧newCanset被matchFo包含时,如果还没共同抽象,则整体全含失败 T;
23d. 单帧成功时,记录到返回的全含结果indexDic中 以前就有的逻辑 T;
23e. 只要有一帧失败,则全含整体失败 以前就有的逻辑 T;
23f. 所有帧都全含成功了,则整体全含成功,并返回收集起来的indexDic 以前就有的逻辑 T;
24. 识别后新旧Canset类比
Canset时序识别算法后,支持CansetLearning(),就是外类比下 参考29024-类比 T
24a. 直接根据全含输出的新旧indexDic映射来进行时序类比 T;
24b. 支持下场景包含帧的类比: 直接Equal判断,因为它们是同一场景的同一元素 T;
25. 场景不包含帧的类比
比如:烤和拌的类比抽象,二者有共同抽象,它们的类比方式是什么? 转29026
(三)
决策时兼容多层抽具象 先不写,等写完前两个,在实测中发现问题时,再顺着问题改决策 转后面实测时做
小结: 29025做了场景fo外类比,以及优先用抽象alg生成Canset,以及Canset识别部分
但场景不包含帧的Canset类比未写,转下面两张继续深入分析一下 在n29p03完成了 T;
决策也没写,转实测时边测边明确了需求时再跟着写 转n29p04边测边搞;
29026
场景不包含Canset帧的类比-初步方案分析 A
方案1
将AB帧的相似点抽象出来 5%
分析: 它的起因是有共同抽象,这个类比结果要随时加入别的新Canset相应帧;
那么: 那么再有新Canset对应帧不断加入时,判断相似度的参考标准就一直在变;
而这个抽象帧,需要应对这一切的变化,都能挂给它当具象,还都得相似?除非直接用空抽象,转方案2;
方案2
直接用空概念当类比抽象结果 95%;
分析: 这个空概念的意义解释依赖它指向的具象,所以它不能全局去重,不然挂几万个各种具象就跪了;
结果
选定方案2 但空概念的防重等细节还需要继续分析,转29027;
改
20231017-反转方案,它的起因是共同抽象,但它的类比却未必要延用共同抽象,制定方案3如下;
方案3: 改为使用类似普通节点的类比算法,重新进行alg类比的路子,而不必理会它俩有多少共同抽象 转30148-todo1
29027
场景不包含Canset帧类比出空方案-细节方案分析 B
问题
要避免这个空概念过度复用,导致下面挂几万个各种具象;
方案1
越来越并集方案;
说明: 根据matchFo.pId和matchFo.index来防重,这样就完美的指向了这个场景下的这一帧;
代码: 直接用场景PID当dataSource,然后用index当algsType,即可;
缺陷: 因为有共同抽象的传递问题 (有时共同抽象是打,有时是推,有时是摸),这种迟早变成并集;
所以: 最好是让生成的空抽象,不要超过目前的共同抽象集,它只能越来越交集,而不是越来越并集;
方案2
直接最交集方案: 如果共同抽象有4条,那么就分别构建4条;
分析: 这种是另一个极端: 属于一步达到最交集状态了;
缺陷: 如果3a有4条共同抽象,9a有5种,难道要一次构建20条抽象Canset?
所以: 这种一次性最交集方式不现实,各种细分许多条,交叉在一块,乱成一锅;
方案3
越来越交集方案;
分析: 此方案一开始生成一个指向多条共同抽象的空概念,后面随着此步骤再触发,变的越来越交集,指向的共同抽象越来越少;
细节: 1.抽象指向4条共同抽象 2.ds用共同抽象的pidArr 3.不用at=matchFo.index了(因为这方案能支持全局防重了)
说明: 允许它全局防重 (空概念的抽象指向明确了它的含义,用在哪个场景下含义都不变,而各场景不同归场景管,不归它管);
示图:
越来越交集步骤说明: 1.3a3b生成如上图空概念 2.下次此空概念可能做为另一个3a即可越来越交集;
优点: 前期空概念的cansetFo会将SP和EFF传递给越来越抽象的后期空概念cansetFo;
结果
选定方案3,代码实践转n29p03;
小结: 29026-29027分析了场景不包含帧的Canset类比方案,最终结果参考29027方案3
总结:
本节迭代支持了场景外类比(Canset迁移性增强);
新Canset改优先为用抽象alg来生成;
迭代了CansetFo识别算法 (及全含判断方式);
写了Canset类比器 (其中matchFo未包含帧的类比未完成);
分析了matchFo不包含帧的类比方案 参考29027-方案3;
n29p03 Canset迁移性增强2: 空概念类比、absCanset的初始SP和EFF CreateTime 2023.03.25
本节顺着上节末尾的matchFo不包含帧的类比继续进行代码实践;
29031
场景不包含Canset帧类比-29027方案3-代码实践规划
todo1
直接构建空概念当抽象 T;
todo1.1
空概念用ds防重 (ds=共同抽象的pointerIds组成字符串) T;
todo2
新空概念的具象指向3a,3b T;
todo3
新空概念的抽象指向共同抽象集 T;
29032
构建absCansetFo后,需要继承SP和EFF-方案规划与实践TODOLIST
说明
上表做了不包含帧的类比,类比写完了,本表要针对类比后构建抽象需要改什么 (主要需要加上继承SP和EFF);
分析
关于继承哪些SP和EFF,以下分析:
1
如果absCanset是复用的,非新建:
a. 如果旧Canset本来就指向它了,则将抽象cansetFo的SP和EFF+1就行吧?
b. 如果旧Canset是新指向它的 (那么就把旧cansetFo的SP和EFF都累计给absCanset);
2
如果absCanset本来没有,新建的:
a. 此时直接将旧Canset的Sp和EFF累计给absCanset;
方案
根据以上分析可得,只要absFo和conFo之间是新关联,即继承它的sp和eff (两个conFo都这样处理);
实践
实践规划: 在absCanset的构建方法里,支持下继承SP和EFF;
todo1
将两处调用createAbsFo_NoRepeat的地方,都收集起来conFos和absFo的indexDic,然后传到构建absFo方法中 T;
todo1.1
新旧Canset映射为<1:3,2:5,4:7>时,newIndexDic=<1:3,2:5,3:7>,oldIndexDic=<1:1,2:2,3:4> T;
示例: canset类比计算indexDic的示例: 其中canset类比抽象时,比如newCanset和oldCanset映射为<1:3,2:5,4:7>;
todo1.2
analogyOutside外类比时,也要支持生成protoIndexDic和assIndexDic两个映射字典 T;
todo2
构建抽象absFo后,要根据具象Fo更新下absFo的sp和eff (分为继承assFo的和后续+1两种更新如下:) T;
todo2.1
根据分析1&2,判断absFo和assFo之间是否新关联 T;
todo2.2
assFo和absFo未关联,则先继承assFo的sp和EFF T;
todo2.3
protoCansetFo给absFo带来SP和EFF的+1 (因为protoCansetFo刚发生一次) T;
todo2.4
Canset外类比需要更新EFF,但普通外类比不需要更新EFF T;
todo3
将conFo的indexDic映射也存到新absFo上 T;
总结: 本节完成了Canset迁移性增强的:
29027-方案3: matchFo不包含帧的类比;
构建absCansetFo后,继承与更新它的SP和EFF;
n29p04 Canset迁移性增强3: 初步回测 CreateTime 2023.03.28
接29025-(三),本文边回测前两节带来的迁移性改进,边看需要改决策哪些部分;
29041
回测规划
简介
通过防撞训练前两步,逐步测试以下各项;
测试项1
场景Fo外类比,可抽象出Canset迁移性增强的结果 T;
测试项2
测试新Canset,优先采用场景alg T;
测试项3
测有新Canset时,进行Canset识别;
测试项4
测试Canset识别中的全含判断算法;
测试项5
测试Canset类比,能构建空概念,并构建抽象Canset;
测试项6
测试抽象Canset继承和更新SP和EFF代码;
测试项7
测下因为迁移性的增强,带来的决策中的问题;
29042
性能差: Canset识别结果太多,都在调用类比导致性能差问题
方案
Canset识别支持AIFilter过滤器即可,排名机制按SP为主&EFF为辅 T;
29043
增强Canset迁移性后-决策改动部分之: 空概念无法执行问题
问题
空概念是没法执行的,那么怎么执行,含有空概念的解决方案?
方案1
决策时,空概念Canset没法执行,向具象再下探 95%;
深入: 则TCSolution要分两步,第1步找出思路absFo,第2步找出conFo具体可执行的推进;
方案2
直接执行空概念所在的Canset,只是actionIndex那一帧下探一下 5%;
否决: 因为执行fo不允许跳出fo,比如conFo中有比absFo多出的帧;
比如: absFo是[饭,做],conFo是[洗,土豆,炒],如果单纯改成[土豆,做]则可能不干净;
结果
本表仅制定了大致的方案,其实就是向下向性找到可执行的conCanset 转n29p05继续;
29044
BUG: PINDiskCache报错
BUG1
ERROR: The item couldn’t be saved because the file name “com.pinterest.PINDiskCache.” is invalid
BUG2
[[PINDiskCache alloc] initWithName:@"" rootPath:saveRootPath],报NSInvalidArgumentException错误
复现
训练到防撞第2步很容易复现 (可以将构建空概念时的ds>100时打断点);
线索
经查,应该是rootPath长度太长导致报错,经查rootPath有长度超过100都不止的情况 名称为A1A1A1...;
分析
调试
说明
如上,当空概念生成图中的流程,在第1次发生还一切正常;
第2次A情况,A5A6有共同抽象A1,导致又生成了A1A1,并抽象指向A1 (以此循环无穷尽也);
第2次B情况,A1A5有共同抽象A7,导致又生成了A1A1,并抽象指向A7 (以此循环无穷尽也);
结果: 总之要避免这种重复构建空概念的情况 (即防重下已有了一样作用的,下次执行又构建了);
思路
分析下,如何避免以上两种情况的防重和死循环问题 (且不能影响持续构建越来越交集的空概念);
方案1
根据A情况,A5A6已有共同抽象空概念A1时,不再重复构建直接复用;
方案2
根据B情况,有一个本身就是空概念(A1)时,A1也是(A5和A1)的共同的空概念抽象,也要支持复用;
实践
方案1和2都要实现,但代码上可以用一套代码支持这两种情况,如下todo;
todo1
构建空概念时,将二者的抽象收集起来取交集,交集中有空概念的话,直接复用返回 T;
todo2
构建空概念时,判断其中一个conFo本身是空概念,且是另一个conFo的抽象时,直接复用返回 T;
todo3
防重不能用原来的从抽象中找ds来判断防重,因为抽象会有新增,ds就变了,但二者有共同空概念抽象 已废弃删除;
todo4
其实用pidArr拼接ds已经名存实亡了,可考虑删掉它 先不删,等过段时间没用再删;
总结
本表重点改动了空概念的防重机制为(场景内共同抽象的空概念仅保留一条,原来的ds防重因无效废弃);
本节在最近Canset迁移性增强大的改动后,本节初步回测: 29041本来是计划一条条测试的,但后来发现许多后期的模块是难以直白的测试的,只能边跑边发现问题,无法一蹴而就的测出有什么BUG (所以转n29p05边跑跑看决策需要改什么,边测试那些有改动的模块有什么BUG吧);
并且本节还大致分析了决策所需的改动 (参考29043),并制定了29043-方案1,决策时的下向性,TCSolution要向下找到可执行的conCanset来推进 转n29p05继续;
29044中将影响闪退等明显的BUG修了,现在大致跑顺了:就是防撞前两步训练较为顺利不闪退等明显BUG了;
n29p05 Canset迁移性增强4: 在Canset抽具象基础上分析决策所需的改动 CreateTime 2023.04.02
上节初步测了下没明显的闪退等大BUG了,本节继续进行应对Canset迁移性增强后: 决策所需的改动;
29051
上节成果回顾,制定本节计划
上节回顾
上节29043-方案1中,初步思考了决策的下向性,向下找到可执行的conCanset来行为化的大方向;
本节计划
先尝试找出决策哪里需要改,怎么改: 首先我们尝试用高度有序的方式来制定手动训练步骤,并从中观察线索 转下节;
29052
制定手动训练步骤,并从中观察线索 参考29051-计划
分析
在第1步识别ok后,第2步手动躲避成功几次,并尝试观察日志中,它的迁移性是否有增强;
结果
需要通过原则->模型->方案->实践进行分析,从而结合实测来共同推进 先29053规划下,到29054再继续本表;
29053
Canset迁移性增强增强迁移性后->决策: 分析哪里需要改,怎么改
示图
注解
1. F3场景过具象迁移性差,大几率是无解的: 必须在更抽象上找到迁移性强的解决方案才ok;
说明
决策向性下,是找到稳定且可行的Canset的过程: 跑起来步骤分析如下:
步骤1. F1一般可被matchPFos识别到;
步骤2. 用F1的具象来取F2,并做匹配度竞争 (因为F2不一定被识别到);
步骤3. 用S2的具象来取S3,因为S2的躲是空概念不可行,只有上飞才是真实可行的行为输出;
实践1实践
步骤1不用实践,现在代码本就如此 本就如此 T;
步骤2实践
找F2共有两大作用: 1.回忆以前被撞经历,它确实危险! 2.找出稳定的场景; 废弃 T
反方1: 第1条,不用取F2(F2是否被识别到不重要),因为只要有F1,则F2必然存在,不激活它也确定危险过;
>>> 证据: 只要抽象sceneFo有一定几率危险,那么具象sceneFo必然危险就一定存在;
反方2: 第2条,在matchPFos中也可以pk出最稳定的那条,不一定非要到sceneFo抽具象路径上找稳定的;
>>> 证据: 只要是稳定的sceneFo就必然不会过度抽象;
结果: 根据以上两点否定,第2条不用做了,即使不找F2,也不妨碍我们根据matchPFos找出最佳解决方案canset 废弃 T,
步骤3实践
本表看来只需要实践步骤3,此处对步骤3继续细分分析:
原则: 根本上其实就是:从稳定不可行到稳定且可行的过程;
说明1: 稳定不可行是指含空概念的absCanset;
>>> a. 稳定是因为它抽象迁移收集了更多SPEFF,它稳定,即它的具象也稳定;
>>> b. 不可行是因为它含空概念,所以不稳定;
说明2: 稳定且可行是指被稳定absCanset具象指向,且不含空概念的conCanset;
>>> a. 稳定是因为它被稳定的absCanset具象指向;
>>> c. 可行是因为它不含空概念;
分析: 当前的TCSolution算法本就支持含稳定性的综合竞争,所以这部分代码可不改继续用;
结果: 本步骤最终指向的就一点: 从稳定不可行到稳定且可行的过程;
结果
根据以上分析: 只需要对步骤3进行实践规划 转29057;
小结: 29053中,大致制定了决策要改啥-的方案规划
29054
Canset迁移性增强增强迁移性后->决策: 实践前验证
简介
在防撞第1步基础上,各位置手动躲开几次;
1
看能抽象出场景和canset 在29055末尾测试通过 T;
2
看能激活抽象canset并尝试求解 T;
3
看调试下matchPFos的具象上,验证是否有更稳定的解 参考29053-步骤2实践-结果 此条不做了,也不必再测;
4
看调试下更稳定的解是含空概念的absCanset,它的具象上,又有更可行的解 边实践边测吧,转29057;
29055
根据29054简介 & 1跑,测得Canset识别全是单帧结果的问题;
BUG
Canset识别几乎全是单帧结果,像[棒,飞,棒,飞]这样的结果很少;
调试
经调试,其实conCansets中是有多帧S的,只是在过滤后,多帧的全被过滤掉了;
方案
将Canset过滤器改为:indexDic映射数;
原则
识别是以匹配度为主 ,而Canset匹配度就是: indexDic映射数;
改动
将EFF有效率和SP稳定性都废弃了,因为有效率低也可以在这里完成原始积累,优胜劣汰,不能让阶级固化 T;
修复
执行方案,改过滤器后回测ok,不再全是些单帧结果了 T;
回测
防撞训练第1步,路偏上随机位置,直投,手动上飞躲开;
1. 训练至第3次时,日志有构建absCanset:F1371[A385(高100,皮0,向358),A1326(飞↑),A1369(),A1326(飞↑),A1370()],可见已正常抽象出ok的Canset;
2. 训练至第5次时,可以自行飞躲开,再来第6次照样通过,可见迁移性善可,测试通过;
结果
本表训练结果存为FZ78,其推进到29054-1测试通过,下表继续做实践前验证的工作;
29056
根据29054简介 & 1跑,测得求解最终激活Canset抽象但不够的问题;
说明
参考代码段29056-1,激活的Canset虽然抽象,但并没有包含空概念;
修复
经查是absCanset构建后没挂到sceneFo下导致的,挂上后问题解决,回测FZ78也ok T;
//代码段29056-1
0 : F1345 [A385 (高100 ,皮0 ,向358 ),A1326 (飞 ↑),A1329 (高100 ,皮0 ,向338 ,距54 ),A1326 (飞 ↑),A1334 (高100 ,皮0 ,距31 ,向289 )] (前0 .99 中0 .60 后1 .00 ) fromPFo :F386 eff :F1345 :H6N0 sp :{0 = S0P3 ;3 = S0P3 ;2 = S2P3 ;1 = S0P5 ;4 = S0P3 ;}
1 : F1368 [A385 (高100 ,皮0 ,向358 ),A1326 (飞 ↑),A1352 (高100 ,皮0 ,向344 ,距71 ),A1326 (飞 ↑),A1357 (高100 ,皮0 ,距37 ,向309 )] (前0 .99 中1 .00 后1 .00 ) fromPFo :F386 eff :F1368 :H3N0 sp :{0 = S0P2 ;3 = S0P2 ;2 = S0P2 ;1 = S0P2 ;4 = S0P2 ;}
2 : F1346 [A958 (高100 ,皮0 ,向5 ),A1326 (飞 ↑),A1329 (高100 ,皮0 ,向338 ,距54 ),A1326 (飞 ↑),A1334 (高100 ,皮0 ,距31 ,向289 )] (前0 .96 中0 .60 后1 .00 ) fromPFo :F959 eff :F1346 :H6N0 sp :{0 = S0P3 ;3 = S0P3 ;2 = S2P3 ;1 = S0P5 ;4 = S0P3 ;}
3 : F1372 [A958 (高100 ,皮0 ,向5 ),A1326 (飞 ↑),A1352 (高100 ,皮0 ,向344 ,距71 ),A1326 (飞 ↑),A1357 (高100 ,皮0 ,距37 ,向309 )] (前0 .96 中1 .00 后1 .00 ) fromPFo :F959 eff :F1372 :H3N0 sp :{0 = S0P2 ;3 = S0P2 ;2 = S0P2 ;1 = S0P2 ;4 = S0P2 ;}
29057
Canset迁移性增强增强迁移性后->决策: 实践方案 参考29053-结果
简介
在29053-步骤3中,确定了只需要改:从稳定不可行到稳定可行,本表继续分析它的可行实践方案;
方案1
判断最终输出的S是否包含空概念,包含时向下再找具象Canset即可 有关键缺点,转方案2;
缺点1: 取得conCansets后,它们如何竞争 (因为结果只要一条最佳的)?
缺点2解决: 能不能把此处的竞争方式和前面的solution.ranking结合起来?比如继承absCanset的竞争值;
缺点2: 此方案的conCansets中,有没有非canset混进来? (在fo构建防重时,可能混入别的);
缺点2解决: 判断下absCanset所在的sceneFo所有cansets与它做交集即可;
缺点3: 空概念与protoFo的匹配度为0,对它的前段Ranking竞争不利;
缺点3解决: 方案2无此问题,因为方案2的空概念canset只提供竞争值,匹配度还是以前做法不变,不受影响;
结果: 缺点2可解,但缺点1和3的解决方式,其实指向了先继承absCanset的竞争值 (即方案2);
小结
即抽具象canset二者有机结合(抽象的竞争值+具象的匹配度),再进行Ranking竞争,才会比较公平;
方案2
在Solution竞争机制中支持将absCanset的SP,Strong,EFF等值继承给conCanset用 95%;
步骤1: 将不可行抽象方案的SPStrongEFF继承给它的具象方案;
步骤2: 在Ranking前将不可行方案过滤掉,它不参与到真实的竞争中;
细节问题1: conCanset有多个不可行抽象指向时,继承哪一个?
细节问题2: SPStrongEFF按什么比例继承给具象canset?
示例: 现在要你做一道你不太擅长的菜:
1. 如果你本来就是个很好的厨师(absCanset)，你会比较有信心能做好(conCanset)。
2. 如果你本来做饭就常失败(absCanset)，你没啥信心能做好(conCanset)。
>>> absCanset的竞争值(好或坏),都会继承给conCanset (儿承父产 & 父债子还 );
3. 如果你做饭常失败(absCanset1),但做这道菜的刀功你玩的很6(absCanset2),那你信心提振了一些(conCanset);
>>> 多条absCanset的竞争值都继承给conCanset (一个儿有多个爹,遗产继承多次 );
4. 如果你做饭常失败(absCanset),但这道菜你虽不擅长却做过几次且成功率80%(conCanset),那你有信心能做好(conCanset);
>>> 具象成功率,影响了它继承的成败比例 (一个不孝子继承的家产少些甚至无 );
那么：根据此例分析从absCanset继承继承到conCanset,怎样计算会好些;
结果
方案2完美解决了方案1的缺点,所以优选方案2 实践转29058;
//代码段-29057-方案1 (最终未采用)
AIFoNodeBase * itemCanset = [ SMGUtils searchNode :item . cansetFo ] ;
if ( [ SMGUtils filterSingleFromArr :itemCanset . contentPorts checkValid :^ BOOL ( AIPort * item ) {
return [ item . header isEqualToString :[ NSString md5 :@"" ] ] ;
} ] ) {
NSArray * conCansets = [ AINetUtils conPorts_All :itemCanset ] ;
}
29058
Canset迁移性增强增强迁移性后->决策: 代码TODOLIST
1
为方便今后灵活改动,将absCanset的各值取出后,封装成模型,然后做为参数传到继承算法中;
2
SP按conCanset的SP比例来继承 (即子SP*父SP);
3
EFF按conCanset的EFF比例来继承 (即子EFF*父EFF);
4
Strong按对应帧来继承;
5
多个父(absCanset)时,多次继承;
29059
Canset迁移性增强后网络结构图分析 因这张图,本节全部中止作废 T
示图
★重点
此图中体现出的迁移性,是因为sceneFo的Canset迁移性增强带来的;
★问题
而本节上面分析的迁移性,是canset自身的类比抽象带来的 (空概念absCanset);
★改动
显然,二者功能重复了,说白了,就是上面做的canset识别类比都没啥用,应该废弃掉 先关掉;
总结: 本节站在Canset抽具象的基础上改决策系统,但突然发现Canset识别类比与Canset迁移性增强功能重复,需要废弃,所以本节的实践中止,转29061在场景共同点抽具象的基础上进行决策改动
n29p06 Canset迁移性增强5: 在场景共同点抽具象基础上分析决策所需的改动 CreateTime 2023.04.07
上节因29059问题中断,转本节在场景共同点抽具象的基础上进行决策改动,其实并不是中断,只是最近的canset迁移性,增加了决策中的抽具象结构,它的改动很大,影响很广,所以本节继续深入分析细节,做以下三件工作:
"canset抽具象还是要依附场景抽具象"来切入思考;
然后将以往没分析透彻的通过画图等手段分析透彻;
分析完后,付诸代码实践;
交层 : 更抽象层为: Canset迁移性增强后缺了某些元素的层 (即缺一些元素的抽象节点),统称为: 集合交集层 (简称: 交层);似层 : 内部概念全是相似度没缺元素的: (即通过相近度匹配到的概念间的抽具象关系),统称为: 强化相似层 (简称: 似层);Brother,Father,I : 在Canset迁移时,主要执行I任务,而I可以从Father继承方案,也可以由Brother通过Father迁移来方案;迁移关联 : Brother与Father,或I与Father之间的Canset推举之后,二者间构建一个关联,称为transfer关联 说白了,就是你的技能是跟哪个老师学的,以后自己赚了钱反馈恩师时要用到这个记录;推举 : 迁移分为拿和放,其中拿是从brother->father,称为推举;继承 : 迁移分为拿和放,其中放是从father->i,称为继承;
Canset的抽具象限定在场景下 (相当于场景下,有一颗小canset树);
29061
通过整理最近改动的场景共同点抽具象网络结构图,来分析决策怎么改
示图
分析
关于示图中protoFo1和protoFo2可迁移,但protoFo3不可迁移,各举一例如下:
情况1
如图: 下次发生protoFo2时,也会识别到scene4;
> 此时可激活canset2,它因为抽象统计更多SPEFF,可体现出迁移性;
情况2
如图: 下次发生protoFo3时,也会识别到scene4;
> 但不应该激活canset2,因为protoFo3太近,canset2并不管用,应该激活canset5才对;
补充
即使识别不到scene4,也可以主动从absPorts取到scene4;
总结1
情况1时canset3可继承canset2的竞争值,而情况2时canset4只能继承canset5而不是canset2;
总结2
即: 使用时,要主动顺着抽象场景,找自己能继承的absCanset 转29062-决策;
29062
步骤分析: 让上图动态跑起来,分析变化步骤
示例
比如第1次protoFo是炒鸡蛋,第2次是煸豆角,二者能抽象到做饭吗?
问题
其中"鸡蛋和豆角"到了抽象sceneFo中都成了"饭",而"炒和煸"到了抽象sceneFo中都成了"做";
说明
以下通过认知和决策两个部分的步骤分析,整理一下整个提升Canset迁移性的过程;
认知
生成新canset时,可向着它的抽象sceneFo推举它;
1. 推举后,还是要生成抽象sceneFo上的absCansetFo (它依然有Canset识别和类比);
2. 只是由以前的从sceneFo.conCansets中识别,改为从absSceneFo.conCansets中识别了 (全含算法要跟着变下);
结果: 即canset自己爬升,改成顺着sceneFo爬升了;
决策
TCSolution求解时,可以用识别到的matchPFos结果,向它的抽象sceneFo继承absCanset的竞争值 参考29061-总结2
1. 先找着absSceneFo,然后再取它的conCansets;
2. 然后判断它与当前canset有抽具象关联时,即继承它的竞争值;
结果: 即原本的canset直接取absCanset改成顺着sceneFo找absCanset了;
总结
看来本节并不是推翻Canset识别类比,而是让Canset识别类比改到在absSceneFo上进行;
29063
Canset识别类比改到absSceneFo上进行TODOLIST
todo1
新Canset时,同时为每条absSceneFo各生成一个newCanset4AbsScene,并挂到它下面 废弃,转29067-todo2;
todo2
每条newCanset4AbsScene都要触发Canset识别类比 废弃,转29067-todo1;
29064
决策改动再分析
图
观点1
不需要继承Canset的SPEFFStrong,因为各是各的,继承后只会让率越乘更低;
★SPEFF各管各原则: 无论是从抽或具象场景取了canset,它们的SPEFF是分别存各的,竞争时也各用各的;
观点2
具象sceneFo上找scene优先,如果找不着,可以到抽象上找;
比如: 有protoFo4[向5距66场景]从未有过Canset,它可以到sceneFo4上找着canset2尝试解决;
但是: 像protoF3本来就有canset4,那么他就只能优先继承canset5,其次才是canset2;
另外: 如果protoF3尝试过canset2,但是躲失败了,也应该为protoF3记录canset2,并记失败一次;
★override. 如果一个canset在抽具象场景全有,则优先从具象取用 (类似编程中的@override);
★方法继承. 如果一个canset在抽象场景有,而具象无,则从抽象取用 (即编程中的方法继承);
观点3
★概念识别仅识别似层结果 (这么做,时序识别时因为索引全是似层,所以时序识别结果也全是似层的);
>>> 好处1. 在决策时,抽具象层级更明确,matchPFos就是具象一级,它的抽象就是抽象一级;
>>> 好处2. 这样的话,Canset迁移性增强的抽具象层级就两层,那么抽具象无论是override还是继承功能,都容易达成;
>>> 结果. 此条影响太广,不过两条好处也很吸引人,所以得做 95%;
观点4
明确说明: 在观点3的基础上: matchPFos就是具象一级:
★从抽具两层取候选. matchPFos是具象,加上他的抽象一层,这两层,收集所有的cansets做候选集 (达成迁移);
观点5
无论是抽具象哪上面取得的canset,最后统计SPEFF时,抽具象上全要统计一份;
★抽具两层分别统计SPEFF. 具象canset向所有抽象扩展统计,抽象canset向取他的具象扩展统计;
综合
以上分析比较散,但整体上带★的6条是比较明确的结论,分别如下:
1.识别时pFos与protoF同长 2.取抽具两层候选集 3.具象无则方法继承 4.具象有则override 5.抽具分别统计SPEFF 6.抽具各用各的SPEFF
结果
这6条结论,分别涵盖了决策中涉及到本次改动的全部: 从场景两层要求,到候选集源,抽具优先级,SPEFF写用;
todo1
概念识别改为仅识别似层 T;
todo1.1
TCFeedback兼容仅识别似层 (原来的contains不行了,因为全是似层,waitA却可能是交层);
todo1.2
TCForecast和TCDemand兼容仅识别似层 (因为结果全是似层,看是否需要向abs取下交层,以找到mv指向);
todo2
TCSolution取抽具两层候选集 转29069-todo3 T;
todo3
方法继承: 具象层不包含的canset,则使用抽象层的 转29069-todo3 T;
todo4
override: 具象层包含的canset,则使用具象层的 转29069-todo3 T;
todo4.1
似层和交层的cansets分别都取出 转29069-todo3 T;
todo4.2
因为似层优先: 所以过滤掉交层中的似层 (交层=交层-似层) 转29069-todo5 T;
todo4.3
剩下的交层和似层,共同参与Solution竞争,直至输出最佳S结果;
todo5
抽具象两层分别统计SPEFF (两层都构建canset);
todo6
TCSolution竞争时,抽具象各用各的SPEFF值;
结果
本节未写的todo部分,在29069全改进并且写了 转29069;
29065
两层scene三层canset示图分析
示图
说明
如图,感觉三层canset有点复杂,分析下能不能简化?
尝试1
空概念canset这一层是否可删除?
前提: 我们的目标是必须能够抽象出canset (以达到迁移的目的),而canset中有场景包含帧,也有场景不含帧;
回答: 场景包含帧依附场景即能够抽象,但不包含帧需要另外类比才能抽象 所以空概念canset这一层不可删除;
结果
因为决策期的下向性,其实仅体现在这两层场景和三层方案,再简化怕啥也没了...所以先这么着吧 放弃简化;
29066
两层scene两层canset示图分析
尝试2
空概念canset这一层再尝试删除 (即使场景不含帧类比,它也未必就是空抽象...)
示图
说明
如上图,将空概念层简化掉了,在整个步骤中,抽象出交层canset,但却不需要生成空概念;
重点: 其中C3和C4的第三帧有共同抽象,但并没有生成空概念,而是对二者进行类比得出了向7无距,再举一例如下:
第1次,[向5距55,上飞,向7距77],在似层构建一个S,交层再构建一个[向5,上飞,向7距77]
第2次,[向5距66,上飞,向7距88],在似层构建一个S,交层再构建一个[向5,上飞,向7距88]
第3步,因为两个第三帧有共同抽象,所以两个canset类比抽象得到[向5,上飞,向7];
结果
本表简化成功 (废除了空概念canset和推举canset),可以相应应用到Canset类比算法中,实践如下;
todo1
推举不能太频繁,采用懒推举 转29067-todo2 T;
todo2
每次构建新Canset时,同时做似层和交层两次canset识别类比 废弃,转29067-todo1&3.3;
todo3
似层: 仅从似层cansets做识别类比,并将结果absCanset挂在似层下 转29067-todo1;
todo4
交层: 取所有它下面的似层(除发起的似层外)cansets做识别类比,并将结果abs挂在交层下 废弃,转29067-todo3.3
29067
性能考虑-懒操作
问题
如果29066-todo2每次都对交层进行识别类比,如果有多个抽象呢?难道都要分别识别类比?性能怎么办?
解答
全采用懒操作,这些找各交层做识别类比的操作,全废弃掉 (即不多做任何事,总是到不得不时再做操作);
todo1
懒识别: 无论是似层还是交层,什么时候有输入或推举一条canset时,就在它的conCansets中进行识别类比;
todo1.1
识别场景包含帧用mIsC来判断(newCansetA抽象指向oldCansetA) T;
todo1.2
场景不包含帧,则判断二者是否有共同抽象 T;
todo1.3
场景不包含帧,有共同抽象时,直接用analogyAlg类比newCansetA和oldCansetA得出抽象A 弃,转29069;
todo2
懒推举: 似层无解,有同级别的似层迁移来canset时,最终输出最佳S前,将其推举到交层,并转换为交层canset 转29069-todo10.1;
todo3
懒统计: 交层的canset执行,根据eff是否有效,转向如下: 转29069-todo11;
todo3.1
无效时: 交层的canset执行完并EFF无效时,在交层和似层分别计eff-1 转29069-todo11;
todo3.2
有效时: 交层的canset执行完并EFF有效时,在交层和似层分别生成新canset 转29069-todo11;
todo3.3
有效时: 交层和似层生成新Canset后,分别各自调用自己的识别类比 转29069-todo10.1&11&12;
todo4
懒统计: 为解决似层任务,无论canset是否有效,也无论canset源自哪,都要为canset在似层统计EFF值 转29069-todo11;
29068
两层scene两层canset不变的情况下: 允许canset出现空概念
说明
在29067-todo1.3实际写alg外类比时,发现几个问题如下:
问题1
有共同抽象的两个cansetAlg要怎么类比,按交集还是匹配度? (注:二者平级无法复用匹配度);
问题2
有多个共同抽象时,此处仅类比出一条,别的可能永远类比不出,即: 场景类比成果未应用到Canset上;
问题示例
比如炸和炒抽象出用油制作,那么下次如果是蒸呢?再抽象一次吗?
分析
这些问题空概念可解,空概念即延用了场景类比的成果,又可扩展性强;
方案
在absCanset中空概念常态化,当成普通概念用,只是指向多个抽象;
重点
启用空概念,但仅改为可在absCanset中出现 (两层scene两层canset别的部分不变)
示图
todo1
场景不包含帧,有共同抽象时,直接用构建空概念 代码本就如此 T;
todo2
TCSolution求解时,如果最佳S有空概念,则再向具象取一层,取出无空概念的canset做为最终输出;
todo3
空概念取它的具象cansets竞争机制,可尝试用EFF竞争;
29069
从:自己,父类,兄弟三级场景取cansets 参考29064-todo2
取步骤
优先级
分别从三者取cansets,优先级: 自己 > 父类 > 兄弟
数据结构
todo1
先写数据模型(AISceneModel) + type(自己,父类,兄弟枚举) T;
todo2
目前仅支持R任务,等到做去皮训练时有需要再支持H任务 暂不做;
todo2.1
支持H任务时,需要根据targetIndex在取(三步的)步骤中,依次判断含目标帧的indexDic映射 暂不做;
todo3
写getCansetFos_SlowV3()支持三级收集候选集 T;
todo4
在getCansetFos_SlowV3()取父类和兄弟时,需要有同类mv指向,否则取到解决别的任务的,白得 T;
todo5
override实现: 每条canseModel的cansets都需根据优先级高一级的防重 T;
注: 优先级高两层不用管,比如:brother不用i来防重,因为二者有交互必然会在father留下痕迹,所以单用father一级防重即可;
公式: validCasets = protoCansets - base.cansets (注: 此公式需要用抽具象相关来判断相减 转todo5.1);
todo5.1
推举后canset和原canset是同一个,且canset类比抽象有抽具象关联,所以用mIsC即可实现此公式 T;
todo5.2
无论是哪种情况,mIsC判断时,都以father为抽象来判断mIsC (因为father本来就是二者的抽象方向) T;
todo5.3
公式使用1: brother有效canset = brother.conCansets - father.conCansets T;
todo5.4
公式使用2: father有效canset = father.conCansets - i.conCansets T;
todo5.5
公式使用3: i有效canset = i.conCansets T;
todo5.6
需要将cutIndex传递到自己,父类,兄弟三者中,因为判断前中后段要用 T;
todo5.6
AISceneModel中cutIndex映射不上的,过滤掉,因为截点找不着,它就未必有什么能迁移成功的解 T;
todo6
鉴于性能考虑,自己,父类,兄弟三者的任一个不能全激活,写每个内部的竞争机制;
> 先不写,随后测得性能问题后再写 暂不写
todo7
最佳CansetModel激活后,它的SceneModel也存到最终生成的TOFoModel中 T;
todo8
输出最佳CansetModel前检查可行性(含空概念即不可行),不可行时延着它的具象,换一个最佳CansetModel输出 T
> 它的具象应在同一个最佳CansetModel的候选集sortModels中取;
todo9
根据CansetModel不同执行不同的feedback反馈: 也写成TOFoModel下的方法来写不同实现 转如下实践 T;
> 实践: 直接在TOFoModel中重写getContent_p()方法,优先返回iCanset,为空时返content_p,这样feedback就不用改 T;
todo10
根据CansetModel不同执行不同的迁移(推举或继承)操作: 也封装成一个方法写不同实现 T;
todo10.1
懒迁移: 最终输出最佳S后,源于Brother则迁移到Father和I,源于Father则迁移到I T;
todo10.1b
无论canset从哪迁移来的,最后执行行为化的都是iCanset (不兼容的H任务等还是执行content_p) T;
上图步骤说明: 1.遍历迁移前canset 2.判断迁移前Canset->迁移前Scene->迁移后Scene的映射 3.映射通过则采纳迁移后Scene的元素 4.映射不通过则采纳迁移前Canset的元素 5.最终拼凑出新的迁移后Canset
todo10.2
迁移后,将迁移前后的canset构建迁移关联(参考文首名词解释) (以便同时更新它们的SPEFF或避免重复迁移) T;
上图说明: 1. 推举后,Father和Brother构建迁移关联,2. 交层EFF更新时,Father的EFF也更新,且它的抽象也更新
todo11
根据CansetModel不同执行不同的SPEFF统计: 也封装成一个方法实现不同统计 T;
todo11.1
无论SPEFF结果是正是负,都进行统计更新 T;
todo11.2
每次执行后,分别对I,Father两级进行统计更新 T;
todo11.3
每次执行后,分别对I,Father两级各自的抽象cansetFo也要更新 转todo11.4 T;
todo11.4
SP在InRethink和OutRethink时,都对其抽象也更新SP T;
todo11.5
EFF在R和H任务时,都对其抽象也更新EFF T;
todo12
识别类比: 在TCTransfer迁移完成时,调用canset识别类比 T;
todo12.1
canset类比抽象时,不对SPEFF+1,因为迁移完成不表示已正向发生 T;
本节对Canset迁移性增强后的决策部分进行了改动实践,含以下改动:TCScene场景树、TCCanset.override算法、TCRealact可行性、TCTransfer推举算法,继承算法,迁移关联、相应更新SPEFF,下节回归测试;
n29p07 Canset迁移性增强6: 整体回测 CreateTime 2023.04.20
在n29p02-n29p06间,改了许多,在n29p04初步回测了下,现在整体写完,再回归测试;
29071
回测规划
手训
防撞训练第1步基础上,进行偏上手动躲开xN次;
分析
从中观察习得canset,以及canset的迁移性;
测项1
测下手训第3次左右,TCScene能不能取到SceneTree;
29072
TCScene的BUG: 因为有多条共同抽象的可能性,所以father和brother中的元素是有可能重复的;
分析
比如: i1和i2有共同的抽象father1,那么就会生成两次father1的SceneModel;
方案1
如果要加防重的话,构建[AISceneModel newWithBase]时就给防重了;
缺点: 但这样会导致SceneModel重复生成时,会有多个base,这样TCScece就无法生成树形结果了;
方案2
到后面TCSolution竞争时再加去重功能;
问题: 那到TCTransfer时,canset迁移哪个base?还是多个base去重后,canset迁移到多个base下?
结果
暂停: 先不解决,先不解决看有影响时再来加防重功能 待测出问题再来解决;
29073
从120多条SceneModel转成CansetModel只有0条的问题 T
调试
在override算法有返回,但到convert2CansetModel后全返nil了;
原因
经调试,发现全是惰性期过滤导致返回nil;
分析
现在时序识别全是似层 (参考29064-todo1),导致抽象挂不到canset,而具象是很难多次发生的;
所以,同样的具象fo不太可能发生>2次 (hStrong>2才能结束惰性期),所以convert2CansetModel()全被惰性期过滤成nil了;
回顾
回顾惰性期功能: 当时因为第2步反射训练时,容易乱飞,所以加了惰性期(参考n28p18上);
现状
现在canset加了override和transfer后,感觉保留惰性期的必要性不大;
方案
先写个开关,关掉惰性期,等随后测训中如果再有用时再来打开 改后回测ok T;
29074
TCCanset中override算法过滤无效BUG
分析
经查,在override算法中,取filter时,是用abs和con抽具象路径上取的;
原因
但其实像father和i的canset迁移过,有迁移关联,而不是抽具象关联;
修复
将override中取filters,由使用抽具象关联改为使用迁移关联即可 T 回测手训第2步转29075;
29075
继续第2步手训躲开,发现问题: 测得第3次时,并不能迁移成功并躲开
训练说明
在路偏上偏右扔,手动躲开,然后在路偏上偏中扔,手动躲开,然后在路偏上偏左扔,结果并没有自行躲开;
问题
按上面训练,第3次时,其实应该可以学会自行躲开,但事实上并没躲开;
思路
可以分析一下第3次和前2次的场景有没有共同抽象,如果有共同抽象场景,再分析一下brother的canset为什么没迁移过来;
调试
经测在第2步第1次和第2次就有F609和F217两个共同抽象,F609在第1次时brother为F678,F217的brother为F431;
日志
调试为什么brother没迁移过来的问题: 在第2步第2次时,关键日志如下:
日志1: item场景(Father):F217[A216(高100,皮0,向6)] 取得候选数:0 转成候选模型数:0
日志2: item场景(Father):F609[A608(高100,皮0,向358)] 取得候选数:0 转成候选模型数:0
日志3: item场景(Brother):F678[A675(高100,皮0,距161,向358)] 取得候选数:7 转成候选模型数:0
日志4: item场景(Brother):F431[A428(高100,皮0,向355,距175)] 取得候选数:12 转成候选模型数:0
说明: 见以上日志,第2次时,Father有识别到F217和F609,并且Brother也有取到F678和F431;
问题
根据F678和F431取得候选数共7+12=19条,但全部被过滤掉了,但下全被过滤的原因;
分析
怀疑是brother的前段不可能条件满足,待调试确定下(重训第2步第2次可调试),然后再分析解决方案;
方案1
在convert2CansetModel()之前先将brother生成为迁移后fatherSceneFo,但不存储hd;
缺点: 方案1复用了迁移代码,并且未造成提前迁移sceneFo,会造成性能等问题 5%;
方案2
在convert2CansetModel()中,在判断条件满足时,针对brother时做优化;
优点: 相对方案1,方案2更符合不滥改的原则;
缺点: 方案2的brother与i毕竟太远,判断起来要mIsC2,跨两层可能导致条件满足成了摆设 5%;
方案3
综合方案1和2,迁移支持取iAlg(且不存),然后在判断条件满足时还是原来的mIsC判断protoA is iAlg即可 95%;
注: iAlg与iFo迁移代码同理,但iAlg只是取得iAlg返回,不构建新节点,然后用于在条件满足中判断mIsC时用;
总结
方案3综合了1和2的优点,且排除了1和2的缺点,所以选用,实践如下:
todo1
实现方式: 在TCTransfer写支持alg的推举和继承 (原来是对fo迁移,现在是支持下alg迁移) T;
todo2
前段条件满足-兼容canset是从brother来的情况 T;
todo3
前段条件满足-兼容canset是从father来的情况 T;
todo4
复查下所有updateConCanset()时,都把scene和canset补上indexDic映射 转29076;
todo5
迁移前canset和proto无抽具象关联,所以前段条件满足后,要用迁移后cansetA与protoA来计算前段匹配度 T;
29076
补全canset的indexDic (参考29075-todo4) T
简介
要兼容canset迁移时判断条件满足,需要所有canset与scene有indexDic映射,本节补全缺失的indexDic;
todo1
补全canset迁移后的indexDic T
步骤: 根据fatherCanset与fatherScene的映射(上) 与 fatherScene与iScene的映射(下)
> 得出 => iScene与iCanset(由fatherCanset逐帧对应得出)的映射(下) 示图如下;
todo2
补全canset类比后的indexDic T
步骤: 根据scene与oldCanset的映射(下) 与 oldCanset与absCanset的映射(上)
> 得出 => absCanset与scene的映射(上) 示图如下;
29077
回测29075-场景判断失败导致Canset迁移失败的BUG
步骤
防撞训练第2步手测: 第1次在路偏上右侧手动躲开,第2次在跑偏上左侧,直投后看能不能躲开;
结果
经修复29075-todo5和29076后,第2步第2次训练,即可自行连续飞躲开 T 结果存为FZ79;
29078
继续推进训练:各向躲训练
问题
BUG_FZ79后,即使在路偏下,怎么训练,它都是向上飞躲 (飞错方向);
分析
示教训练太少,导致它有过上飞躲开的经历,本节继续训练在不同位置需要向不同方向躲技能;
训练
先训练下第2步,如果无效,可以试下改成示教模式(认知模式)再训练第2步;
结果
按以上动物模式和认知模式训练第2步,都依然有飞错方向的BUG 转29079;
29079
各向躲训练: 飞错方向的BUG
复现
防撞第1步正常训练,第2步用认知模式训练,然后投路偏下偏左一点,会错误的向右飞,没成功躲开
思路1
首先现在没有负SPEFF数据,所以错也是正常现象,所以如下:
继续训练先: 先做下试错训练，使负SPEFF统计跑出来些数据。训练后测下负统计数据作用于canset竞争;
示图:
然后: 尝试将transferAlg都存下来，在竞争时看要不要综合一下它的speff数据。
思路2
同一批pFos,能不能互相印证canset的有效性?以帮助更准确的对canset竞争评价;
比如: pFo1迁移过某canset并确定它无效,pFo2现在又迁移类似的canset时,它是否也大几率无效?
暂停
先做2907a,防重性能机制,避免各种cansets一堆,影响到飞错方向 暂停,先做2907a;
2907a
一次rSolution调用上千次convert2CansetModel的性能问题: cansets竞争机制迭代
简介
如下日志,防撞三步训练完后,rSolution执行时调用上千次convert2CansetModel: 数据量大,性能太差
日志
rSolution打印: R场景树枝点数 I:3 + Father:13 + Brother:375 = 总:391
DEBUG匹配 => 循环圈:1 前辍:TCCanset.m 代码块:convert2Canset 3 计数:1431 均耗:1 = 总耗:1151 读:412 写:0
DEBUG匹配 => 循环圈:1 前辍:TCCanset.m 代码块:convert2Canset endR 计数:573 均耗:1 = 总耗:440 读:166 写:0
说明
如上日志: 有375条brother,且1431次进入convert2CansetModel(),最终输出617条cansetModel;
方案
将TCCanset的竞争机制改下,无论是激活的cansets还是激活后的防重机制都迭代下 转29081;
结果
在29081加了canset过滤器和scene过滤器后,性能ok,经测训练完防撞第3步后,此处总耗为70ms T
已解决: 本节前面各BUG全解决了,至29077-FZ79手训防撞第2步也可以使用迁移后的canset顺利飞行躲开;
未解决:
在29072测得用scene树取得的cansets有重复可能 (转29081-改项5);
29079测得各种cansets太冗余了,导致各种飞错方向,却来不及对它们全判负SPEFF (转29081修后回测);
2907a测得性能问题,需改进竞争机制,宽入窄出配置调整 (转29081);
n29p08 Cansets宽入窄出竞争机制配置调整 CreateTime 2023.05.02
在上节末,训练飞错方向了(参考29079),然后也测得性能问题(参考2907a),本节先迭代canset宽入窄出改进性能问题,然后再回测下飞错方向的问题;
29081
通过以下修改项各项并行改动,迭代改进cansets的宽入窄出竞争过滤机制
改项1 增强override的防重机制 参考29079-思路2: 同一批pFos,是否可以互相印证canset的有效性?
todo11
单条iScene对整个scene树下的所有fatherCanset都有override防重作用 废弃 (参考-改项2-疑问);
todo12
单条fatherScene对整个scene树下的所有brotherCanset都override有防重作用 废弃 (参考-改项2-疑问);
改项2 在getOverrideCansets()中对整个scene树中全局father和brother中重复出现的canset做综合评分;
todo21
整个scene树下的所有fatherCansets中重复的canset综合speff评分 废弃 (参考-改项2-疑问);
todo22
整个scene树下的所有brotherCansets中重复的canset综合speff评分 废弃 (参考-改项2-疑问);
疑问: 多条iScene指向同一个fatherScene时,虽然fatherScene重复了,但它迁移时指向的iScene不同;
所以: 它们其实是有不同的,至少在transfer生成iCanset时,它们是不一样的,所以todo11,todo12,todo21,todo22全废弃;
改项3 判断transferAlg后,如果会生成多条一样的结果,则对其做防重(注意此处:未生成迁移后的fo);
比如: 张三打人和李四和王五打人,都迁移成我打人,则3次生成经防重只生成一条;
反方: 我在水里和天上打人往往失败,但在陆地上打人却能成功;
所以: 多条iScene还是会生成多条,以上只是多条brother推举到father时要防重;
todo31
其实生成了三条,只是它综合了speff评分 (参考todo21 & todo22) 废弃 需继续深入细节,转29082示图;
分析: 这条没啥问题,本来就是生成三条,但怎么实现综合speff评分?需要继续深入分析,转29082示图
todo32
推举的防重机制能够fo的构建全局防重机制即可实现 T;
改项4 对每个fatherScene和brotherScene根据effectDic对他的cansets做竞争和限制limit;
todo41
写AIFilter对effectStrong评分进行竞争限制20%的limit激活 T;
改项5 fatherScene和brotherScene也要支持防重 (参考29072)
结果 本表有些浮于表现,没想透彻,导致除了todo32和todo41外别的都没写,转由29082继续;
小结: 29081尝试分析本节canset竞争机制的问题,但浮于表面,未能深入,所以仅大致AIFilter加了个过滤器,然后加了canset的全局防重,别的待深入继续分析,转后面
29082
继续深入分析飞错方向问题 (说白了,还是cansets的竞争机制问题,让更准确的canset更易执行行为化)
说明
本节继续深入分析: 通过分析怎样的迁移更准确,怎样的不一定准确,来解决飞错方向的问题
示图
思路1
如图思路1方案分析如下 95%:
1. 如图,s2和s3中间层共同抽象只可能是似层(如s4),而s4也是father层,用它来预判c1迁移到c3后可能无效;
2. 相当于s1将c1继承给s2,然后s2又将c2推举到s4,这么一继承一推举,确实看起来此思路可行;
3. 即在当前pFos迁移过,它的迁移性就更强: 在一继承一推举中,与当前pFos相关性强的,它的可迁移性越强;
思路2
如图思路2方案分析如下 5%:
1. s2和s3差异有可能巨大,此时共享负经验显然不准确 (比如:少年我打不死老虎,青年我继承打老虎技能后可能轻松虐它);
2. 即: 少年我和青年我,想共享speff经验,最好是找到二者的共同抽象,这样共享起来有依据 (即思路1的做法);
结果
思路2太简单暴力,导致准确度不足,所以思路2废弃,而思路1无此问题,暂选定思路1;
总结
1. 从思路1可以看出,现在要解决的是让更贴合当前场景的(也即更准确的)迁移结果,优先级更高来实现override防重;
2. 以往都是具象的场景匹配度更高,而cansets在此基础上,又追加了: 经迁移的找更确定度更高的 (迁移后有效性更高);
3. cansets的竞争: 不能单纯向性下找具象,也要更聪明的顺着迁移关联找到中间层即准确又稳定的那个匹配结果;
结果
总结了本表的成果,更多的深入分析和实践规划转29083;
小结: 29082通过示图分析,得出了问题深入的初步方向 (需要找出更准确更稳定更易执行的canset),而后可以推进分析出解决方案了,默诵后面
29083
根据29082思路1继续分析 -> 制定方案1 5%
简介
29082的思路1共有两个重点:
重点1
override算法需要增强: 但不能阻止任一条canset的可能性被防重掉;
说明: 可以调试下,那些曾经有效的解,为什么没有在竞争中战胜那些飞错方向的解,然后针对性改代码;
重点2
需要找出中间层抽具象准确的场景: 但不能简单的用向性下来取得;
说明: 需要根据迁移关联来辅助找,比如顺着迁移关联找出似层中与当前pFos匹配度高的场景;
方案1
根据迁移关联找出中间抽具象稳定层,来慢慢竞争浮现稳定解,以解决飞错方向问题;
缺点
此方案用迁移关联来找中间层,控制器的控制力有点弱,因为用迁移关联极可能找不到中间层,可能找到的是交层等问题;
29084
根据现有代码问题分析 -> 制定方案2 95%
现问题1
brother层和father层和i层,现在是公平对决的,但三者本来就不公平不应公平对决;
1. 越接近i层越准确;
2. 越被pFos涵盖度高,越准确;
现问题2
在决策阶段: canset中,多层多样性没体现出来,现在father和i,其实就是两层,一个太抽象,一个太具象;
1. 在TI阶段,识别负责准确度(似层),学习负责抽象度(交层);
2. 在TO阶段,谁负责迁移源?谁负责稳定性? (交层可负责迁移源,似层负责稳定性);
方案2
根据交层father.conPorts进行匹配度判断,将有解的,且匹配度高的找出来,做为似层稳定中间层,以解决飞错方向问题;
优点
本方案无方案1的控制力弱的问题,交似层明确区分与协作,可控制操作性大大增强;
小结: 根据29083和29084分析出两个方案,可以解决飞错方向的问题,并且最终选定方案2
29085
TC模型名称更新说明 (决策各选了新词描述):
1
认(认识): 识别
2
知(知道): 学习
3
决(决定): 分析
4
策(策略): 方法
29086
通过外部HE模型,和内部交似相对协作: 来分析方案2细则
注解
读本表前,先看下29085的TC模型名称更新说明,用那些名称对应来读本表更易理解;
说明
29084制定了方案2,敲定了交似层各司其职,本表分析一下方案2的细则,因为以往的TO并未对交似层区别对待,这需要写新东西;
问题1
方案2明确了交似层各自的职责,那么交似层各负责什么?如何相对与协作?
解答1
此问题分析二者的职责,与相对协作方式,如下:
1. 交层负责分析稳定解,似层负责切实可行的方法;
> 注: 似层为反馈匹配的工作做好准备 (反馈识别结果全是似层,所以只有似层的实际行为化才可能被反馈成立);
2. 交层是右而不发 (只分析采用哪个方案,但不推进),似层是纯右方法(找具体可行方法),二者的相对:就是先分析,后方法;
问题2
方案2与TI阶段也有相对,只是TO阶段是右主下辅,那么从HE模型上分析下,此处怎么融入到右主下辅中?
解答2
此问题在HE模型上分析对比TI与TO交似层的工作流程,如下:
1. TI阶段入(感知)后,做好准备(VAFM打通右向性),执行: 认识别(似层,向性上) -> 知学习(交层,向性上) ;
2. TO阶段求(计划)后,做好准备(交似打通下向性),执行: 决分析(交层,向性右) -> 策方法(似层,向性右) ;
举例
通过乌鸦防撞示例,套入本表方案2,并尝试先验推导此方案可行性,示例如下:
决: 交层分析[(高,皮,向350),上飞]是稳定能躲开的 (依据此结果再找似层具体方法S);
策: 似层找到[(高,皮,向350,距48),上飞]更具象可行的方法 (且可支持反馈系统工作);
总结
综上,仅从交层抽象分析S,再从似层找具体的S方法;
小结: 根据29085和29086分析方案2的细则,外部从融入HE模型分析,内部从交似的相对与协作分析;
29087
实践规划
说明
本表对以上29084-方案2和29086细则分析部分进行代码实践规划分析;
29086实践规划
其实就是个TCSolution是否更明确区分交似层的问题,即: i和brother必须是似层,father必须是交层 ;
回顾1: TCSolution现在即有solutionFoRankingV2(即分析),也有可行性判断TCRealact(即方法);
回顾2: 现代码在决时,未要求必须是交层 (因为有可能交层全不稳定,似层却有稳定的中间层);
>>>>> 参考代码: 现在在solutionFoRankingV2()是不区分交似层的 (谁pk胜利谁ok);
回顾3: 现代码的策时,要求必须是似层 (因为只有似层才可行性高,且无缝衔接反馈)
>>>>> 参考代码: 现在代码真正执行的全是iCanset (所以必然是似层);
结果: 从代码回顾1,2,3来看,这一条其实不用改啥,现在代码应该几乎就全支持 看起来不用改代码,几乎本就如此 T;
29084实践规划
将交层father.conPorts进行匹配度判断,将有解且匹配度高的找出,做为似层稳定中间层,以解决飞错方向问题;
解析1. father.conPorts其实就是brother呗,然后找出匹配度高的,再做稳定性pk出稳定中间层;
结果1. 找出有解且匹配度高的,这个现代码未支持,转29089继续分析 转29089-解答1;
结果2. 进行稳定性pk,现代码就在进行稳定性pk,只是更广泛,对i,father,brother都参与了pk;
>>>>> 感觉没必要非得仅对brother进行pk,毕竟有些已经迁移到father和i了 暂不用改啥;
结果
发现29086和29084都几乎不用改,代码本就大致如此,而针对29084-结果1,现代码不如此的,转下表继续;
小结: 根据29084方案2和29086规划代码实践,分析了一下需要改什么然后回顾代码,发现几乎本就如此,除了29087-29084实践规划-结果1转由下表继续,别的都不用改
29088
29086成果总结
接上
29086向着HE模型套入当前问题来分析,也确实套入成功了,算是近期TO改动与模型有些许远离的补偿吧
1
最终发现决依然对应的是TCSolution(求解) //决是争而不发 :只求解竞争不真正迁移
2
而策则对应的是TCTransfer(迁移) //策是将争的结果发出去 :迁移成iCanset
名称改
在贴合HE模型对应上相关模块后,名称改为以下:
★1
认(认识): 识别
★2
知(知道): 学习
★3
决(决定): 求解
★4
策(策略): 迁移
相对
在1和3,2和4中找出相对: 求解使用识别,学习用于迁移
结果
即TO控制弱不存在,只是竞争有断层,将求解使用识别这条加上,来拟补竞争断层的问题 转29089;
前半节总结: 从29081-29087绕了一大圈,发现最后不存在控制力不足(只是写的代码没想通对应着模型哪一块) 参考29088-结果
29089
通过思维流程来分析证实: 求解的竞争有断层
接上
接29088结果: 控制力弱不存在,只是求解使用识别的竞争机制未加上,导致竞争有断层
★
竞争只要有断层,就会导致前面所有竞争做的努力全白费,因为木桶效应,在闭合循环中,只需要一个短板就能带来熵增混乱;
现流程
决求解(TCScene,TCCanset)->策迁移(TCTransfer,TCRealact)->canset识别->canset类比
问题1
发现问题: TCScene中向着抽具象取sceneTree时,取了所有的absFather或conBrother,这样无差别对待有问题
说明: 在慢慢学习越来越明确的整个过程中,可能absFather和conBrother有各种根本不怎么匹配的幼婴期抽具象关联;
影响: 这样会导致不那么匹配的迁移,自然也会有导致飞错方向的问题;
解答1
TCScene改为仅取最匹配前20%的absFathers和conBrothers进行后续操作;
补充: 要求absFathers和conBrothers必须是含cansets的部分,才有资格进行20%的竞争;
小结
根据问题1和解答1,可见竞争的断层就在求解的TCScene中,即验证了29086b的结果,断层确实在求解中;
方案
写TCScene求解使用识别(Scene求解过滤器) (通过复用识别匹配度来实现Father和Brother层的竞争) 实践转2908a;
小结: 其实现在缺失的还是29088-结果 & 29089-解答1中指出的缺失竞争问题,因为HE的各模块取数据其实都要有伸有缩,只要有伸没缩就必然会带来混乱问题;
2908a
求解使用识别-实践规划
todo1
前期验证: 将匹配度打印出来,看下改之前飞错方向时,它的baseScene匹配度是否很低;
todo2
写Scene求解过滤器 (复用识别匹配度做竞争过滤器) T;
todo3
应用Scene求解过滤器: 在TCScene中取father和brother时调用 T;
todo4
Scene求解过滤器仅保留前20%的结果 T;
todo5
Scene求解过滤器过滤掉无conCansets的结果 T;
todo6
回测下,是否真的在稳定性的scene下: 如[向350棒],生成了稳定的canset[向350棒,上飞];
本节总结: 在29081-todo41加了TCCanset的竞争机制(稳定性竞争),在2908a写TCScene竞争机制(使用识别算法实现),然后2907a的性能问题ok了,经不则优化为总耗70ms了;
n29p09 回测TCCanset和TCScene竞争机制 CreateTime 2023.05.08
上节写了Scene和Canset过滤器,本节回测过滤器,并回测29079-飞错方向问题;
29091
测得Scene过滤器排序因子:匹配度全是0: 取到的conFo和absFo用indexDic复用匹配度为0
调试
经调试,indexDic映射的抽具象alg间没有matchValue存着,但alg间的mIsC关联是有的;
修复
经查,在类比器中alg类比时,生成抽象alg与具象alg未存匹配度,导致复用时为null,加上后ok了 T;
回测1
经回测,alg类比后不再有未存上匹配度的问题 T;
回测2
经回测,Scene过滤器排序因子取匹配度也有值了 T;
29091
测得还是飞错方向-向355却下飞了
说明
防撞训练第3步后,出生路中偏右上,扔木棒,结果下飞了,应该上飞才对
调试
见29092代码段日志,概念和时序识别时就有向2和向6,结果F1067取得了CansetF2910最终执行输出;
结果
尝试在训练过程中,使speff越来越准确 转29093;
29092 代码段
== = == == == == == == == == == == == == == == 1 时序识别 == = == == == == == == == == == == == == == ==
protoFo :F4930 [A4928 (高100 ,皮0 ,向357 ,距160 )]->
过滤器 : 总10需6 主 :0.62 = > 剩 :6 辅 :0.97 = > 剩 :5
时序识别结果 P (5 条 ) R (0 条 )
P强度 :(72 ) > F626 [A621 (高100 ,皮0 ,向355 ,距149 )]-> {-5.32 } (SP :{0 = S0P71 ;1 = S42P29 ;}) indexDic :{0 = 0 ;} 匹配度 = > 0.94
P强度 :(51 ) > F864 [A861 (高100 ,皮0 ,向356 ,距134 )]-> {-3.71 } (SP :{0 = S0P50 ;1 = S21P30 ;}) indexDic :{0 = 0 ;} 匹配度 = > 0.89
P强度 :(25 ) > F1067 [A1062 (高100 ,皮0 ,向2 ,距137 )]-> {-6.38 } (SP :{0 = S0P24 ;1 = S17P7 ;}) indexDic :{0 = 0 ;} 匹配度 = > 0.88
P强度 :(82 ) > F96 [A93 (高100 ,皮0 ,距182 ,向6 )]-> {-2.89 } (SP :{0 = S0P81 ;1 = S26P55 ;}) indexDic :{0 = 0 ;} 匹配度 = > 0.86
P强度 :(36 ) > F676 [A672 (高100 ,皮0 ,向355 ,距191 )]-> {-3.09 } (SP :{0 = S0P35 ;1 = S12P23 ;}) indexDic :{0 = 0 ;} 匹配度 = > 0.86
== = == == == == == == == == == == == == == == 1 rSolution == = == == == == == == == == == == == == == ==
任务源 :ImvAlgsHurtModel protoFo :F4930 [A4928 (高100 ,皮0 ,向357 ,距160 )] 已有方案数 :0
第1步 R场景树枝点数 I :5 + Father :14 + Brother :71 = 总 :90
item场景 (I ):F1067 [A1062 (高100 ,皮0 ,向2 ,距137 )] 取得候选数 :3 转成候选模型数 :1
item场景 (I ):F864 [A861 (高100 ,皮0 ,向356 ,距134 )] 取得候选数 :6 转成候选模型数 :2
item场景 (Brother ):F1130 [A1127 (高100 ,皮0 ,距110 ,向2 )] 取得候选数 :1 转成候选模型数 :1
item场景 (Brother ):F1067 [A1062 (高100 ,皮0 ,向2 ,距137 )] 取得候选数 :3 转成候选模型数 :1
item场景 (Brother ):F1767 [A1758 (高100 ,皮0 ,向1 ,距89 ),A1194 (飞 ←),A1764 (高100 ,皮0 ,距0 ,向151 )] 取得候选数 :3 转成候选模型数 :2
item场景 (Brother ):F1067 [A1062 (高100 ,皮0 ,向2 ,距137 )] 取得候选数 :3 转成候选模型数 :1
item场景 (Brother ):F864 [A861 (高100 ,皮0 ,向356 ,距134 )] 取得候选数 :6 转成候选模型数 :2
item场景 (Brother ):F864 [A861 (高100 ,皮0 ,向356 ,距134 )] 取得候选数 :6 转成候选模型数 :2
第7步 排除FRSTime来不及的 :12
0 : F2910 [A1062 (高100 ,皮0 ,向2 ,距137 ),A1131 (飞 ↓),A2904 (高100 ,皮0 ,距66 ,向158 )] (前0 .88 中0 .25 后1 .00 ) fromSceneFo :F1067 eff :F2910 :H1N0 sp :{}
1 : F2287 [A861 (高100 ,皮0 ,向356 ,距134 ),A1168 (飞 ↘),A2277 (高100 ,皮0 ,距48 ,向8 ),A1168 (飞 ↘),A2282 (高100 ,皮0 ,向146 ,距25 )] (前0 .89 中0 .00 后1 .00 ) fromSceneFo :F864 eff :F2287 :H2N0 sp :{1 = S0P1 ;2 = S1P0 ;}
2 : F2305 [A861 (高100 ,皮0 ,向356 ,距134 ),A1216 (飞 ↗),A2297 (高100 ,皮0 ,距54 ,向332 ),A1216 (飞 ↗),A2302 (高100 ,皮0 ,距32 ,向259 )] (前0 .89 中0 .12 后1 .00 ) fromSceneFo :F864 eff :F2305 :H2N0 sp :{1 = S0P1 ;}
3 : F4054 [A1127 (高100 ,皮0 ,距110 ,向2 ),A1194 (飞 ←),A4046 (高100 ,皮0 ,距49 ,向37 )] (前0 .88 中0 .25 后1 .00 ) fromSceneFo :F1130 eff :F4054 :H1N0 sp :{}
4 : F2910 [A1062 (高100 ,皮0 ,向2 ,距137 ),A1131 (飞 ↓),A2904 (高100 ,皮0 ,距66 ,向158 )] (前0 .88 中0 .25 后1 .00 ) fromSceneFo :F1067 eff :F2910 :H1N0 sp :{}
= == = == = == = == = == = == = == = == = == = == = 1 TCRefrection反思 == = == == == == == == == == == == == == == ==
> newS 第1例 : F2910 [A1062 (高100 ,皮0 ,向2 ,距137 ),A1131 (飞 ↓),A2904 (高100 ,皮0 ,距66 ,向158 )]
29093
所有father取到的canset全是0条
日志
item场景(Father):F634[A633(高100,皮0,向355)] 取得候选数:0 转成候选模型数:0
item场景(Father):F726[A725(高100,皮0,距149)] 取得候选数:0 转成候选模型数:0
item场景(Father):F628[A627(高100,皮0,向359)] 取得候选数:0 转成候选模型数:0...
线索
经查,在TCTransfer中迁移后的newCanset存到了targetIndex下,而canset的target和sceneFo的target是两回事
canset的target是执行目标,而scene的target是任务目标,二者用错了导致存下的canset存错地方,所以取不到
方案
将canset执行目标转成scene的任务目标,然后再存canset到转换后的正确位置即可 T;
29094
日志测试分析下整个训练过程中,canset越来越准确度的演化过程
尝试1
看能不手训第2步(包括正常躲开和错误被撞),然后观察speff的准确度变化;
BUG1
手训第2步手动躲开多次后,发现所有转成cansetModel的还是0条
查证: 经查,在cansetFilter过滤后全是长度为1的canset,>1的全被过滤了,然后取cansetModel时全被无后段过滤掉;
方案1: 在取得conCansets后立马对长度<=1的过滤下先,再过cansetFilter过滤器 性能差 10%;
方案2: 直接不存canset长度<=1的 性能ok 90%;
修复: 方案1性能不佳,先选方案2: 改代码为无后段时(canset长度<=1时),直接canset存都不存;
结果: 改后经回测ok,没导致别的什么影响或问题,也可以很快就迁移到解 T;
BUG2
查下是否先转cansetModel,再进行cansetFilter?避免太早误杀符合却不太好的解 (留下的全不符合转cansetModel失败);
结果: 先不改,因为目前也不会严重到过滤太早导致留下的转cansetModel全失败 等真正明确了此问题时,再来继续改;
BUG3
SceneFilter过滤后未必准确,仍然有可能过滤出老旧的F和B层;
说明: 老旧的F和B,会导致更多混乱的前期错误被延续到后期仍在被体现,而这些错误无法随着训练演化被沉寂;
方案1: 可尝试把SceneFilter的匹配度竞争,改成pId早晚竞争,保留下最晚的20%试下 5%;
>>> 此方案不行,因为很多准确的F层是很早生成的,只是后期频繁反复验证了它的正确性而已;
>>> 分析: 除了pId早晚,还有个早晚期的可参考数值,即强度 转方案2;
方案2: SceneFilter改为和时序识别过滤器一样的: 强度为主,匹配度为辅;
结果: 此问题未验证,但先将方案2实践了,毕竟改动不大,设想也较为可信 T;
尝试2
改完上几个bug:继续手训第2步,看能否speff越来越准;
训练规划: 先在认知模式手训上下都能躲开,再在动物模式试错数次,并观察speff变化;
训练: 经认知模式路偏上和下各训练两次,然后试错训练8次,发现问题如下:
问题1. 失败过的canset但它的N和S没统计上 转29095;
问题2. 各种canset太多,否不完 修复29095后,无明显否不完的问题 T;
结果
本表尝试手训观察canset的speff准确度演化,测得三个bug并修复,然后在尝试2训练中又发现两个问题,转下表;
29095
失败的canset未统计上N和S问题
日志1
首次飞躲失败时: > newS 第x例: eff:H1N0 sp:{1 = S0P2;2 = S2P0;} Father:F109 F1412
再次飞躲失败时: > newS 第x例: eff:H1N0 sp:{1 = S0P3;2 = S2P0;} Father:F109 F1412
问题1
问题说明: 由日志可见,第1次F1412方案失败后,第二次失败时effN一直是0,没+1;
经查,在rEffect()中,对IF两层及其各自的抽象指向,全更新统计了eff,但为什么日志上显示没统计上呢?待继续查;
日志2
试错时,更新了N1: Eff更新S:F1481 (index:1 H0N1)
再试错时,又更新了N1: Eff更新S:F1481 (index:1 H0N1)
问题2
日志2可见,再试错时,N没统计成2;
日志3
刚由father迁移成F1589: 迁移结果: iScene:F777 Canset:F1589
立马eff更新成了H1N1: Eff更新S:F1589 (index:1 H1N1)
问题3
经查F1589文件的创建时间和修改时间一致,应该是新的,但它为什么在无效时更新的H是1呢?
线索
在effect()方法中,无论是fatherCanset还是iCanset全用了iScene,导致fatherCanset统计的EFF在错误的场景下;
修复
在每个ifbCanset都对应一个ifbScene,执行effect()时,一一对应着执行统计更新 T;
29096
继续手动防撞训练
说明
在防撞训练前,发现两个问题,先改掉,算正式手动防撞训练之前的前提;
问题1
尽量在左侧进行训练,因为左侧躲错方向就很难躲开了 (它的惩罚更稳定),而离木棒太远时,即使飞错方向也来的及躲开;
问题2
可以尝试下UIDynamicBehavior来进行碰撞检测,因为现代码的碰撞检测太简略,较容易判错 T;
> 说明: 原来的二段式判断碰撞判错举例: 飞躲开,但木棒走后又飞回路上,被判为撞到,其实没撞到;
结果: 改为用物理仿真碰撞检测了 T;
另外-BUG: 加上UICollisionBehavior后,用UIView动画不生效问题 (导致鸟飞不动);
另外-修复: 鸟的飞行也需要改成物理仿真飞行,不然在dyAnimator中,用UIView.animate()动画无效 T;
结果
问题2修复后,转下表进行回测,并发现有没别的问题 转29097;
29097
回测上表问题2修复结果,并继续手动防撞训练
回测
训练步骤: 上表问题2修复后,训练步骤如下进行回测;
1. 强训防撞训练第1步
2. 认知模式手动躲开: 路中偏上,手动上躲成功两次,路中偏下,手动下躲成功两次;
3. 动物模式试错训练: 路中偏左上,它应该能迁移过来方案,然后自行进行飞躲;
结果: 在第3步试错时,发现无限循环的往屏外飞去,并且木棒也卡在屏中一直飞不到屏最右侧结束区 转29097;
问题
用物理仿真后,有飞行卡循环,木棒飞不全问题,因为物理仿真鸟飞和木棒扔两个动画互相卡;
分析
鸟的不断物理飞行,会导致木棒也卡住,导致木棒一直在鸟偏左上或左下,时序识别一直有pFo结果,预测到有危险;
思路
原来的UIView动画不会卡木棒,所以很多就飞过去了,就没啥危险了,思维循环也就结束了;
新方案
换方案解决碰撞检测: 在原来UIView动画的基础上,加上更多碰撞检测次数,判断上一段鸟的飞行和木棒轨迹是否有交叉;
说明: 轨迹交叉的判断: 鸟飞躲前后形成整体rectB,木棒前后也形成整体rectW,如果rectB和rectW有交集则判为撞到了;
结果
实现新方案后回测发现:当step执行时洽好鸟飞躲开了,飞躲整个rect与木棒整个rect是有交集的,会误判为撞到 转下表;
29098
step碰撞检测误判的问题 (参考29097-结果): 重新分析碰撞检测算法方案
方案1
每次step执行动画后,针对step的Wood和Bird的运动轨迹,单独模拟物理仿真做碰撞检测 5%;
缺点1: 执行动画后,无法给出碰撞结果,要模拟重现推演一下后,才知道答案;
缺点2: 会非常复杂,比如根据运动轨迹飞行速度,触发时间等,数据收集起来,再转为仿真模拟,哪个都复杂;
结果: 所以本方案因过度复杂且容易有性能问题而否掉;
方案2
wood和bird的飞行都有安全期,改为仅判断危险有相撞时,才算撞到 5%;
缺点: 此方案简单的使用安全期来做,但安全期和触发时间非常相关,并且和每一次小鸟的飞行都有关 (比如飞成功又飞回来);
结果: 本方案因为还是有些简略,可能导致不健全而否掉;
方案3
每次木棒或小鸟的frame变化 (根据当前与上条记录的"位置&时间")来切成10等份,分别判断是否撞到 95% 选定;
结果: 此方案收集的数据够用,且切成N等份的方式,也可以替掉29097-新方案中动画分step的方式,步骤如下:
步骤1. 无论是Wood还是Bird的frame触发,都报告木棒和小鸟的位置及时间 T;
步骤2. 根据(上帧和本帧的位置和时间),计算出任意时刻的木棒和小鸟所在位置 T;
步骤3. 将轨迹分成10等份,分别判断是否有相撞的情况 (用Rect交集判断) T;
步骤4. 废除UIView.animate()动画的step动画 T;
结果
将方案3写成runCheckHited()算法,回测大致ok,但还有一些小BUG,如下 T;
测BUG1
发现UIView动画后,不会调用Frame更新触发最后一次碰撞检测,所以在动画结束时手动调用下后ok T;
测BUG2
发现棒(0 -> 736) 鸟(115,229 -> 115,229)鸟一直在危险地带没动,而棒从左飞到右,竟然检测为没撞 T
原因: 因为分10等份并不连续,0-736离的太远,如果可能在3.5帧撞到时,3和4等份都检测不到碰撞 (就是间隙大错过检测了);
修复: 将10等份的上下等份Rect取并集,然后再检测是否碰撞即可 T;
29099
测得eff很差的能竞争到第1名问题
训练
1. 强训防撞训练第1步
2. 认知模式手动躲开: 路中偏上,手动上躲成功两次,路中偏下,手动下躲成功两次;
3. 动物模式试错训练: 路中偏下,它应该能迁移过来方案自行飞躲,但可能犯错并统计到负统计,最终应当能逐渐修正;
训练小技巧: 其间可以刚出生在路边上,使其易躲开,尝点甜头 在结尾测试这一技巧,有效 T;
训练小提示: 第3步不断训练10来次,其间不断观察SPEFF的变化 (应能演化出较为明确的有效解) 已在结尾测此条ok T
问题
训练到在第3步试错,执行10次试错后,统计了不少N,但它竞争还是排第1名?
示图
回顾
代码回顾发现,现solutionFoRankingV2()根据前(匹配度强度)、中(稳定性有效性)、后(匹配度强度)段三项综合排名;
质疑: 前段和后段的匹配度强度并不重要,本来pFos在TI识别中已经根据匹配度强度竞争过了,这里再次竞争显的多余;
>>>: 并且brother和father迁移过来的也会转成iCanset,所以匹配度压根不用操心,所以应该弱化匹配度,强化speff竞争:
方案
迭代solutionFoRankingV3(),废弃前后段的匹配度强度竞争,改为:用cansetFo的speff进行排名竞争,实践如下:
todo1
用迁移前取到的cansetFo来进行speff竞争,因为迁移后还没speff这些数据 T;
todo2
根据AICansetModel的cutIndex和targetIndex来计算稳定性和有效性 T;
另bug1
AIRank的排序排反了,上面示图中出现啥结果都有可能 (是个低级错误,却未测到的bug);
另bug2
AIRank取speff值有问题,因为错用了int类型,导致归1化后只会取成0或1,上面示图压根没算清楚speff值 (低级错误);
结果
方案实践后,又改了几个影响到排名的BUG(未必是此方案的功劳,BUG也明确影响到了排序),但全改后现在还ok T;
2909a
solutionFoRank中SP太容易得0分的问题 T
示图
说明
如果SP全是0分,那好坏就不分呗,坏的可能排前面,导致决策错乱;
思路
scene复现性强(sp可取多帧得分),而canset较长复现率极低,并且在推进过程中不断变化(sp取下一帧得分即可);
方案1
尝试只评下一帧,毕竟一般canset只推进一帧就会有变化了,而eff已经标示了它最终是否有效 尝试了下没用;
> 方案1实践后,回测发现得分又全成了1,还是没有起到排名的作用;
方案2
sp在canset中要弱化,改成eff为主排序,下帧sp仅在eff一致时起辅助排序作用;
todo1. solutionFoRank改为eff为主排序,sp仅做二次补排 T;
todo2. 查别处canset也有sp得分为0的情况,看下也改成eff评分,如:TCRefrection()中 T;
todo3. 经回测,发现todo1排序后H7N0和H4N0可能H4排前面,所以再加上三级排序用H值来排 T;
结果
方案1实践后无效,又在方案1的仅取下帧sp基础上追加了方案2 T;
本节修复了数个TO阶段的未测到的低级BUG,在末尾时,已经可以顺利手训得到很确切的speff,让canset能够顺利上躲和下躲成功,但是最终还是因为识别不够准确,导致连该上飞还是下飞的前提都有了不准确,导致飞错方向的问题 见29101-BUG,下节继续解决这一识别不够准的问题;
CreateTime 2023.05.25
上节经过一大堆BUG的修改,整个决策过程跑着顺当好多了,但最终却因为识别不够准确而有一些影响 (因为向350识别成向10),导致飞错方向,本节修下此问题;
29101
概念识别不够准确问题
示图
说明
如图,识别结果中向352和向10同在,无论训练的SPEFF再好,识别不准确,一切全白搭;
关键★
现在主要问题是不重要的特征,对重点的特征的影响,导致不准确 ;
方案1
在概念识别Filter过滤器中,加强下准确度 5%;
缺点: 治标不治本,样本少的时候,再在各种特征的影响下,还是会不准;
方案2
想办法明确距离不重要 (限定在一组场景中时,做此判断),仅根据方向再排序下;
结果
本节选中方案2,解决不重要特征对重要特征的影响,导致识别不准问题 转下节在方案2基础上继续
29102
不重要的特征,对重点特征影响,导致概念识别不准确问题
说明
接上节,分析下,怎么判断出木棒距离不重要;
分析
1. 通过fo的识别结果,稳定性高的,反过来筛选alg的识别结果? (只有fo才能标示出哪个码无关紧要);
2. 打开识别交层么? (只有交层,才有排除无关码的影响);
步骤
依上面分析结果,来进行步骤分析,看下大概思路流程;
交层版
交层步骤设想步骤如下 (得出交层方案):
1. 用pFo取交层absFo,然后判断下sp稳定性;
2. 找着稳定的后,反过来看交层absPFos中的absAlg缺失哪个码;
3. 再回到具象alg,看下去掉这一码后的匹配度;
4. 过滤掉匹配度低的概念识别matchAlgs结果;
5. 过滤掉匹配度低的matchAlg索引的pFos结果;
交层方案
根据交层步骤,得出无关码,然后计算匹配度,进行识别结果(含pFos和matchAlgs)的二次过滤;
可行性: 套入防撞示例分析此方案的可行性: (结果可见,是可行的);
>>> 1. 无距码照样危险,但无向码未必危险,得出方向码更重要;
>>> 2. 然后排除掉距离,直接按方向匹配度排序来进行过滤;
缺点: 可能得出无距向330到向30危险,但如果有另外一个特征区也在特定情况下会有危险,则可能错过重要特征;
似层版
似层步骤设想步骤如下 (得出似层方案):
1. 用pFo取似层absFo,然后根据稳定部分的每种码的范围(码域)来重新计算V相近度;
2. 然后重新计算alg相近度,fo匹配度(二次计算匹配度),以此进行二次过滤;
似层方案
根据似层步骤,得出码域,然后计算匹配度,并进行识别结果(含pFos和matchAlgs)的二次过滤;
可行性: 套入防撞示例分析此方案的可行性: (结果可见,是可行的);
>>> 1. 距得出范围为30-230=200,向得出范围为:330-30=60;
>>> 2. 这样方向错误的更容易匹配度差,然后被过滤掉;
抉择
目前看起来,以上交层和似层方案都具备可行性,但似层方案看起来更模糊支持,而交层像是一刀切,有不精确的风险;
比如: 红衣炮孙危险,单纯红衣不危险,单纯炮孙也不危险,那么交层方案就比较尴尬;
结果
目前暂选定似层方案,可以看下是否再多进行分析,或在实践中试下是否这方案真ok;
29103
识别二次过滤方案实践前分析
推演
将当前遇到29101的识别不准问题,套入29102方案2,进行推演 步骤如下,结果: 可行;
1. 错误识别到方向5和方向10,取抽象危险稳定的前20%,得到距为30-230=200值域,及向345-35=60;
2. 通过距域200,向域60,重新计算V相近度,然后计算A匹配度,F匹配度,进行二次过滤;
推翻1
既然是抽象指向的,那么它的向和距,值都大差不差,不然也不会有抽具象关联上 已调试实证确实如此;
所以,通过向域和值域重新计算匹配度,是不可行的,因为二者都会维持在同样较小的范围;
推翻2
再则,通过调试发现,pFo.absFo就全是交层,一个似层都没看见 已调试实证确实如此;
推翻3
经调试,通过稳定性求重要性也不可取,因为只要构建了抽具象关联,那么就大差不差,无论向或距,其稳定性都接近;
因为其匹配度高,所以无论是向还是距,你多一点,我少一点,但最终导致的被撞几率是非常接近的;
结果
所以,29102-似层方案是不可行的,似层压根取不到,且即使取到了,也和设想推演的那个压根不一样 推翻 T;
而上节中两个方案,都是依赖场景内稳定性pk来反推特征重要性的,看来两个方案全推翻了 推翻,转下节重新来过 T;
29104
继续深入,重新分析解决方案
分析
1. 交层大多是无距棒,因为在一次次的pFo外类比中,都是向重要,距不重要,导致(alg类比器中)距被抽象掉了;
2. 那么我们所有的pFo.absFos中,将所有的无距与无向的次数统计起来,就可以体现出当前场景下不同特征的重要性;
推翻
下面日志可见,二者有差别但相差不大,因为有抽具象关联的向和距的值都大差不差,所以alg类比也不能确定哪个重要;
比如: 就像实力差不多的初生小虎,和壮年大狗,战了个半斤八两,我们不能说虎打不过狗;
所以: 场景内,无论是哪个特征,其实力都差不多,在场景内无法区分二者不同的重要性 ;
结果
既然场景内无解,那么就跳到场景外求出路 转29105;
//供29104参考代码段:
//说明: 如下日志,在3条pFo的absFos中: 发生7次方向重要,5次距离重要;
for protoFo : F2480 [A1751 (向5 ,距110 ,棒 ),飞 ↑,A2477 (距92 ,向0 ,棒 )]
from pFo : F714 [A711 (向8 ,距89 ,棒 )]
> absFo : F779 [A778 (向8 ,棒 )]->M68 {↑疼 -9 } 稳定性 (0.51 )
> absFo : F842 [A841 (距89 ,棒 )]->M75 {↑疼 -9 } 稳定性 (0.50 )
> absFo : F109 [A108 (向357 ,棒 )]->M13 {↑疼 -9 } 稳定性 (0.56 )
> absFo : F716 [A715 (距101 ,棒 )]->M62 {↑疼 -9 } 稳定性 (0.61 )
from pFo : F504 [A499 (向357 ,距105 ,棒 )]
> absFo : F109 [A108 (向357 ,棒 )]->M13 {↑疼 -9 } 稳定性 (0.56 )
> absFo : F682 [A681 (距105 ,棒 )]->M58 {↑疼 -9 } 稳定性 (0.51 )
> absFo : F223 [A222 (向348 ,棒 )]->M23 {↑疼 -9 } 稳定性 (0.54 )
from pFo : F680 [A677 (向352 ,距101 ,棒 )]
> absFo : F716 [A715 (距101 ,棒 )]->M62 {↑疼 -9 } 稳定性 (0.61 )
> absFo : F984 [A983 (向352 ,棒 )]->M88 {↑疼 -9 } 稳定性 (0.50 )
> absFo : F682 [A681 (距105 ,棒 )]->M58 {↑疼 -9 } 稳定性 (0.51 )
> absFo : F223 [A222 (向348 ,棒 )]->M23 {↑疼 -9 } 稳定性 (0.54 )
> absFo : F109 [A108 (向357 ,棒 )]->M13 {↑疼 -9 } 稳定性 (0.56 )名词解析: 本文场景内: 是指pFo和pFo.absFos的组合都算场景内,因为它指向抽象关联,其实还是pFo的范畴;
名词解析: 本文场景外: 是指pFo和pFo.absFos.conFos取到pFo的同层fos,这些同层算场景外;
29105
继续深入,重新分析解决方案 (从场景外找方案)
引子
本节尝试从场景外求解: 即需要在各场景间,进行对比,以找出哪些特征重要,哪些不重要;
白话: 今天遇到的情况,在别的地方是不是也遇到过,当时和今天的情况,有没有共同点?这个共同点就是重点;
线索1
到了场景外,无论是方向(a),还是距离(b),都会变的广泛,不能计算新的值域了,也不重新计算匹配度了 ;
a.任一个方向都有可能能躲避一种危险; b.任一个距离都可能无危险;
线索2
场景外啥特征值都有,只能通过sp稳定性为依据,来区分特征重要性 即: 场景外只能通过sp稳定性来区分特征重要性 ;
初方案
根据以上,只能在场景外,根据sp稳定性,区分特征重要性 ,然后以此来实现二次过滤;
> 从absFo再取conFos即可取到与pFo的平级fos,然后根据conFos来计算各特征重要性;
> pFo为似层,它的absFos为交层,再取conFos又为似层 (即pFo的同层) => 同层算场景外 (参考本文场景外名词解析);
方案改
见代码段,改为: 取pFo.absFos.conFos的强度前20%,然后用强度来区分各码各处导致mv的几率,以区分重要性 ;
todo1
conFos需要做下防重 (如代码段中的F514和F541就有重复) T;
todo2
conFo可以全收集起来,然后筛出强度前20%名 (不然各种细小的conFo太多了) T;
todo3
从下面: 选个方案,计算出protoAlg中各个特征的强度值 T
方案1. 每种特征的权重曲线计算,方法1: 用每条V值的强度向周边30%冷却辐射,做出最终曲线 较麻烦,先不选用;
方案2. 每种特征的权重曲线计算,方法2: 直接用直线关联起来这些值;
方案3. protoAlg所在的protoFo也在conFo中,所以有自己的强度,只是太弱了,一般为1,不具备参考性;
方案4. 直接protoAlg的某个循环就=最相近的那个conFo中的对应的alg的value的那个强度值 (但要排除protoFo自身);
结果: 最终选定方案4,因为最简单,精度上也没啥明显的问题,可以接受 T 回测不可行,转29106-问题1;
todo4
将高宽这种全程只有一个值的打酱油码,就不计算重要性了,浪费时间,它们在alg的匹配度里,永远100%匹配没有责任 T
todo5
某个v重要性 = 某个v强度值 / 平均强度值 T;
todo5.1 某个v强度值 = 与protoV最相近的那个conFo的强度 (参考todo3-方案4) T 回测不可行,转29106-解曲线;
todo5.2 平均强度值 = 总强度值 / 总conFo数 T 回测不可行,转29106-问题2;
todo6
计算权值时,仅取强度前20%名 & 计算总强度和总conFo数时,取所有的100% T;
// 29105参考代码段 (以下根据pFo取abs再取con,然后将强度排名靠前的打出来log) => 用于分析出29105的方案和实践分析;
for protoFo : F2527 [A2525 (向7 ,距122 ,棒 )]
from pFo : F514 [A511 (距119 ,向0 ,棒 )]
> absFo : F559 [A558 (向0 ,棒 )]->M46 {↑疼 -9 } 稳定性 (0.55 )
> conFo : F514 [A511 (距119 ,向0 ,棒 )]->M39 {↑疼 -9 } 稳定性 (0.62 ), 强度12 {0 = S0P40 ;1 = S15P25 ;}
> conFo : F541 [A538 (距177 ,向0 ,棒 )]->M42 {↑疼 -9 } 稳定性 (0.50 ), 强度11 {0 = S0P26 ;1 = S13P13 ;}
> absFo : F2171 [A2170 (距119 ,棒 )]->M119 {↑疼 -9 } 稳定性 (0.00 )
> absFo : F109 [A108 (向357 ,棒 )]->M13 {↑疼 -9 } 稳定性 (0.54 )
> conFo : F102 [A99 (向357 ,距61 ,棒 )]->M11 {↑疼 -9 } 稳定性 (0.53 ), 强度21 {0 = S0P70 ;1 = S33P37 ;}
> conFo : F504 [A499 (向357 ,距105 ,棒 )]->M38 {↑疼 -9 } 稳定性 (0.46 ), 强度15 {0 = S0P54 ;1 = S29P25 ;}
> conFo : F136 [A133 (向357 ,距72 ,棒 )]->M17 {↑疼 -9 } 稳定性 (0.62 ), 强度14 {0 = S0P50 ;1 = S19P31 ;}
from pFo : F964 [A959 (距110 ,向359 ,棒 )]
> absFo : F1392 [A1391 (向359 ,棒 )]->M107 {↑疼 -9 } 稳定性 (0.31 )
> conFo : F964 [A959 (距110 ,向359 ,棒 )]->M83 {↑疼 -9 } 稳定性 (0.42 ), 强度11 {0 = S0P38 ;1 = S22P16 ;}
> absFo : F1770 [A1769 (距110 ,棒 )]->M114 {↑疼 -9 } 稳定性 (0.29 )
> absFo : F779 [A778 (向8 ,棒 )]->M68 {↑疼 -9 } 稳定性 (0.50 )
> conFo : F714 [A711 (向8 ,距89 ,棒 )]->M61 {↑疼 -9 } 稳定性 (0.62 ), 强度5 {0 = S0P26 ;1 = S10P16 ;}
> absFo : F559 [A558 (向0 ,棒 )]->M46 {↑疼 -9 } 稳定性 (0.55 )
> conFo : F514 [A511 (距119 ,向0 ,棒 )]->M39 {↑疼 -9 } 稳定性 (0.62 ), 强度12 {0 = S0P40 ;1 = S15P25 ;}
> conFo : F541 [A538 (距177 ,向0 ,棒 )]->M42 {↑疼 -9 } 稳定性 (0.50 ), 强度11 {0 = S0P26 ;1 = S13P13 ;}
> absFo : F109 [A108 (向357 ,棒 )]->M13 {↑疼 -9 } 稳定性 (0.54 )
> conFo : F102 [A99 (向357 ,距61 ,棒 )]->M11 {↑疼 -9 } 稳定性 (0.53 ), 强度21 {0 = S0P70 ;1 = S33P37 ;}
> conFo : F504 [A499 (向357 ,距105 ,棒 )]->M38 {↑疼 -9 } 稳定性 (0.46 ), 强度15 {0 = S0P54 ;1 = S29P25 ;}
> conFo : F136 [A133 (向357 ,距72 ,棒 )]->M17 {↑疼 -9 } 稳定性 (0.62 ), 强度14 {0 = S0P50 ;1 = S19P31 ;}
29106
特征强度值分布曲线
问题
在29105中,计算出重要性有错,原因有二:
1. 29105-todo3-方案4的偶发性高,即使在向5这样的危险高发区,也可能正好遇到最相邻的强度只有2;
2. 29105-todo5.2中计算平均值不可用总强度值和总conFo数,因为向集中,距分散,用这些向距求平均值,都会受此影响;
思路
向集中,距分散 (调试时向值在355-8,距值49-177),所以如下两条改后新解法:
解曲线
1. 根据29105-todo3-方案3改进: 用每条V值的强度向周边100%(两边各50%)冷却辐射,做出最终曲线 T
>>> 关于冷却函数,可以先取环境温度为30%,随后在调试中,看是否随着样本数量做出相应动态调整;
解均值
2. 求平均值 = sum(从整个V值域中,均匀取样100份)/100 T;
>>> 举例: 比如方向码为:0-360度,取样为0,3.6,7.2...,曲线上取Y值求和/100
todo7
最终得出向距重要性,如:1.向5重要性320% 2.向180为11% 3.距150为90% 4.距210为110% 5.距40为150% T;
todo7.1
根据50%辐射,30%环境温度,发现竞争不足,后改为33%辐射,10%环境温度 T;
todo8
根据不同特征重要性,对识别结果进行二次过滤 转29107;
29107
根据重要性,进行二次过滤: 公式步骤和代码实践
说明
重要性有高有低,为表示出高的重要性,低的不重要性,采取如下公式 (分两步);
步骤1
几个V的重要性,等比缩放,使最小的V为1单位,别的则全>1 (注:缩放是为了支持第2步顺利工作,第2步次方不得<1) T;
比如: 距为0.5,向为2,在缩放后,则距为1,向为4;
步骤2
每个V的二次过滤相似度 = V原相似度的重要性次方 (注:重要性次方,放大了重要V的在匹配度中起到的作用) T;
说明: 因为步骤1已经让最小的为1,所以越重要的值越大就会越占便宜,不重要的因为接近1次方,不占任何便宜;
例如: 当向重要性=2,距重要性为0.5时,缩放后为向4,距1;
>>> 如果原匹配度为: 向0.9 x 距0.1 = 0.09, 二次过滤相似度=0.90.9 0.90.9 0.1=0.0656;
>>> 如果原匹配度为: 向0.2 x 距0.8 = 0.16, 二次过滤相似度=0.20.2 0.20.2 0.8=0.0013;
小结
即通过步骤1和步骤2,使原本0.16 > 0.09,成功变成了0.0013 < 0.0656;
另外
在如上两个步骤代码实践后,还需要写些别的todo如下:
todo1
概念识别结果matchAlgs要用新匹配度来排序,并过滤下 (保留40% & 至少保留4条) T;
todo2
时序识别结果matchPFos则根据概念识别二次过滤结果来过滤 (剩几条算几条) T;
todo3
在rInput()执行时序识别完成后,调用识别二次过滤器 T;
结果
两个步骤和三个todo全写完了,重新训练防撞训练,测试一下 转29108测试;
29108
回测发现过滤力度太大问题
1
时序过滤器中可以只保留强度过滤,而匹配度过滤可废弃,因为二次过滤要重排匹配度了 T;
2
测得概念识别结果很多,但时序却很少(往往只有低保的4条) T;
2.1 可以把概念识别结果拆分成rAlgs和pAlgs,然后分别过滤,rAlgs的过滤还按20%,但pAlgs改为50% T;
2.2 识别后合并rAlgs和pAlgs二者,赋值给matchAlgs,这样以前的代码都不用改 T;
结果
以上全改完,经回测大致ok,没啥问题,转下表回测并重新训练下防撞训练,如果防撞ok了,可以回归搞觅食;
29109
继续回测防撞训练之前的问题和性能优化
测得1
发现扔木棒v4版本改为一次动画后,太顺畅,往往鸟来不及反应躲避,就撞过来了;
修复: 把扔木棒的速度由5s过屏改为8s过屏 T;
测得2
二次过滤更是用时1.5s,需要优化下;
经查二次过滤慢是因为取距离的ValueInfo慢,取一次4ms,在循环中时累计到1s以上,尽量改到循环外取后性能ok 已修复 T;
测得3
概念识别经常用时1s (概念识别第1次因为无缓存慢,后面有缓存会快些,但仍有些慢);
经查看TCDebug日志,与硬盘Read无关,R次数多或少都慢,比如日志:用时:******** (837) (读:11 写:0);
经边调试边优化,把稀疏码的DataDic等移到尽可能循环外后,性能ok,大概从800ms优化到300ms了 T
测得4
BUG_二次过滤现在先过滤概念,再根据概念过滤时序,会导致(时序结果条数的)不确定性,说明如下 T
说明: 比如: 概念过滤出前50%,但这50%可能正好一条时序都没有,或者正好含了所有的时序;
解决: 改为直接顺着概念新排序,找对应pFo,找够limit条后中止 (比如概念10条,第2条时已经找够30%的时序结果,就中止) T;
结果
本表完善细节,优化性能,修复bug,正式的回测防撞训练转n30p01;
总结: 本节主要针对识别准确度问题,做了二次过滤,并在写完后回测有效; 然后在回归防撞训练前,又做了一些小问题和性能的优化 (参考29109);
,如图,试错训练后也没用,照样飞错方向被撞到;
