Skip to content

Latest commit

 

History

History
1062 lines (881 loc) · 59.3 KB

Note21.md

File metadata and controls

1062 lines (881 loc) · 59.3 KB

v2.0版本四测、五测、六测

注:

  1. 本文seem表示part局部匹配;
  2. FC表示决策流程控制缩写;


n21p1 四测: 规划训练

CreateTime 2020.09.01

21011 简化训练步骤
1 直投,右下飞,直投,边吃边飞至右上
2 重启,右投,飞至坚果,吃掉
3 重启,右投,马上饿 (小鸟自行飞到坚果并吃掉);
21012 简化训练步骤-多向版
1 直投,右下飞,直投,边吃边飞至右上
2 重启,右投,飞至坚果,吃掉,右上投,飞至吃,左下投,飞至吃...
3 重启,右上投,马上饿 (小鸟自行飞到坚果并吃掉);




n21p2 反省类比测试-前(deltaTimes记录,触发器,ActYes流程控制等)

CreateTime 2020.09.01

21021 BUG
1 ATHav时序的,deltaTimes和mvDeltaTime为0的BUG (参考21022);
2 将训练第3步右投果识别为M有向果,所以MC时失败,因为C为无距无向果;
3 第3步改成左投,成功识别为无距无向果,但马上饿找到-mv解决方案 (转21024);
21022 BUG1-deltaTime为0; T
示图
总结 修复getDeltaTimes()中多个BUG,现仍为0的情况参考fo.deltaTimes注释
21023 BUG2-MC中mIsC失败;
示图
方案1 将M识别为无向果M[速0,高5,皮0],即可;
方案1解析: 参考20172-方案2 ↓↓↓↓↓;
结果 将第3步改成左投,可成功识别为无距无向果;
方案2 MC中不判断mIsC,而是判断MC二者的absPorts前三条,有交集;
方案2解析: M和C未必是抽具象上下层关系,可能是同级关系,因为后面要执行PM,所以应该广入口,窄修正,所以选择方案2,实例如下:
实例: 奶奶听到孙女给同学打电话,说想吃治愈系水果,所以拿一根香蕉给孙女;
1. 孙女:"我不要吃香蕉";
2. 奶奶:"你不是要吃水果吗?"
3. 孙女:"是治愈系水果,香蕉不是"
4. 奶奶:"什么是至于是水果?"
5. 孙女:"就是甜的"
6. 奶奶:"把香蕉切开,拌了点白糖,然后递给孙女;"
解析 1. 例中,治愈系水果是C,那根实际的香蕉是P,香蕉是M,水果是S
2. 显然,MC非抽具象关系,但奶奶认为M和C都是S,所以就拿给孙女;
3. 当孙女反馈后,奶奶又在PM中,对香蕉进行特征修正,加了白糖 ↓↓↓↓↓;
实测 实测显示,MC是同级,但并不是有共同抽象,而是有共同具象;
复现 按着21012训练,第3步改为右投,即可复现;
21024 BUG3-P+的解决方案为负价值;
示图
21025 最后一帧isOut=true,导致反省类比未触发的BUG; T
日志
说明 在21012训练后,第三步没飞过去,而是直接原地空吃;
分析 PM未发现SP,所以理性评价通过,未飞是正常的;
问题 但下帧输出(即空吃)后,却没有触发反省类比;
原因 经查,行为输出时isOut=true未触发ActYes,也没触发Finish;
解决 使行为输出时,触发Finish,从而递归至base,即demand时可以触发ActYes;
复现 按着21012训练,即可复现;
总结 将流程控制fo.finish直接转至fo.actYes后解决 (参考流程控制Finish方法的注释version-20200916);
21026 ActYes时,决策系统还在继续P+模式继续递归着; T
日志
说明 在21012训练后,ActYes时,当前任务还在反复思考F14方案;
分析 估计是流程控制问题,新输入又尝试解当前任务,未判断其ActYes状态;
解决 在ActYes中的解决方案(如F14),继续等待,而不是反复决策;
结果 将isOut=true时的情况,先改为ActYes,等输出行为后,再改为Finish即可;
21027 反省类比算法中,明明PM有四个特有码,却取到0个; T
问题 经查,取fo.subAlg.justPValues是没有码的;
解决 经查,短时记忆取fo.subAlg.subAlg.justPValues才可以;




n21p3 特征模块迭代计划

CreateTime 2020.09.10

  在v3.0版本时,我们将支持多码特征,从而对特征的类比抽象有所支持,本节提前进行些记录,特征的类比,不仅包含特征间纵向类比,也包含稀疏码间的横向类比,从而形成更多样的特征。而感官算法上只需像以往所述,将稀疏码集输入即可。

  前段时间有个新闻,是说把视觉接到听觉脑区,照样工作,但需要一定的时间来慢慢形成。

  这里其实显示出皮层的可塑性,说明视觉算法输入时我们只提供稀疏码信息,然后通过组合方式得出模糊特征,再通过互相类比得到抽象特征。以此得到外形等特征信息(组分)。

  这与当下的概念和时序模块非常类似。但目前代码上还是仅支持单码特征,在3.0版本时,面向现实世界的迭代中,再对特征模块进行多码支持与完善。所以本节暂止,v3.0时再续。

我语音中只是举例说明,比如说咱们两个有个算法,得出稀疏码仅为:"灰度值",

  • 示例: 解释下图中我们如何认知飞机特征,以及识别飞机头;
    • 注: 本问题和图来自@张仙_用友提问;
* 假设:现感官视觉算法中:
  1. 灰度0-1表示白到黑;
  2. xy表示坐标;

* 第一次看到飞机得到最初的稀疏码可能为:
x0,y1,灰1
x2,y1,灰0
x1,y1,灰1
x2,y2,灰0
x2,y3,灰0
x1,y2,灰1
x2,y3,灰1
x2,y4,灰1
...

* 通过色值类比发现:
x0,y1,灰1
x1,y1,灰1
x1,y2,灰1
x2,y3,灰1
x2,y4,灰1

* 通过坐标类比发现 (外形):
灰1路径为: 原点-> 右1 -> 上1 -> 右上1.4 -> 上1

* 当第二次,再发现飞机时,可能有所变化,比如:
飞机2的灰1路径为: 原点-> 右1 -> 上1 -> 右上2 -> 上1

* 两个外形,再进行类比,发现,抽象飞机3的路径为:
原点-> 右1 -> 上1 -> 右上1.4/2 -> 上1

* 当描述飞机头时,发现,路径为:
原点-> 右1 -> 上1

* 注:
  1. 当然,你也可以在此基础上,支持RGB,支持模糊匹配,支持亮度,等;
  2. 就是这种,最最基础的视觉算法,通过类比后,发现各种各样多样的特征;
  3. 以上多个稀疏码组成一个字典,多个字典的数组,为一帧输入;

