Tang

关于定投策略的记录(五十三)

试行国债网格后的结论:不适用 一方面数据量很大,计算时间非常长,以树莓派的算力已经无法在交易时间以外同时完成其他计算和网格计算。另一方面目前的方法不太适合做区间段内的网格,如果超出就无效了,所以需要找出比较稳定的波段,在这个波段下进行网格是比较合适的,也就是要用新方法。 所以把1m级别的网格计算停了,保留了120m的计算。还使用日级别的周期来生成网格。 另一个更新: 因为日和周的买卖区间不太均匀, […]

关于定投策略的记录(五十二)

发现了一个算法的BUG 在网格交易过程中发现,1m级别波动下,一次买卖交易后,至90%位置跌幅的次数变多了。 原因是这样:假设从距离90%跌幅位置4次的位置开始买入,当买入第三次后,涨幅超过了最低涨幅,那么下跌位置将回到0,当下跌继续,超过最低下跌幅度时,会重新计算到90%跌幅位置的买入次数,这样前面的两次买入就游离于算法之外了。 看来是时候重新审视一下Cplan算法了。 与问答AI交流,梳理了一 […]

关于定投策略的记录(五十一)

实际运行了1m和120m的网格交易,也许对国债来说,固定价差的网格交易更合适? 具体做法如下:当1m的网格到了合适的位置后,先买入2个单位,然后以买入位置为基准上下划定4个固定网格,这样最多是上下4个网格的波动,120m的网格使用固定价差作为网格单位,上下限总长度为日级的一个网格。因为买入位置都在4格以内,从概率上讲90%以上的概率买入次数不会超过4次,如果超过了就拿着不动,进入下一个日级、周级网 […]

关于定投策略的记录(五十)

继续微小更新。 一、回收FLAG,解决了树莓派死机的问题。找到了死机的原因,一是树莓派的内存耗尽了,通过优化内存回收的方式解决;另一个是树莓派温度过高,增加了一个常驻后台运行的动态测温算法,15分钟一次,根据当前温度动态生成最高温度和最低温度,当温度高于阈值的时候就休息,冷却到低于最低温度的时候再继续进行计算,高低温度差不低于平均温度附近8摄氏度。 因为解决了死机问题,用两个周末扫完了所有的历史数 […]

关于定投策略的记录(四十九)

微小更新。 将所有指数放在一起了,因为有一些指数的存在时间短,所以新增一个“次级指数”的分类;因为目标类型比较多,增加了一个自动选择的方法,选出适合买入的各种日周期、周周期目标,动态形成两个recommend卡片,当日和周周期都适合买入的时候会入选。因为股票类卡片的波动和风险都比较大,所以只有期望值高于当前指数期望的1.5倍时才会入选。 将所有合适目标整合到一起有一个好处,就是能够更直观地比较各类 […]

关于定投策略的记录(四十八)

回收FLAG 涨跌趋势的判定由固定调整到浮动了。有了一个意外的好处,因为很多信息都可以通过新算法得到,反过来直接省掉了后面的计算,不用一个个比对了,得到结果的计算量大幅减少,直接重构了算法w 原理是忽略所有前面的数据,只考虑当前周期的数据,代价是如果想得到全部历史数据,计算量会变大,计算复杂度会比原来的算法多1个次方。 算法分两步。 第一步精简数据,将所有连续上涨或下跌的部分合并,只保留最后的上涨 […]

关于定投策略的记录(四十七)

游戏的确耽误时间w(不 更新了一点点,指数方面,把周数据换成日数据了,因为每天都在更新数据w增加了卡片的周数据作为参考,作为中期数据相对比较准确。同一类卡片可以放在一个配置项里了,配置文件精简了很多。港股产生了第一个零成本单位,居然是B站,波动的确很大。成功建立了H股组合猫鱼H10,目前没跑赢恒指w 从今年这段时间的运行来看,短期数据方面,算法的准确度是100%,不知道什么时候会出现一个坑呢w 9 […]

在家建立NAS版WOW服务器

用我不是矿神的源,下载到了魔兽世界的套件,在家里下载客户端就可以愉快地玩耍了,未来还可以跟孩子一起玩,开心w 接下来使用转发和域名实现公网访问,远程联机也可以实现了,开心w 这里用到了frp,非常好用的转发工具。因为有带公网IP的服务器,以及域名(非必要 ,可以在公网服务器端安装服务端,在家里安装客户端,然后进行转发就可以了。 一、下载安装 首先在公网服务器端安装frp服务器端。在github获取 […]

关于定投策略的记录(四十六)

关于定投策略的记录(四十六)

继续更新,完善Cplan并在长期指标的计算中引入期望值。 将目标分为4类,A股、港股、海外和商品,reit其实也是一个重要的目标,但国内这些时间都太短了,大概还要再观察几年。A股的部分,引入了10年以上的指数,海外的部分,主要参考美股的海外ETF,时间足够长,似乎是那个前阵子在中国亏到上新闻的贝莱德旗下的w港股目标时间少于美股的,用美股的数据。 引入期望主要是为了计算一个单位实际的盈利情况,从实际 […]

关于定投策略的记录(四十五)

继续数据本地化计划w 用NAS计算也许是个错误,计算时总提示过热,还因此自动关了两次机。算法从原来的并发多线程转成分时段分步,还是会提示过热,python的计算效率也很低。所以现在将计算任务交给了树莓派,相对于几千块的NAS,几百块的树莓派似乎更适合干这种体力活w(坏了不心疼(。 借助通义千问编写和修改了很多代码,感觉还可以再重写一下w通义千问给出的代码风格也大不相同,不知道喂了多少奇怪的代码进去 […]