Open
Description
目前全域 OpenRank 和社区 OpenRank 均以自然月为单位进行计算,但也有不少人提出希望可以进一步细化 OpenRank 的计算间隔,以股市为例,股价是实时变化的,而对于股票的长期分析一般可以细化到天。
目前提出一种按照每日进行全域 OpenRank 计算的可能方案,涉及到几个重要的点:
- 全域节点的衰减比例。目前全域 OpenRank 计算中,所有节点无论是否活跃每月都有固定 85% 的衰减,以避免 OpenRank 全域价值的无限增长。如果计算周期是按天进行,那么此时的衰减比例要做一定的调整,可以是 0.85^(1/30),大概是 0.995。即每天所有节点的衰减比例是 99.5%。
- 开发者节点的新增 OpenRank 值。目前全域 OpenRank 计算中,所有新增节点的初值均为 0,需要由开发者节点活跃为网络带来新增价值。目前使用的归一化方法是 sigmod 归一化,横轴平移 44.08,即全月全域所有开发者活跃度的上四分位数均值 88.16 的一半。但如果使用按天计算,这里的参数需要做相应调整。2024 年每日全域所有开发者的活跃度上四分位数均值是 55.38,即横轴平移需调整为 27.69。但这种变化带来的影响目前不可知,体感上而言,这种方式下按天计算的全域 OpenRank 总值增长可能比按月要快,也可能是等价的,不是很确定。
- 工程实现。如果按天计算且与按月计算的结果基本相同,则按天更新是完全可行的,因为按月计算每次计算大约只需要十分钟左右即可完成,而按天计算的网络规模要小很多,速度也会更快。但工程实现方面需要有一些改变,在按月计算中,我们每月计算当月活跃仓库和开发者后,不活跃的仓库和开发者节点也会把衰减结果存回表中待用。但按天计算会导致活跃仓库的数据点很多,如果为每个在当天不活跃的仓库和开发者也存储衰减后的数据,会导致大量的存储浪费和表的扩张。因此需要修改 OpenDigger 中的实现方法,不再存储当天不活跃的仓库和开发者的衰减数据,而是在计算时动态从历史数据中获取。PS. 目前全域 OpenRank 表中正常数据和衰减数据比例大概为三比一。
- 数据说明:目前全域 OpenRank 计算使用自然月数据,而且使用的 UTC 时区,与中国时区有 8 小时的时差。当按月计算时,该时差导致的数据差异是可以忽略不计的,但按天计算时 8 小时的时差占到一天的三分之一,可能会使大家有非常明显的体感差异。当然中国也可能不会,因为差异的八小时为 0-8 时,此时活跃度并不高。但例如美国可能会有比较明显的差异感受。因此需要额外的数据说明来让大家理解这种差异的原因。
解决上述问题后,是有可能将全域 OpenRank 计算更换到按天更新的级别的,当然按天更新会带来较大的硬件压力和开销。
Metadata
Metadata
Assignees
Labels
No labels