问题:来自群友@error的问题,视觉z轴的表征方式?
回答:通过两种方式来回答:

  1. 视角差方式:
    • 左眼视角为=8,右眼视角为=6,得出视角差2
    • 再通过差值匹配记忆中的数据,获取z轴的距离值,如视角差=2时距离为3米。
    • 注:3米是后天概念的匹配描述,距离的表征数据仅是视觉差2而已。
  2. 视觉差方式:
    • 左眼视觉为:[x1y2color6 x2y2color8 x3y3color10]
    • 右眼视觉为:[x4y2color6 x2y2color8 x0y3color10]
    • 根据外形特征C=[color6,8,10]过滤视觉差为L=[x3,x0,x3]
    • 再根据视觉差来估算距离,如视觉差L表示的为0.5个C长度的距离;
    • 如3d电影中C为汽车外形时,视觉差L表示距离为0.5个汽车长度,即2.3米左右;
  3. 说明: 以上只是简答,因为此问题涉及到感官稀疏表征向特征层,概念层的两个宏微隔层,要细讲述内容太多。
  4. 可理解为找规律的筛子,根据某些共同点,找出异同点并求差值。




n21p4 反省类比测试-后(生成SP,抽象SP,与PM应用SP)

CreateTime 2020.09.18

21041 SP的抽象,往往是方向而不是距离 未构成BUG T
分析 因为只有8种方向,却有数百种距离,导致方向较容易抽象;
待办 1. 实测下,是否果真如此,即方向更易被抽象,而距离不行;
2. 分析下,此问题如何解决?
分析 在SP中,无非是S或P有明确的,也有模糊的,各举一例如下:
1. S更明确例: S为:pos5,6,7 P为:pos0,1,2,3,4,8,9,10
2. P更明确例: S为:dis7,8,12,29,311 P为:dis0
3. SP一样例: S为:dir1,2,3,4,5,6,7,8 P为:dir1,2,3,4,5,6,7,8
说明1: 只有S中fuzzy匹配到结果,才会到P中尝试找出较近的目标值进行修正;
说明2: 所以S与P是明确还是模糊不再重要,因为说明1的运行,不受其影响;
总结 问题中,距离与方向是否更容易抽象,并不重要,因为无论是否抽象,都在考虑范围,并且抽象强度也不那么重要,因为最终匹配时,是以fuzzy理性的模糊匹配的,这导致更接近的值排最前面,而不是强度最强的;
21042 BUG_同一fo执行多次触发,并反省类比 T
说明 在测试中,发现同一个时序,进行了多次触发,并反省类比;
如图
修复 经查共有两个地方会导致重复触发反省类比,改动如下;
1. 为OPushM多次触发导致,对OPushM防止第二次触发即可;
2. 行为输出调用Finish,推进流程控制也会触发反省类比所致,取消调用即可;
总结 最终,改为仅由OPushM中,调用一次推进流程控制与反省类比;
21043 BUG_demand取到重复解决方案 T
如图
解决 共有4处,修改了3处;
1. demand转移时,仅执行一次,而不是原来的一帧瞬时一次; T
2. 新解决方案后,直接返回true中止,因为流程控制会接管此后流程; T
3. ActYes的解决方案,加入到不应期,避免重复行为化; T
4. ActYes的demand不再尝试新解决方案; 暂不改,如饭快好了,也先吃些零食




n21p5 四测:规划训练2

CreateTime 2020.09.21

21051 因得不到P,PM测试受阻 T
示图
说明 在21012的训练方式中,发现只反省类比出S,而没有P,所以需改进训练方式;
分析 因为21012训练的第1,2步中,正价值都是反射反应触发的,并无主动行为输出;
所以,从未以mv+触发反省类比,所以也就未生成P;
这形成了没P就没法成功,没成功过就不会生成P的死循环;
解决 方案1: 在训练第2步时,尝试点击马上饿吃掉0距果,而不是摸嘴触发吸吮反射;
方案2: 在正向反馈类比中,构建P; 需分析理论模型支撑,不能轻率这么做
结果 暂采用方案1,规划出21052的训练方案,见下表,方案2等待后续需求明确再说;
21052 新规划训练步骤
1 直投,右下飞,直投,边吃边飞至右上
2 重启,右投,飞至坚果,马上饿,右上投,马上饿,左下投,马上饿...
3 重启,右上投,马上饿 (小鸟自行飞到坚果并吃掉);
21053 BUG-反省类比SP触发类型BUG和决策循环未停止的BUG T
示图
说明 1. 明明吃到坚果了,却反省类比S,而不是P的问题;
2. 明明吃到坚果了,却没有抵消demand,也没有中止决策循环的问题;
结果 经查,deltaTime单位为s,但在生成触发器时却当做ms来计算了,修改后好了;
结果 关于决策循环未停止的问题,确是按ms算触发时任务善未抵消导致,修后好了;
21054 反省类比P中出现距6的BUG T
示图
说明 如图所示,距6是上一位置,当前位置是距0,但反省类比P却在以距6处理;
分析
结果 如上图,将_Hav中改为新帧优先即可 (参考_Hav.200928注释);
21055 反省类比P的内容经常为空的BUG T
示图
说明 经测反省类比中,常常因justPValues都被不应期掉,导致反省类比放空炮;
复现 依21052训练至第二步,第二小轮,点击马上饿时,即可复现;
分析 在PM中,发现三个独特码,都在无需PM时转为Finish,致其为不应期状态;
示图
解决 代码中取excepts取错了,错成了左边的部分,所以导致反省的内容经常为空;
21056 在PM中,取AIKVPointer.pointer导致闪退 T
示图
总结 PM中,Alg与Pointer类型错乱导致,修复后ok;
21057 第3步训练时,进入死循环的BUG
示图
分析 1. 向小并不重要,可能是PM经历太少导致 (因为P只有2条);
2. 查下为什么会进入死循环 (训练至第3步,可复现);
3. 似乎_GL太容易转到_Hav了,导致明明该是PM修正的问题,却变成了各种_Hav后乱飞 (猜测未实证);
21058 P中有距21的BUG
示图
说明 如图,在P中有距21,导致距21无需修正,事实上距21显然不能直接吃;
分析 P在反省类比中构建,所以需通过反省类比,分析距21的P是从何而来的;
21059 PM独特码不在P中的BUG T
示图
说明 如图,因为mIsC时,隔了层,所以M和MAtFo并非同层,导致"距0"要从M具象找;
结构图
结果 优先从C中找距0,即解决;
2105a 同一解决方案的重试问题 暂绕过问题
说明 同一解决方案,首次PM时无SP,但反省类比后有了SP,却未能及时重新PM
示图
分析 解决方案1: 可以通过反省结果SP与justPValues独特码比较,如有同区,则说明发现了问题,则重置现执行中解决方案(从demand.sub删掉即可,只要不在不应期,自然会再次被取到,重执行),而不是使其失败;
绕行方案2: 直接重启之,重训练第3步,相当于下次遇到任务时SP再生效;
结果 方案1彻底但麻烦,先不做,执行方案2;
2105b PM中独特码方向_转移GL问题
示图
分析 多进行各方向吃食物的训练,即可使乌鸦知道,方向右不影响吃;
方案 1. 训练第2步,多训练一些方向,尤其"右";
2. 使P有了各方向后,再训练第3步,看是否可以依各方向飞过去吃掉坚果;
结果: 似乎训练后,并没有得到;
2105c PM修正距离飞错方向的问题 转至21081
示图
分析 调试下,在PM转移GL后,是否将方向右上的概念节点,传进去参与联想glFo;
方案 将protoAlg传递到getInner1Alg()中,用于以下用途;
1. 以使其筛选出合适的glAlg(如右上果,变近的经验);
2. 帮其筛选合适的fo(如右上飞近右上果);
实施 以上两条,需要实测得出答案 转至21081;
2105d 发现内类比时序中_总是缺了最新一帧数据 T
说明 内类比缺最后一帧如:P:F698[A178(向↙,距22..),A1(飞↙)]
分析 mModel在赋值protoA和matchA后及时存至mModelManager中;
总结 修后正常P:F698[A178(向↙,距22..),A1(飞↙),A179(向↙,距13...)]




