撮合引擎是否可以使用当前Bar Open Price来成交

[merz9b]

请问，在日频率的回测中，如何以当前bar的open price交易？

[wh1100717]

@merz9b

class MATCHING_TYPE(CustomEnum):
    CURRENT_BAR_CLOSE = "CURRENT_BAR_CLOSE"
    NEXT_BAR_OPEN = "NEXT_BAR_OPEN"
    NEXT_TICK_LAST = "NEXT_TICK_LAST"
    NEXT_TICK_BEST_OWN = "NEXT_TICK_BEST_OWN"
    NEXT_TICK_BEST_COUNTERPARTY = "NEXT_TICK_BEST_COUNTERPARTY"

目前有如上几种模式。

之所以没有当前bar的open是因为策略会使用到未来数据，从而影响到回测的结果。

[merz9b]

@wh1100717
比如在NEXT_BAR_OPEN下,我想记录一个订单状态:

context.order_info = order(...)
order_avg_price = context.order_info.avg_price

因为实际撮合是在下一根bar,是不是得第二天才会有order_avg_price?

[merz9b]

@wh1100717

主要想实现一个组合下单:

context.stocks_buy_list = [...]#N个股票,N>20
for stx in context.stocks_buy_list :
    order_stx = order(stx,...)

假设目标是持有20只股票，就需要记录每个订单的状态，停牌、涨停等原因造成订单失败时，继续购买list上下一只股票，直到达到20只股票。

n_filled = 0
if n_filled <=20:
    order_stx = order(stx,...)
    if order_stx.status == ORDER_STATUS.FILLED:
        n_filled += 1
    else:
        cancel_order(stx) 

这么做在current_bar_matching下没问题，但是只能以close price交易。如果在next_bar_matching下，好像就实现不了了，因为当时返回的order_status是pending_new。

在NEXT_BAR_OPEN模式下有什么好的办法？

[handsomu]

order的状态应该是每个handle_bar都会更新的，与matching type没有关系。发单函数返回order Object，可以存在context中，然后每个handle bar检查下订单状态的改变。

[wh1100717]

@merz9b 还有一种方法，使用 signal 信号模式， https://github.com/ricequant/rqalpha/tree/master/rqalpha/mod/rqalpha_mod_sys_simulation

这种方式，会按照您指定的下单价格成交。

#65 中 8. 回测过程中，我们真的需要撮合引擎吗？其使用场景到底是怎样的? 描述了信号模式的使用方式。

然后通过LimitOrder 指定下单的价格。如果是MarketOrder的话，则会直接按照当前bar的close_price成交

[merz9b]

@handsomu

所以可以先全部下单:

context.order_status_record = {}
context.stocks_buy_list = [...]#N个股票,N>20
for stx in context.stocks_buy_list :
    order_stx = order(stx,...)
    context.order_status_record[stx] = order_stx

然后在下一天检查订单状态?

n_filled = 0
for stx in context.order_status_record.keys():
    current_order = context.order_status_record[stx]
    if n_filled<=20:
        if current_order.status == ORDER_STATUS.FILLED:
            n_filled += 1
        else:
            cancel_order(stx)
    else:
        cancel_order(stx)

这样？

[merz9b]

@wh1100717

OK,谢谢。我试下。

[wh1100717]

该模式下，停牌、涨跌停也会被 rqalpha_mod_sys_risk 风控模块控制住的，所以这些您不用担心，只是取消了撮合，而是采取用户指定的价格成交，属于有特殊需求，但自己可以控制避免使用未来数据的用户来使用的。

[dongyi]

这里我还是有点不明白
日级别的回测 handle_bar里 用history_bar取历史数据是取不到今天的, 那么相当于我今天执行回测会根据今天之前的数据告诉我今天有哪些信号, 我应该是可以用今天的开盘价去下单的, 而且看实际运行的trade记录, 如果设置成NEXT_BAR_OPEN 最后的成交价格也是handle_bar那一天的开盘价.

[wh1100717]

@dongyi NEXT_BAR_OPEN 应该是下一个Bar的开盘价，不是当前Bar的开盘价，如果像你说的，按照当天的Open成交的话，就可能是一个regression bug了。麻烦能给出具体的可复现的代码供测试使用吗？ @handsomu 麻烦看一下这个问题~~

[dongyi]

https://github.com/ricequant/rqalpha/blob/master/rqalpha/mod/rqalpha_mod_sys_simulation/matcher.py#L45-L46

就是这里， CURRENT_BAR_CLOSE和NEXT_BAR_OPEN 是取的同一个bar的close和open

我测试代码是自己扩展的数据源，看最后report的成交价跟行情软件比对过是当天的open价，rqalpha的bundle数据和行情软件对不上 我就没测试

[wh1100717]

@dongyi Matcher是根据撮合类型来判断使用什么数据，但是今天的还是明天并不在这里判断，对于当天Bar Close 撮合这种方式是立刻成交的，因此这时候的Matcher 获取的Bar_dict 对应去下单的时间点来说是“当前Bar”
而 Next Bar Open 实际在撮合的时候 已经变成了下一个Bar了

具体你可以看下 match_immediately

https://github.com/ricequant/rqalpha/blob/master/rqalpha/mod/rqalpha_mod_sys_simulation/simulation_broker.py#L35

[wh1100717]

@dongyi 另外 我和 @handsomu 同学测试了，这块的撮合逻辑是没有问题的