vn.py官网
开源量化社区
Member
avatar
加入于:
帖子: 7
声望: 0

接口中ticker的成交量为

tick.volume = float(d["volume_24h"])

而 BarGenerator中合成bar中交易量的合成方法为:

volume_change = tick.volume - self.last_tick.volume
self.bar.volume += max(volume_change, 0)

这里可以看出,使用的是交易量累加的方法,在期货市场这样是很正常的。但对于24小时运行的数字货币市场却是行不通的,数字货币市场中tick的volume_24h并不是前边tick的交易量加上当前tick的交易量。volume_24h 其实是前面tick的成交量减去24h前tick的成交量加上现在tick的成交量。这里就会导致bar的成交量计算完全是不准确的。
另外:

# Filter tick data with less intraday trading volume (i.e. older timestamp)
        if self.last_tick and tick.volume and tick.volume < self.last_tick.volume:
            return

这里为了忽略无成交的情况,做了剔除。而对于24小时制的数字货币,这里的意义就成了当前tick的成交量一定要大于24小时前从last_tick中剔除的t成交量。这样的情况肯定很多的,导致一直return,剔除tick数据,最终导致bar的合成中ohlc的数据也不准确了。

Member
avatar
加入于:
帖子: 3027
声望: 174

这个过滤的问题我们已经在最新的dev里改回了之前的基于tick.datetime的过滤方法,会在下个版本更新的

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

xiaohe wrote:

这个过滤的问题我们已经在最新的dev里改回了之前的基于tick.datetime的过滤方法,会在下个版本更新的
成交量的计算问题有分析吗,对于数字货币算法上是存在问题的

Member
avatar
加入于:
帖子: 3027
声望: 174

可以去github上提个issue,我们会处理的

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

这个确实有问题,虽然最新的版本已经将tick.volume < self.last_tick.volume去了,但是volume的计算是完全不准的
请问这个github的case id多少?

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

沪公网安备 31011502017034号