n21p6 反省递归

CreateTime 2020.09.24

21061 思考支持结构化循环-反省递归
示例 1. 战败,反省敌方机枪手太厉害
2. 因为我方狙击手未干掉对方机枪手
3. 想到前两天,狙击手打篮球手受伤了
4. 通知狙击班长将篮球框拆掉;
说明 例中,类似决策循环,做了反省循环,并最终找到原因;
分析 广义上说,找出原因,是一个任务,其实这就是在做决策循环而已;
但确实可以在下次打战前昔,通知狙击手不允许打篮球,即SP起作用;




n21p7 特征模块迭代计划2

CreateTime 2020.09.28

  本节记录,源于群友@陈国冬 交流话题:关于“线”是否是先天算法。

21071 我的回答
主张 我并不反对先天“线”的作法,只是我一贯主张感官算法越简单通用越好
回答 为单位,通过色值和点间相对位置来解决线的问题。
说明 关于这一点主张,我从17年一开始就是如此主张,至今未变。不仅线,如果我们现在认为“外形”是一个不可拆分的感官算法,那么外形算法也是可以被接入的。
优缺分析 只是越复合度高的感官算法,其通用性就越受限,这种受限越来越明显时,我们自然会去想办法迭代之,使之更通用。
v2.0做法说明 当下认为什么是Ok的,就先这么写,只要理论上原则定了,模型的方向定了,其实后面大几率也就是这么个路子去迭代。
现有接口设计 但是我要说明的一点是,HE的内核在模型设计的接口上,已经具备了支撑现在做法,以及下版本做法。即:HE的感官算法,只有一个要求,即转为稀疏码格式。
例1 如果我们将味觉算法,中的甜和咸的分区标识,都定为a23b,那么HE理论上就无法分辨甜和咸,因为二者的分区标识是一致的。
例2 HE的听觉算法,假如只能够转换20000hz以下的声音,那么理论上,超过这个频率的声音,HE是听不到的。
例3 HE的听觉算法,假如只能分辨出细粒度为10的声音,那么10005hz和10008hz对于HE而言就是一致的。
v3.0做法计划 一组稀疏码输入为模糊,后以类比抽象来确切化,与概念与时序一致




n21p8 四测:规划训练3

CreateTime 2020.10.19

21081 getInner1Alg支持多向飞行问题 转至21082
示图
说明 在getInner1Alg中,判断A185与A186间mIsC关系显然不成立;
分析 1. 因内类比仅针对protoFo,导致内类比的结果都太具象;
2. 不够抽象所以mIsC失败,而构建抽象后,如Fx[左下果,向左下飞],即可;
方案1 构建GL抽象时,判断protoAlg的抽象matchAlg是否符合,符合也关联到GL;
方案2 考虑增加多识别结果 (暂不增加尝试解决);
结果 选定方案1,并转至21082处理;
21082 内类比GL太具象问题 以下至21115都围绕此问题进行迭代,已解决
示图
说明 构建GL抽象时,判断protoAlg的抽象matchAlg是否符合,符合也关联到GL;
分析 即使改成A185向抽象找matchAlg,共同指向GL距小,依然不行;
因现在matchAlg=A8(速高皮),A8太抽象,必须先类比A185和A186得到Anew;
方案 Anew介于抽象和具象间,先TIR_Alg.Seem到A185,后外类比解决;
暂停 暂停此处内类比迭代,转至n21p9做Seem识别迭代,并触发外类比得到ANew;
问题 可否不建立Anew和GL的关联,而从Anew.conPorts中分析其是否GL稳定?
答:不行,太麻烦,直接以Anew抽象指向GL的方式更好,即提前归纳学习好;
代码 综上问题,所以我们对内类比GL时,将GL延伸到protoAlg.abs中;




n21p9 迭代TIR_Alg

CreateTime 2020.10.21

在21082中,发现必须先做TIR_Alg.Seem迭代,才可以产出不过于抽象或具象的Anew节点,所以本节以此需求对TIR_Alg迭代;

21091 需求分析与代码规划 T
示图
主说明 每次识别,改为产出两个结果:1最大全含,2最模糊相似;
次说明 黄色的支持,对随后MC中判断mIsC有用;
步骤 1. 根据A186识别,TIR_Alg.Seem,取到A185;
2. 外类比A186&A185,得到A66;
3. 再下次A187时,最大全含就成了A66,而非A8;
关联 1. 对于全含的,直接进行抽具象关联;
2. 对于相似的,先类比A1A2,再使A1A2关联至absA3;
21092 TODO:识别迭代计划MutilMatchResult:多识别结果
1 无论是TIR_Alg还是TIR_Fo,只要将相似的seems(相似度排序)前limit条返回即可,全含的会排在最前面,非全含的也会在相对后面一些,然后都进行外类比,从而即保证旧抽象的加强,也保证新抽象随时浮现;
结果 TIR_Alg已完成,TIR_Fo以后再说;




n21p10 迭代getInner1Alg

CreateTime 2020.10.21

TIPS: 当网络中某信息不知道应该延伸到哪些节点时,那么类比的结果就是其边界;

