摸索系统的各种机制

逆向思维

利用系统机制的问题

来解决遇到的问题

根据个人摸索的情况

CLOSE等未来只是闪烁的一部分

比较表象且容易被认知

也会让策略编写者把精力都放在价格锁定上（诸如H/L + 回溯 + 逆向计算 并衍生了其他问题）

半成品OnBarClose+SetTriggerBarClose就是这种典型思路

但不得不说

TB的内建机制 已经优于友商

业务逻辑千奇百怪

几无可能提供一套给客户直截了当的解决方案

需要自己根据实际情况去控制

这个思路和在onbar上直接上时间约束有区别吗？从描述看机制是一样的，如果一样，直接上时间约束不就行了？

在我自己的另外一个帖子中

作为程序员的角度

当然希望官方能够重写这种 过时但已优于友商（） 的信号机制

也认为只能开发新版本

否则现有机制的推翻

对庞大的存量量化是毁灭性灾难

甚至对TB系统自身也是个毁灭性灾难

----------------------------------

我给出的建议 只是现有机制下 去解决闪烁问题

https://www.tbquant.net/forumDetail?cur=tbquan&id=12343

解决闪烁问题的历程

断断续续从控制在日内 到 完全解决

每个开发者业务逻辑不同

思路也给了

看自己控制

-------------------------------------------

老师给的例子是有问题的

自己琢磨琢磨

肯定可以完全解决信号闪烁

账户报撤单等成交率就看自己策略包容度了

给你提供一个思路：

自己重构类似onbarclose+SetTriggerBarClose+多图层

可以大胆使用CLOSE/最新价做任何复杂的运算 并实时报单

非常轻松的彻底解决闪烁

除非真实CLOSE最终确实不符合条件（实盘几个月，一周都难得碰到一次，和切片密度有关） 这就是策略包容度等另外一个层面了

解决不了信号消失以后 回测报告和实盘绩效不符的问题

实际上这是一个最大的问题，如果回测报告不真实，那么这个功能可以说就没用了

这个问题很难处理，除非重头再做一套新的机制系统。

这就看策略包容度了

即使信号完全保留具备一致性

账户成交状况的因素太多

只能不断测试报单/成交尽可能等于或优于信号

如果账户最终不成交 回溯依然是不真实的

账户同步及算法交易的出发点也是如此 尽可能的靠拢信号

这是策略包容的另外一个角度 也是逆向思维

不存在完美的机制 不必过于纠结

--------------------------------------------------------

我目前碰到的问题借用这里说一下：

虽然设计目标是无人值守 且 TB理论上提供了

但5个月以来发生了3次服务器宕机问题

周三周四出差2天

周三收盘后服务器未能正常连接

无行情信息所以策略无法正常运行交易

5个月以来

碰到了4次

第一次是系统的阿里云故障

第二次是系统升级当天全面宕机

第三次是前天

第四次不能算宕机

盘中服务器停了15分钟

无

我代码有个闪烁还未除掉，但很难复现，之前开了二十多个品种跑几天才会出来，但现在系统具体限定了交易次数，这就没法继续调试了。能不能放开模拟交易的次数？

以后会推出摒弃信号系统的程序化和复盘功能，这个可以从根源上去除信号闪烁的问题。

但是相应的，开发能力也有更高的要求。

常见的闪烁案例在信号闪烁的专题课里都举过例子了。但是仍然有很多稀奇古怪的信号闪烁方式，这个是穷举不了的。

零基础课程里应该有说过，测闪烁还是需要靠模拟账户快速跑几个信号，一般都能查出来