数据到6.11号预测可以到6.11，为何交易明细只能到6.10

[benduofen007]

你好作者，有一点比较困惑的是，根据观察，CN的交易数据是到2021年6月11号的，预测的结果也是到6.11号，但是交易明细和持仓信息没有到6.11，到6.10就结束了。
按照真实的使用场景，假设今天是6.11，6.11下午交易结束了，交易结束后获得了最新的6.11股票数据，这时需要知道明天怎么买入卖出，6.12的交易操作怎么获得呢？
非常感谢可以抽出一点时间答疑

[1eunght]

Similar problem. After we dumped the newest data from Jqdata into .bin files and tried to test, the prediction only ends on "2021-06-11". The transaction details are also weird.
Noticing that the v2 Yahoo CN data also updates to 2021-06, I wonder is it possible that the dump_bin.py is set to use the date of Yahoo CN v2? Therefore, the prediction aborts because of the truncated data or process? If that is the case, how to modify the scripts to make predictions?
Thanks a lot!!

同问，使用jqdata的最新数据并dump为bin文件后，预测的结果同样只到2021-06-11，查看交易明细结果都是异常的。
留意到Yahoo的CN数据同样是更新到2021年6月，有没有可能是dump_bin.py有设置使用Yahoo的数据日期，因此在dump过程中数据截断了？如果是的话，应该如何设置呢？
感谢作者的解答！！

Screenshot

[zhupr]

你好作者，有一点比较困惑的是，根据观察，CN的交易数据是到2021年6月11号的，预测的结果也是到6.11号，但是交易明细和持仓信息没有到6.11，到6.10就结束了。 按照真实的使用场景，假设今天是6.11，6.11下午交易结束了，交易结束后获得了最新的6.11股票数据，这时需要知道明天怎么买入卖出，6.12的交易操作怎么获得呢？ 非常感谢可以抽出一点时间答疑

@benduofen007 Hi，
持仓信息到6.10的问题已经在这里修复了(236ab6e#diff-0bfa3d82b4c66a0a5c04a89164a40cbd981b4ced02151a75af6286f48f4c1367L73), 把代码更新到最新重试下看看是否正常：

• git clone https://github.com/microsoft/qlib.git
• cd qlib && python setup.py install

对于下个交易日怎么操作，可以参考这个：#722 (comment)

[zhupr]

Similar problem. After we dumped the newest data from Jqdata into .bin files and tried to test, the prediction only ends on "2021-06-11". The transaction details are also weird. Noticing that the v2 Yahoo CN data also updates to 2021-06, I wonder is it possible that the dump_bin.py is set to use the date of Yahoo CN v2? Therefore, the prediction aborts because of the truncated data or process? If that is the case, how to modify the scripts to make predictions? Thanks a lot!!

同问，使用jqdata的最新数据并dump为bin文件后，预测的结果同样只到2021-06-11，查看交易明细结果都是异常的。 留意到Yahoo的CN数据同样是更新到2021年6月，有没有可能是dump_bin.py有设置使用Yahoo的数据日期，因此在dump过程中数据截断了？如果是的话，应该如何设置呢？ 感谢作者的解答！！

Screenshot

@1eunght Hi，
jqdata的数据不能直接更新到Yahoo CN数据上；因为Yahoo数据做了一些操作(除以第一天的close)，可以使用这个脚本把jqdata的数据append到Yahoo CN数据上: https://github.com/microsoft/qlib/blob/main/scripts/data_collector/yahoo/collector.py

• python collector.py normalize_data_1d_extend --old_qlib_dir <yahoo cn qlib data> --source_dir <jqdata csv> --normalize_dir <jqdata normalize csv> --region CN --interval 1d
• python scripts/dump_bin.py dump_update --csv_path <jqdata normalize csv> --qlib_dir <yahoo cn qlib data> --freq day --date_field_name <date> --symbol_field_name <symbol> --exclude_fields <symbol,date>
  具体参考: https://github.com/microsoft/qlib/blob/main/scripts/data_collector/yahoo/collector.py#L954

不建议把两个不同数据源的数据合并到一起，因为复权算法可能不同；建议使用同一个数据源的数据

[1eunght]

@zhupr
我没有用Yahoo的数据，只用了jqdata。问题与楼主的相同，并已经通过更新代码解决了。非常感谢！

[benduofen007]

更新代码后

qlib/qlib/backtest/utils.py

Line 117 in 125922b

return self._calendar[calendar_index], epsilon_change(self._calendar[calendar_index + 1])

self._calendar[calendar_index], epsilon_change(self._calendar[calendar_index + 1])回测报错IndexError: index 3995 is out of bounds for axis 0 with size 3995 ，end_index 可能大于了len(self._calendar)，是否可以修改类似下面的逻辑：
end_index = calendar_index + 1
if end_index >= len(self._calendar):
end_index = len(self._calendar) - 1
return self._calendar[calendar_index], epsilon_change(self._calendar[end_index])

[zhupr]

更新代码后

qlib/qlib/backtest/utils.py

Line 117 in 125922b

return self._calendar[calendar_index], epsilon_change(self._calendar[calendar_index + 1])

self._calendar[calendar_index], epsilon_change(self._calendar[calendar_index + 1])回测报错IndexError: index 3995 is out of bounds for axis 0 with size 3995 ，end_index 可能大于了len(self._calendar)，是否可以修改类似下面的逻辑：
end_index = calendar_index + 1
if end_index >= len(self._calendar):
end_index = len(self._calendar) - 1
return self._calendar[calendar_index], epsilon_change(self._calendar[end_index])

qlib数据中有个day_future.txt，表示未来一年的交易日；可以利用这个文件来解决这个错误，在获取calendar的时候指定future=True： D.calendar(future=True), 这个bug在这里修复了：#751

[github-actions]

This issue is stale because it has been open for three months with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days