21101 迭代分析 T
示图
说明 问题1: 是否构建A2和A66&A67的关联;
问题2: 如何最终输出F1/F2;
分析 getInner1Alg仅输出alg,且输出后会relateFos尝试跳转,故无法仅输出f1/f2
回答 第1步,可以将A2与A66&A67关联;
并构建A66&A67被fo引用关联,以下用A66举例说明步骤:
第2步,使A66有fo接收 如F6[A66,飞↘,A66];
第3步,使F6与GL时序关联 如F3[A66,飞↘,A2距小];
代码 1. 先到内类比中写第1步,再分析第2,3步 转至21102;
21102 尝试用内中外类比,解决21101第2,3步问题 转至21115
说明 在21101中第2,3步缺fo,根据时序识别找到seemFo,然后内中外类比可解决;
步骤 1. A1:A2=>A66以及A8和A66的关联由TIR_Alg完成;
2. F1:F2=>F4由内中外类比完成;
使用 3. getInner1Alg中,A66和A8判断mIsC成功,取回A66;
4. 返回_GL后,取A66.refPorts,得到F4,无太抽具象问题;
5. 返回_GL后,判断F4.GL抽象中,只有距小,没有距大,稳定性佳;
21103 GL节点具象指向太多 T
说明 比如,各种方向飞行的具象都有,非常混乱;
分析 因为GL节点去重了,所以导致具象指向太多;
方案 方案1:GL时序首位,增加A66,或者方案2:GL节点不去重;
解决 选择方案1,在GL时序首位,增加A66;
总结 已完成,由TIR_Alg内中外类比分别完成了,类比构建A66,且加到GL中;




n21p11 迭代内中外类比

CreateTime 2020.10.28

在21102中,我们尝试使用内中外类比,来解决GL太抽/具象的问题,本节将围绕此问题展开,重点与HE现有做法相结合,分析怎样迭代比较好;

21111 内中外类比网络结构分析 转至21113
现状
说明 1. 旧有内中外类比,其实是在类比F3 仅针对range进行类比(缺fb);
2. 如果改为F1:F2,则会多余出前后辍;
方案1 改为F1:F2方式,步骤如下:
1. 剔除当前时序(如F1),前后辍多余部分;
2. 根据剩下的content_ps,分别索引找到refPorts: R集合
3. 根据F3取conPorts: C集合;
4. 对R和C集合取交集,并按照稀疏码命中数,计数;
5. 按命中数排序,取出mostSeem最相似的,做为F2;
6. 对F1:F2剔除前后辍后的部分,做类比,并得出结果absF4;
7. 将F4的range+GL,构建成F5 (GL抽象时序),与F4关联;
说明 1. 此方案其实是重新执行了TIR_Fo,只是有GL的限定条件;
2. 此方案能够有效得到F4,即不太抽具象的时序,并且,F4应该会包含A66;
取seem类比时,可以延伸到概念->稀疏码中做相似判断;
方案2 以当前GL具象指向的protoAlg为索引,进行assFo查找,转至21113;
21112 已发与未发分裂模型 & 评价器与类比器的关系
已发与未发 1. 未发生的时序,识别后,用来做评价 (向性:左下) (如反思);
2. 已发生的时序,识别后,用来做类比 (向性:右上) (如正向反馈类比);
评价与类比 二者共同点是都是bool对比;
二者不同点是类比是找规律,评价则是判断是否继续;
21113 内中外类比迭代方案2 T
简介 以当前GL具象指向的protoAlg为索引,向seemAlgs逐个进行assFo查找;
旧做法
说明 对range倒序逐个取refPorts与GL.refPorts取交集,作为assFo外类比;
新做法
说明 对protoAlg的seemAlgs逐个尝试与GL.conPorts取交集,有效则取其fo作为assFo外类比;
步骤 1. 将TIR_Alg中,seemAlgs返回成数组 (所有局部匹配排序后的结果); T
2. 将内中外类比,改为新做法; T
3. 将内中外类比中protoAlg与seemAlg的抽象absA,指向glAlg转向21114;
21114 内中外类比迭代之_将BackConAlg集成到innerFo中 转移21115;
简介 在21113中,已将内中外类比迭代至v2,但步骤3中,仍有些尾活,由本表来做;
示图
说明 如图,用glFo:assFo外类比,有以下问题:
1. glFo中不包含backConAlg,所以需单独做backConAlg:protoAlg=absA3;
2. absA3所在时序,也需单独处理 (其实根本就缺这个fo);
方案 1. 将backConAlg放到glFo中,即range+backConAlg+glAlg;
2. 1.根据glAlg向glFo联想; 2.再向下分别与backConAlg.refPorts和seemAlg.refPorts取交,取得两个conFo; 3.再分别截出range+backAlg部分; 4.并进行类比,得出absFo; 5.再抽象指向glFo;
3. 将内类比构建中,加一个range+backConAlg的中间fo,并标记为GL类型;
4. 将glFo改为range+backConAlg (即方案3的中间fo直接替代glFo);
分析 方案1改动较大,但一劳永逸 30%;
方案2太麻烦,且第1步性能就不好 0%;
方案3无性能问题,且改动也不大,但无法区分中间fo和glFo的区别 20%
方案4改动中等(有改有简化),无性能问题,可以考虑 50% (选定,转至21115);
21115 内中外类比迭代之_将BackConAlg集成到innerFo中 T
简介 上表选定方案4,本表对此画示图模型代码规划;
示图
说明 如图,GLAlg仅负责始索引,其余部分全由backConAlg自行关联 (更理性);
构建
说明 图中黄框内,构建了gl类型的absFo,及末位类比构建absAlg,且指向glAlg;




n21p12 神经网络迭代计划

CreateTime 2020.11.05

在以往的Net设计中,分为横向五模块,纵向抽具象,但是这种分模块的方式,其实是为了前期方便开发的方式,之前我们也有过概念嵌套或者时序概念化的迭代想法,其实都是在尝试去除模块分隔,本节针对此展开进行迭代计划,但v2.0中,暂不做真实的代码实施;

21121 Net迭代计划
1 根据hebb理论,同时输入的(新),可直接打成组,即横向组分;
2 根据hebb理论,同时识别的(旧),类比后打成组,即纵向抽象;
模块 此表中,将完全抛弃网络模块,来分析网络的两种关联关系动态构建网络;
模块 此网不限模块数,可支持概念再组合概念(概念嵌套),如:香蕉有果肉和皮;
过滤 hebb像一个天然的过滤器,一层层的过滤着网络产生抽象组合;
混合 此网可不严格区分fo和alg,在混合中只是对元素间生物钟间隔有否区分;
控制 此网络更简单,而非更复杂,因为只需要更简单的控制器来控制;
向性 此网络仅有两个向性;
概念 据以往笔记概念嵌套其实也是一对多的关系,即香蕉抽象为:"果肉,果皮",即香蕉的再组合用absPorts实现 (当不区分横纵向后,这非常自然) 如下图:;
界线 模块间界线模糊了,即同时AFVP混合存在,如[A我,F画出,V更红的,P红色];
特性 模块各自的特性:P特征是同区码组,A概念是特征组,F时序是先后;
组分 最自然的组分(时间):P同区,A同时,F不同时;
抽具 最自然的抽具象(空间):用类比对信息间筛出共同点,并抽象;




