ricequant / rqalpha

A extendable, replaceable Python algorithmic backtest && trading framework supporting multiple securities
http://rqalpha.io
Other
5.36k stars 1.61k forks source link

分钟级别的回测事件源不准确 #281

Closed tiandian closed 6 years ago

tiandian commented 6 years ago

在simulation_event_source.py的_get_stock_trading_minutes函数中会生成分钟级别的事件源:

def _get_stock_trading_minutes(trading_date):
        trading_minutes = set()
        current_dt = datetime.datetime.combine(trading_date, datetime.time(9, 31))
        am_end_dt = current_dt.replace(hour=11, minute=30)
        pm_start_dt = current_dt.replace(hour=13, minute=1)
        pm_end_dt = current_dt.replace(hour=15, minute=0)
...

从上面的代码可以看出有如下问题:

  1. 上午9:30分未生成事件, 而是在9:31分才开始生成事件, 这是不准确的, 其实在9:25分时已经生成了开盘价, 9:30分已经具备生成事件的所有信息, 应该生成交易事件.

  2. 上午11:30分生成了事件, 但上午11:30分已经停牌了, 此时不应再发送事件了.

  3. 同理, 下午13:00分应生成事件, 而15:00分不应生成事件.

Cuizi7 commented 6 years ago

rqa 的分钟 bar 数据反应的是过去的一分钟内市场的变动情况,所以在第一分钟走完的时候推送出来是合理的。

hzliu commented 6 years ago

目前并没有对集合竞价部分做处理,所以第一个分钟线是在9:31分

tiandian commented 6 years ago

@Cuizi7 你的解释不能让人满意呀,

在11:30和15:00发送一个交易信号是没法成交的,

这个问题和next_bar 的那个问题一样, 为什么要在下一个bar处理?

ricequant代码我基本上都研究了一遍, 运行速度快, 结构也很合理, 就是这个问题和next_bar的问题的设定和其它量化平台(MindGo/joinquant/...)不同,且不合理呀.

我看过joinquant的文档中的运行时间设定是比较严谨的, 和现实紧密切合, 希望ricequant能和joinquant的文档中的运行时间保持一致. 谢谢!

Cuizi7 commented 6 years ago

bar数据(以及国内市场的tick数据)中不包含逐笔数据,所以不可能(大多数情况下也没有必要)实现和交易所一致的连续竞价撮合逻辑。回测框架中只能对撮合的过程进行抽象,抽象出的模型可能有多种,next_bar 就是其中一种,不一定适用于所有回测,可以不使用。

rqalpha提供了多种撮合类型可供使用。 如果有其他合理的撮合类型欢迎提pr~

tiandian commented 6 years ago

您的解释是无法令人满意, 这个问题和逐笔数据没有任何关系, 也不是要"实现和交易所一致的连续竞价撮合逻辑",
而是在同样复杂度的情况下尽量和实际保持一致, 这个问题只是希望能将分钟往前移1分钟, 以和实际保持一致, 也尽量和MindGo及joinquant等国内优秀的量化平台保持一致, 让rqalpha更严谨。