TB期权测试框架走通了
测试框架:主边合约888,动态加载期权合约。所有代码写在一个策略里。 策略逻辑如图一。 图二是rm888合约加载期权的开发工作区。 图三是Call信号示例,Call卖出+固定止赢。 图四是Put卖出的多次交易,涉及了3个期权合约。第一次止赢出场。第二次因为虚值合约变成实值合约,防守出场。第三次又开,止赢出场。第四第二次因为虚值合约变成实值合约,防守出场。 图五、六、七是多品种加载的回测工作区,和部分测试报告。 目前,有一个实际的困难,TB加载合约数量最大是200个。期权有非常多的合约,一个品种最起码十个Call、十个Put。如此的话,10个品种测试一期就200个合约了。暂时还没有想到解决方法。
你最后的问题只能做个优化第一步是你目前做到的第二步根据历史Bar只订阅交易所需的3个档期权标的如果已经在期权集中则不用再订阅所有周期内历史bar公用这些期权集标的基本也够用了200个数据源也可以充值扩展的确实有需要的话问题不大
回复:谢谢分享心得。1、我确实在往这个方向琢磨,主连信号出现后,再订阅需要的期权合约。2、这种订阅方式,有个缺点,无法在期权上计算信号。信号只能依靠主连上给出。我这个考虑对吗?2、“所有周期内历史bar公用这些期权集标的”,是指这三个期权合约,从CurrentBar==0跑到最后一根Bar吗?
回复:参考上个帖子我的跟帖我的场景比较简单每个bar只交易1-2个期权遍历所有的bar得到需要交易的期权标的存入数组历史bar很多交易的期权标的是重叠的不重复订阅当然重复订阅也没问题重复的只记一个数据源这样自己设计算法对应到交易期权标的比较方便根据数组一次性一起订阅这样比直接订阅全部期权集少很多
回复:排序必须重新弄一下不然定位有问题的
回复:再捋一遍错了莫怪一种是订阅所有期权集(排序需要修订 有利于快速定位交易标的)会有很多没有发生过交易的期权标的数据源占用200数据源限定第二种是动态的计算只订阅历史bar兼顾实盘状态下需要用到的期权标的数据源可以大幅度减少
回复:我现在short策略是第二种 动态long策略是第一种 静态都加了个参数是否回溯
回复:我看你的策略逻辑还要复杂一些转化为实盘需要处理的细节不少
回复:你这个思路特别好!先把需要的合约先全部计算出来,然后统一订阅。实盘时,有新bar了,看需要再订阅!运行效率高,系统消耗少。