n21p13 好奇心

CreateTime 2020.11.07

以往多次记录好奇心,今天群友@1815628171刘伟 问到好奇心的工作原理,所以更新一下;

刘伟 人类好奇的机制是什么?
好奇是想找到"未知"的答案,而其驱动力,就是对找答案的价值追求,与找到答案后的价值变化;
而往往这种未知,都依赖外界由感观输入新的认知来完成,所以向外界去探索就成了解决好奇的惯用方法;
说白了,由价值驱动决策,由决策驱动行为 (好奇心驱动);
好奇和AI系统本身的运行,是同一套东西,只是出发点不同,价值迫切度不同,导致我们对其意义不明确,才会对它疑问很大;




n21p14 五测:规划训练

CreateTime 2020.11.07

多向飞行训练,内类比GL太具象问题,导致飞行方向杂乱问题已经解决,所以本节再次回归到测试训练中,因为本次改动了TIR_Alg(),内类比构建器,内中外类比,getInner1Alg()等,改动中等,不过会影响到诸多流程,所以另起进行第五轮测试;

21141 新规划训练步骤4
1 直投,右下飞,直投,边吃边飞至右上
2 重启,右投,飞至坚果,马上饿 右上投,飞至坚果,马上饿...
3 重启,右上投,马上饿 (小鸟自行飞到坚果并吃掉);
21142 坚果在手,吃完还右飞BUG T
说明 训练至第2步,点击马上饿后,还会右飞一下;
分析 解决方案为:F145[A1(吃1),A3(飞→),A1(吃1)],所以吃完,还会右飞;
解决 TIR_Alg识别matchAlg在21091改为仅全含,而没有seem,导致常为空,而TIR_Fo时有判断这个非空的逻辑,所以导致未执行外类比,直接将判断非空的代码去掉即解决;
21143 0距果马上饿不直接吃的BUG T
说明 训练至第2步,点击马上饿时,发现决策未成功执行;
示图
分析 如图,在_Hav中,mIsC判断失败,导致F47直接失败;
解决 将mIsC中,兼容cIsM,即可;
21144 价值预测不工作BUG T
示图
说明 训练第1步,TIR_Fo总由Fx识别到Fx+1->{noMv},使正向反馈类比工作异常;
分析 猜测是识别到内存中某新时序内类比生成的时序?需调试Fx+1来源;
解决 1. Fx是MatchAFo,Fx+1是ProtoF,将二者不应期掉,不能互相识别自己;
2. MatchAFo构建时,未兼容partA_ps,导致末位是protoAlg而不是partAlg,而末位在时序识别中作为索引,所以导致识别失败,使之兼容partA_ps后恢复;
结果 已可正常识别时序,并外类比,构建出F14[A8,吃]->{mv+};
21145 0距果马上饿不直接吃的BUG-mIsC不稳定 T
说明 21143类似,不过此处是在第2步,已有几个方向是正常的,到左投时才不行;
示图
调试 经调试,有时A8:A135为同级有共同抽象,有时为A8:A413有共同具象;
分析 抽象度的多样性如A133(速高皮),A8(速高距皮),导致很难精准对应mIsC;
分析
方案1 采取多全含识别; T
分析: 虽然全面改掉问题,但改动较大,不过迟早要支持,改动如下:
1. 在多全含识别后,要分别支持与protoAlg进行抽具象关联; T
2. 也要用多个mAlg构建多个mFo吗? 暂不予支持
3. 在_Hav中,支持分别对matchAlgs判断mIsC通过; T
方案2 在mIsC时,M支持partAlg_ps而不止是matchAlg;
分析: partAlg_ps涉及太广,带来不确定性,与熵减原则相背;
优点: 此种方式改动小;
缺点: partAlg_ps非常长,导致mIsC通过率太高,尝试面感觉太宽;
综合 先选方案1,不过仅做改动1和3,暂不支持2;
21146 BUG_PM修正不必修正的码
示图
说明 如图: 在PM中,对经207进行修正,其实是不需要修正的;
分析 1. 从图中可见,S数1,P数3,两者中,都有,所以得出修正是正常的;
2. 所以导致此BUG的原因在于S和P不够抽象,即经历太少;
方案 1. 制定更多训练步骤,使S和P在外类比中变的更加抽象;
21147 BUG_PM修正GL失败时,会直接否掉当前解决方案 T
说明 在PM修正单条GL失败时,会直接取下一个解决方案,导致当前方案没怎么试就弃疗了;
分析 PM修正GL失败时,其实可以再尝试relativeFos获取alg,而不是直接整个否掉;
方案 在PM修正GL失败时,使_Hav继续relativeFos获取alg.cHav;
代码 对PM返回bool改成三个回调:failure,success,notNeedPM,来应对不同逻辑;
21148 BUG_ATPlus数总为0的BUG T;
示图
说明 无论怎么训练,P数总为0;
分析 以前训练时是有P的,但具体以前什么时候训练的,什么情况都忘了;
方案1 查以前代码分支,找出P非0的情况下的代码逻辑;
方案2 查现在的架构,查出为什么没生成P;
方案3 训练决策行为吃,解决饥饿问题,以使之触发正向反省类比,生成P T;
规划: 先测试到getInner1Alg中找到relativeFos,飞到坚果吃掉,从而生成P;
训练记录: 顺着第2步,远投飞过去后,发现识别为A8,马上饿,直接吃掉,并反省类比P,看起来一切正常;
结果: 按着上述步骤训练,发现正常构建了P;
方案4 正向反馈类比正向反省类比统一,使之更多的被执行;
结果 通过方案3暂已修正P数为0的问题,此问题暂止;
21149 PM修正不必修正的码2
示图
说明 该BUG与21146一致,但这次有复现方式,可调试性更高;
复现 根据21148的方案3训练记录过程进行训练,并观察第二步飞至坚果后的,坚果方向,设为DirectionX,然后第3步DirectionX投,马上饿,应该可以复现 (如此操作后,未复现);
2114A PM该修正的未修正 T,不算BUG
示图
2114B energy足够时的决策循环中断BUG T
示图
调试 当第1条value.finish成功时,再调用第2条valuePM转移失败时,未继续流程导致;
解决 将failure回调后流程补齐 (补成AlgModel永不言败,一直传给_Hav,直至其自报失败);
代码 1. 将AlgModel改为永不言败流程; 2. 将_Hav中加上不应期处理,防止死循环;
流程
说明 从A开始做PM处理,除了本次涉及改动部分外,其它说明直接看图即可;
1. 本次改动仅在最终失败时,即图E1,失败时总会到E1,并且E1添加了不应期功能;
2. 本改动主要使E1到A之间完成循环,不至于决策循环中断;
2114C 反省类比S后决策循环中断BUG T
说明 训练复现步骤说明:
1. 21141第2步中,马上饿,此时S=空 & P=空,导致无需修正;
> 输出掉,触发正向反省类比,得到P(向,距0,经,纬)
2. 21141第3步中,马上饿,此时S=空 & P=(向,距0,经,纬),导致无需修正;
> 输出,空吃吃不到,触发反向反省类比,得到S(向,距27,经,纬)
问题 3. 此时发现,反省类比S后,未能继续决策循环,而是另起了一个解决方案;
调试 经查,反省类比S后,调用了FC-Failure(Alg),所以另起了解决方案;
结果 将反省类比S后,改为递归调用FC-Begin(Alg)即可继续递归Alg (参考21161);
追加 经测并未修复,因为整个fo已完成,所以只是用demand调用了反省类比S(根本没法调用到同级Alg递归),此时无论是同级或上级递归,都无法回溯到subValueModel,不必纠结于此,转N21P17继续训练;




