vn.py量化社区
By Traders, For Traders.
Member
avatar
加入于:
帖子: 7
声望: 0

首先,将 rqdata 保存到 sqlite 时,对rqdata 的日期做了特殊处理,减了1分钟,也就是说时间为 10:00:00的数据其实是10:00:00 到 10:01:00的ohlc价格,这个是前提

再看 BarGenerator 的 update_bar 函数,它会将最新的 bar 的数据更新到 self.window_bar 中,假设此时传到 update_bar 中的 bar 的时间为10:00:00(注意这个bar实际表示的价格是10:00:00 到 10:01:00之间的),这个bar 的 ohlc 价格会先更新到 self.window_bar(合成1小时时,此时这个window_bar要表示的是9点的数据) 中,之后代码中再判断当前bar与上一个bar 的小时是否相等,如果相等表示这个window_bar完成,这是不是有问题了,这个windows_bar其实用到了未来数据了(就是10:00:00 到 10:01:00的价格)?还望回答一下,谢谢!

description

Administrator
avatar
加入于:
帖子: 2453
声望: 103

BarGenerator只负责K线的聚合功能,回测时下单数据的撮合是由回测引擎内部的逻辑负责的,严格遵循T时刻委托,只有T+1时刻之后才能撮合的逻辑,所以并不会有未来函数问题。

这里的last_bar,是上一跟收到的1分钟K线数据,而不是合成过程中缓存的K线数据

Member
avatar
加入于:
帖子: 7
声望: 0

用Python的交易员 wrote:

BarGenerator只负责K线的聚合功能,回测时下单数据的撮合是由回测引擎内部的逻辑负责的,严格遵循T时刻委托,只有T+1时刻之后才能撮合的逻辑,所以并不会有未来函数问题。

这里的last_bar,是上一跟收到的1分钟K线数据,而不是合成过程中缓存的K线数据

这里就有一个问题了,就是此时的 window_bar 其实包含了 此时刻 bar 的数据的,也就是说 window_bar 是 1小时零1分的 K线了,并非 1小时的

Administrator
avatar
加入于:
帖子: 2453
声望: 103

并不是,因为上一个小时线也是从同样位置开始分割的,小时线里包含的还是60根分钟线,想不明白可以自己加个计数器打印出来看看

Member
avatar
加入于:
帖子: 7
声望: 0

用Python的交易员 wrote:

并不是,因为上一个小时线也是从同样位置开始分割的,小时线里包含的还是60根分钟线,想不明白可以自己加个计数器打印出来看看

哦哦,对,确实还是 1 小时长度的,只是小时的分割并非按照正常时间的 00 分到 60分, 而是 01分到下一个小时的01分,感谢!

© 2015-2019 上海韦纳软件科技有限公司
备案服务号:沪ICP备18006526号-3