n21p15 规划决策

CreateTime 2020.11.26

说明 规划决策是指,先对任务进行计划,再付出行动; T
曾经 原本老版本的决策系统,本来就是半规划性的,即将决策递归完,才会付出行动;
现在 但后来改成了实时外循环方式,即现在的方式;
规划 支持完全的规划决策,即对输出改为挂起到某场景下,进行计划性输出;
举例 比如1: 回家路过小卖部买醋; (其中情景为:回家路过小卖部,计划为:买醋);
比如2: 打篮球,拍一下,等球弹回来,再继续
比如3: 饿了,午饭快好了,躺在沙发上等待一开饭,就冲过去吃;
分析 广义来看: 其实我们每一次决策,都有规划的影子;
分析前提: 一般情况下,规划决策发生在当前条件不满足,而条件在未来会满足的情况下;
分析结尾: 即我们在ActYes状态下,等待条件满足时,再继续推进任务;
结论 从三个例子来看,HE目前本来就是支持规划决策 (ActYes) 的,所以不需要迭代;




n21p16 流程控制-整理递归方式

CreateTime 2020.11.28 参考2114B,2114C,TOR类注释-递归说明

21161 本节用于整理FC递归方式
源由 源于2114B和2114C两个BUG,本节对递归方式进行整理;
正文 将递归分为同级递归上级递归:
示图
同级 当单轮评价失败时,先向同级递归;
> 即调用_Hav_GLTOP+新解决方案,用不应期再取下条;
上级 当同级全失败时,再向上级递归;
> 即调用FC-Failure: V递归到A,A递归到F,F递归到Demand;




n21p17 继续五测

CreateTime 2020.11.28

21171 新规划训练步骤5
1 直投,右下飞,直投,边吃边飞至右上
2 重启,右投,飞至坚果,马上饿 右上投,飞至坚果,马上饿...
3 重启,右投,马上饿 (没有S,所以原地空吃);
4 重启,DirectionX投,马上饿 (其中X为,小鸟习得P中的方向)
21172 找不到GL飞行经验的BUG T;
示图
说明 如图,训练第4步时,发现明明训练过飞,但却找不到任何GL经验;
调试 1. 经调试getInner1Alg方法,发现传入的参考pAlg确实是向→节点;
2. 查联想到的try_getInnerAlg结果,却并未将向→排在前在 参考21115;
结果 在21175中,将absAlg和glAlg构建关联后,问题解决 (参考21175);
21173 找不到GL飞行经验的BUG-方案1 转至方案2;
方案1 建议从识别开始解决gl无法找到问题,即能够达到的最抽象优先,进行GL启发联想;
比如: 将右果识别为:(速,高,向→,皮)果,而不是(速,高,皮);
问题 如何判断稳定性,比如飞行,其实与方向较稳定相关,但我们为何要根据方向启发呢?
答: 肯定是从"抽象"找稳定性,右果右飞变近,被抽象了,即为稳定;
答: 根据右果右飞变近来重新设计训练方式,以使之稳定,再改此BUG;
终: 21115示图训练方式是没问题的,只是目前有BUG而已,转方案2;
21174 找不到GL飞行经验的BUG-方案2 转至方案3;
方案2 边制定解决方案,边代码改动并调试,以避免再次发生改了半天,结果训练时才发现是无效的;
ALG部分
说明: 在ALG部分依上图进行联想,然后打印出来,看效果是否稳定; 废弃,21115图正解
问题 上图中,有两个原则性问题:1.强度排序存在实时运算问题,2.稳定性应从抽象中获取;
21175 找不到GL飞行经验的BUG-方案3; T
方案3 此方案从21115图中,调试查找原有代码的bug,而不是进行迭代;
调试1 查下为何372图中的glAlgCon_p这么具象;
答: 因为内类比本来就是用protoFo来完成的,但21115彩图中的absAlg却没有找到;
调试2 查下372图中glAlgCon_p与参照A77,都不构成mIsC关系的原因,及改之;
答: 因未找到absAlg,所以glAlgCon_p都是最具象节点,而具象与具象间很难mIsC成立;
代码 1. 考虑将参考A77改成matchAlgs,因为除了识别前,别的地方不建议使用protoAlg;
疑问 2. 调试下,内中外类比是否因partAlg_ps总是最新一帧而导致未执行;
答1: 本来algB就是最新一帧,所以partAlg_ps参数没问题;
答2: 但内中外类比确实似乎未执行,需调试之后,得出答案;
可视
解决 经测,内中外类比中,构建absAlg时,并没有与glAlg构建关联导致,改后好了 (参考21115)
21176 找不到GL飞行经验的BUG2 T;
示图
说明 在21172BUG修复后,glAlg.conAlgs中有了absAlg,但依然不全,如图只有A93,没A78;
方案1 从训练方法上先着手;
比如多次训练右投,右飞,然后断点看是否会构建右果glAlg的抽具象关联;
训练
说明 经训练调试,内中外类比构建的确实太抽象,但方案1训练构建右果有效;
结果
转移 1. 本节内中外类比构建的GL结果,是下节稳定性问题的前提,转至n21p18;
转移 2. 根据方案1调整训练步骤,并转至21191;




n21p18 GL理性评价

CreateTime 2020.12.07

v2.0五测中,getInnerAlg中,我们如何判定稳定性? (比如:右果右飞近,而不是无向果向飞近),增加理性反思,将是好的处理方法;

  1. 本节对于理性反思的支持,主要是集中在对稳定性问题的处理上,且与"感性反思"相对;
  2. 抽象是相对确切的,但却不一定是稳定的,所以依靠抽象得出稳定性是不可取的;
  3. 反思的场景,往往是正思嵌套下的子场景,比如当前游戏手柄场景下右击是左行;
21181 方案1: 理性反思分析 T
向性右 理性反思中,由概念向着时序进行匹配,如:右果右飞总变近;
代码 右果.refPorts右飞.refPorts,取交集,总能预测到果变近;
触发 是发生在getInnerAlg中就理性反思?还是在行为输出时才理性反思?
草图
结果 转至21186,最终方案为:未发生时理性评价;
21182 方案2: GL反省类比与评价 T
简介 现Hav稳定性就是由反省类比和SP来解决的,而在GL上,也可以延用此方法;
步骤 1. 在GL行为输出后,触发反省类比时,进行大小符合预期的判定 T本就支持;
2. 从PM评价TOValueModel的SP是否稳定,稳定时才决策继续;
结果 转至21186,最终方案为:未发生时理性评价,
21183 代码规划1: getInnerAlg部分 T
1 将relativeFo改为逐个返回 T
2 并加上不应期except_ps T
3 并且判断glConAlg必须在末位时,才有效,在getInnerAlg中发现>> fos: F90[A100,A271] == _-2147483600_0 (其实A100应该在末位才对) T;
21184 代码规划2: 流程控制部分 T
1 为GL返回结果做流程控制 (输出行为时,要走ActYes流程) T本来就有;
2 为GL返回结果做流程控制 (Failure时/ActYes.ATSub时,要递归过来继续GL);
3 为RelativeFos调用Fo.Begin然后调用Action._Fo T;
21185 代码规划3: 反省与理性评价部分 T
1 ActYes反省类比触发后,要判断是否GL修正有效/符合预期 (并构建SP);
2 OutterPushMidd中,当完成时,要转到PM_GL()中进行理性评价 (以对比是否需要继续修正GL) T无需GL评价,继续由原Alg评价来支撑;
3 PM中,SP要对抽象中也考虑 (冷苹果不能吃,是因为冷的不能吃);
4 在CommitOuter中,对符合GL变化的algModel进行保留,用于反省类比时 T本来就有相关代码;
结果 1通过OPushM解决; 2.参考OPushM代码注释流程说明; 3.转至TODO4;
21186 代码规划4: GL反省类比 & 未发生理性评价 & 已发生PM理性评价 T;
原做法
新做法
说明 如图,原GL决策流程(红色)不变,新增GL反省类比(蓝色) T本就支持;
分析 此处理性评价分为: 已发生和未发生;
1. PM判断GL是否需修正 (已发生);
2. getInnerAlg判断GL是否能修正 (未发生);
代码 本次,主要针对进行迭代三个部分:
1. GL反省类比 T本就支持;
2. 未发生GL理性评价,针对空时序(hnglFo.range_ps为0)的ATSub时; T;
3. 已发生PM判断GL是否继续修正 T;
21187 方案转变: 反省类比迭代转调试 T暂未发现问题
示图
说明 上图为反省类比旧有代码模型图 (参考20205);
分析 看起来,本来就已经是支持GL反省类比的,因为图中有照顾到VAF;
调试 只需要调试一下,在HNGL的Fo反省类比时,能否在GL修正后JsF正常工作即可;
21188 方案转变: 反省类比迭代转支持空SP T
说明 根据21187所示,本来反省类比就支持GL,所以重新分析本节GL稳定性问题;
分析 要分析GL稳定性,就分析导致不稳定的原因;
本节训练为: 抽象中发现坚果什么都不用做会自己变近;
而并不会变近,所以应形成S,因为什么都没做,所以只能形成空S;
方案 在反省类比支持构建空SP,以使之帮助getInnerAlg中判定不稳定性;
结果 转21202,在反省类比中对空spContent构建空spFo;




n21p19 调整训练步骤继续五测

CreateTime 2020.11.28

21191 新规划训练步骤6
表中X为小鸟习得P的方向
1 直投,右下飞,直投 (边吃边飞至右上)
2 重启,右投,飞至坚果,马上饿 右上投,飞至坚果,马上饿 (各方向都训练下)
3 重启 X投,飞至坚果,摸嘴吃x3 (内中外类比抽象出X向果)
4 重启,右投,马上饿 (没有S,所以原地空吃);
5 重启,X向投,马上饿
21192 GL联想,抽象glAlg被引用0条的问题 T
示图
说明 在内中外类比构建absAlg时至少被glFo引用了1次,但在此处联想却是0条参考21115;
分析 示图首行代码中,取glConAlg.refPorts,错写成了glAlg.refPorts;
结果 改glAlg为glConAlg后,问题解决;
21193 GL距小经验中,都没有飞行行为的BUG T
示图
说明 如图所示,训练至第5步时,联想到的结果,却没有一条是需要任何飞行的;
调试 经查,内中外类比明明构建了F79[↖飞,↖果],但却GL联想时,联想不到;
修复 在修复21195后,此处自然好了,估计是21195的BUG所致;
结果 如上图,BUG已在21195中修复,但联想结果在第2个Item第4条,所以转21182;
21194 GL联想时,左上果的refPorts中没有距小时序 T
示图
调试 调试发现,在内中外类比的fo:[左上果,飞]往往与assFo:[右果,飞]相差甚远,导致其抽象总是无向果createAbsFo:[无向果,飞],而没左上果;
分析 而assFo是根据partAlg_ps索引所得 (参考21113);
分析2 A169源于parts联想assFo后的内中外类比构建所得;
一旦有了A169,就可以以matchs中的A169,为启发联想assFo;
parts构建A169->联想matchs才有效,所以parts和matchs都需支持;
todo1 所以21113联想assFo方式改为:先part触发,后match增强,二者各取三条;
分析3 调试测得,取交集时,会使原有part或match的匹配度有序被打乱;
导致总是与并不那么匹配的assFo进行内中外类比;
todo2 使交集保持有序,即可;
结果 修复todo1和todo2后,BUG恢复;
21195 内中外类比构建的时序,取不到的BUG T
示图
说明 如图,前脚刚构建,后脚就联想不到;
调试 经调试发现node.refPorts取mArr反序列化后为arr类型,导致无法新增关联;
结果 将refPorts,absPorts,conPorts改为必返mArr类型后解决;




n21p20 六测

CreateTime 2020.12.24

  在n21p18中,GL理性评价本来就是支持的,而上次测试被卡在getInnerAlg获取到空HNGL,所以本次六测继续五测时的情况,对空SP进行反省类比支持与getInnerAlg中未发生理性评价支持,并测试其训练过程,改掉BUG(改测改边改训练)。

21201 六测规划训练步骤
1 直投,右下飞,直投 (边吃边飞至右上)
2 重启,右投,飞至坚果,马上饿 右上投,飞至坚果,马上饿 (各方向都训练下)
3 重启,右投,马上饿 (没有S,所以原地空吃,反省得到P方向X);
4 重启 X投,飞至坚果,摸嘴吃x3 (内中外类比抽象出X向果)
5 重启,X向投,马上饿
21202 反省类比未支持到空SP的问题 T
示图
说明 按着21201训练至第5步后,发现取到的空GL时序触发了反省,但反省未构建空SP (参考21193图3中的空GL结果);
代码 构建空SP,就涉及到构建content_ps为0的时序;
结果 将反省类比中spContent为0时,也构建spFo,改后测试正常;
21203 距小和经小的GL联想结果一样的问题 T
示图
问题1 如图在联想GL距小/经小时,其结果竟然一致;
分析1 说明在构建GL时缺失了ds的判断 (因为ds被ATType替代,导致了BUG);
结果1 经查,并无此问题,巧合而已 参考21115;
问题2 无需行为化才对;
结果2 因为经历少,恰巧这位置附近只有S,多反复训练几次第4步即可;
21204 GL修正有效时却反省类比得了S而不是P的问题 T
示图
说明 如图,A4左飞变近,但OPushM后,继续A157时ActYes,反省类比了S;
分析 图中可见,A111虽然变近了,但与A157是无法对比的,而应与其base比较;
调试 怀疑是在OPushM时,与A157进行了GL相符对比,而非base导致BUG;
实测 发现在OPushM中GL判断时,waitType判断为ATLess错误,导致对不上号;
结果 将waitType由baseFo为准判断后,问题修复;
21205 F21[吃,L]不长记性 T
说明 如21204图中F21,在每次训练时,都会重新空吃,然后再失败;
分析 失败时已经构建了空S,但未发生理性评价,并未对此生效;
分析 将未发生理性评价中,判断range为0的准入条件去掉;
结果 仅保留 (hngl节点否则F14也会不通过 & 空S)两个条件即评价不通过;
21206 OPushM后继续PM后独特码异常 T
示图
说明 如图:新的独特码为距16,而旧有同区码应废弃掉,且独特码原顺序保持不变;
结果 在OPushM继续PM前,重算P-C/M,从而重新赋值JustPValues,改后ok;
21207 PM中P数总只有2条以下的BUG T
说明 明明训练了许多方向的飞行,但F14&A8的P数却只有2以下;
问题 这导致修正GL的不确定性增加,经验未被完全利用,如下:
如: 8个方向都训练过,但P只有右,而左坚果会被认为左应该被修正成右才行;
分析 仅2条,连8个方向都覆盖不了,又如何训练飞向各种方向呢?
调试 经查,在pm_GetValidSPAlg_ps()中最多支持limit=3条;
结果 将limit改成100,返回了足够的P经历,经测ok;
21208 PM中P中有距大于0的问题
示图
说明 如图,P中有距>0的,导致距离31变成了无需要PM修正;
分析 疑是第5步训练成功后反省类比构建的,当时连续飞,短时fo中是有距>0的;
方案1 以更近的元素为主,比如最后一个元素肯定是距0;
方案2 反省类比进行外类比,将更确切的P找出来;
21209 经混用了距的S经验问题
示图
说明 训练至第5步,反省构建空S的,居然都作用于了;
2120A 偶发性S导致其相近都PM评价为否的问题 T 完成1,未完成3,转移4
说明 比如,经历了经384S,那么383很容易在PM中匹配到,并判评价不通过;
方案1 治标1: 分析SP的抽象,把S的关联强度考虑进来,那么强度底的参考性底;
分析1 方案1更简单可操作 转至n21p21-值域求和;
方案2 对multiAlg识别结果,都做SP评价,得出更综合的稳定性;
分析2 方案2改动太大,且跑题(跳出V到A解决了) 暂不选用;
方案3 治标2: 更多的P触发,来动态修正错误第一印象的问题;
分析3 可从非主动行为输出触发P反省类比 (如正向反馈类比),来解决之;
方案4 治本: SP再综合,经验再多,也是量变,质变是抽象; (转至22021);
2120B BUG1:GL修正飞反却没有更新独特码 & BUG2:GL修正飞反不长记性T;
示图
结果1 BUG1在使OPushM中将不符合GL的变化也重赋值到独特码,并继续PM后解决;
分析2 BUG2在构建节点时,同样的sames抽象会去重,导致S节点压根没生成;
结果2 在构建节点时,absPorts中不同ATType时,不进行去重;




n21p21 SP场景和值域求和

CreateTime 2020.12.29

以往PM评价中,仅对相近性delta(值更接近)排序,但在实际训练测试中,发现这种方式不足用,因为S和P可能是交织的,都接近怎么办?偶发一次导致接近但这种偶发性导致评价一边倒怎么办参考2120A?本文重点针对此问题,对SP进行值域求和,来迭代PM理性评价;

21211 SP的场景 (宏观)
概念 SP的场景是指其所作用到的时序;
比如 0距果可以吃,翅膀疼不能飞,翅膀疼能睡觉;
21212 SP域 (微观)
简介 SP域决定其稳定性,作为稳定性的判断标准和修正GL方向;
示图
说明 1. 各方相邻组成单队; 如:[S1,S2],[P2,P3,P4];
2. 只与相邻单队进行争夺; 如:[P1]和[S1,S2],[S1,S2]和[P2,P3,P4]
3. 同值时求和; 如:S4和P4
4. 单队以最有利为主; 如:[P2,P3,P4]单队中,左以P2为主,右以P3为主;
21213 值域求和图
示图
说明 如图示,我们对S值域和P值域求和,得到紫色;
1. 紫波在上的部分为S,在下的部分为P;
原则 在HE中,只有网络的始(稀疏)终(价值)可以参与到求和运算,此处为始;
21214 代码规划 T
1 写SumModel模型,支持当前x轴值,和类型S/P两个属性; T
2 写lastGroup和curGroup两个组,来比对; T
3 从两组中分别找出最具竞争力的两个成员 (详转21215); T
4 取交点,生成SumModel并收集作为结果; T
21215 找最具竞争力成员算法 T
示图
说明 如图,规律为找出角度最陡峭的,两端点为结果;
21216 值域求和评价有误 T
示图
说明 训练至21201-第5步时,发现上图中BUG;
结果 发现值域求和算法中将Alg当成Value来处理了,导致没法正确运行,改后ok;






TODOLIST

TODO STATUS
1. 在生物钟触发器触发时,判断下outModel是否有根(在demandManager下) T
2. SPAlg节点中的稀疏码是否应有序?比如,距离显然帮助解决问题强度要>方向 (参考21149,暂时不考虑先测着);
3. 2020.12.18: 决策流程控制的可视化,用来实时调试决策流程的神器;
4. 2020.12.07: PM中,SP要对抽象中也考虑 (冷苹果不能吃,是因为冷的不能吃);
5. 2021.01.04: 用正向反馈类比触发->反省类比 (参考2120A-方案3);