qlibtrade时间

Posted 2023-05-05

qlibtrade是一个开源的量化交易平台，它没有固定的交易时间。交易时间取决于所连接的交易所的交易时间。不同的交易所有不同的交易时间，例如，中国股市的交易时间是周一到周五的上午9:30到下午3:00。如果你使用qlibtrade连接的是中国股市，那么交易时间就是按照中国股市的交易时间来进行的。 参考技术A qlibtrade是QuantLib的Python实现，是一种用于金融工程和量化投资的开源工具包。在使用qlibtrade进行量化投资时，需要注意时间的处理。

qlibtrade中的时间处理主要涉及以下几个方面：

1. 时间戳：qlibtrade中使用Unix时间戳来表示时间，即从1970年1月1日0时0分0秒到某一时间点的秒数。

2. 时间周期：qlibtrade中常用的时间周期包括天、分钟、秒等，可以根据需要选择合适的时间周期进行数据处理。

3. 交易日历：qlibtrade中的交易日历用于处理股票、期货等金融产品在交易日和非交易日的价格变化，可以根据实际情况进行设置。

需要注意的是，qlibtrade中的时间处理与具体的数据源和交易策略有关，不同的数据源和策略可能需要不同的时间处理方式。因此，在使用qlibtrade进行量化投资时，建议您仔细阅读相关文档和代码，了解其时间处理方式，以避免因时间处理错误而造成的投资风险和经济损失。 参考技术B qlibtrade 是一个基于 Qlib 的量化交易框架，提供了一系列常用的交易策略和工具，适用于股票、期货、外汇等市场。

在 qlibtrade 中，时间是一个非常重要的概念，它通常与数据的处理和交易的决策密切相关。qlibtrade 中时间通常有两种表示方式：

1. 时间戳（timestamp）：时间戳是一种表示时间的数据类型，通常是一个整数或浮点数。在 qlibtrade 中，时间戳通常表示某个具体的时间点，例如 2022 年 1 月 1 日 00:00:00 的时间戳为 1640995200。

2. K 线数据（k-line data）：K 线数据通常是指一段时间内的 OHLC（开盘价、最高价、最低价、收盘价）数据，也可以包括成交量、持仓量等信息。在 qlibtrade 中，K 线数据通常是按照一定的时间间隔（例如 1 分钟、5 分钟、日线等）组织的，每个 K 线数据包括该时间段内的 OHLC 数据和其他相关信息。

在使用 qlibtrade 进行量化交易时，通常需要根据市场数据生成 K 线数据，并根据 K 线数据进行交易决策。同时，需要注意时区、交易所的开市时间、休市时间等因素，以确保交易策略的正确性和可靠性。 参考技术C 你好，Qlib的代码是以一个比较“松散”的结构，每一个模块都尽量做到可以最大程度的复用。这一点很好支撑我们的量化系统。即能够最大复用它的工程能力，又可以自主发展我们想要的功能。

今天看一下Qlib的投资组合策略。

传统的量化回测策略不同在于，Qlib的策略输出是由模型输出预测好的分数，由这个分数来构建投资组合。

策略的基类是qlib.strategy.base.BaseStrategy

class BaseStrategy:
"""Base strategy for trading"""
def __init__(
self,
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
trade_exchange: Exchange = None,
):
BaseStrategy是一个抽象类，就是定义了一些基础参数。

它的一个子类是ModelStrategy，顾名思义，基于模型的预测来交易的类。

它传入两个参数，一个是模型，一个是数据集。

class ModelStrategy(BaseStrategy):
"""Model-based trading strategy, use model to make predictions for trading"""
def __init__(
self,
model: BaseModel,
dataset: DatasetH,
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
**kwargs,
):
"""
Parameters
----------
model : BaseModel
the model used in when making predictions
dataset : DatasetH
provide test data for model
kwargs : dict
arguments that will be passed into `reset` method
"""
super(ModelStrategy, self).__init__(outer_trade_decision, level_infra, common_infra, **kwargs)
self.model = model
self.dataset = dataset
self.pred_scores = convert_index_format(self.model.predict(dataset), level="datetime")
if isinstance(self.pred_scores, pd.DataFrame):
self.pred_scores = self.pred_scores.iloc[:, 0]
使用model.predict(dataset)生成预测分数pred_scores。

源码中可以看出，qlib实现了两个关于强化学习的策略类，但它们都还没有具体的实现类。

传入重要参数是policy。

class RLStrategy(BaseStrategy):
"""RL-based strategy"""
def __init__(
self,
policy,
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
**kwargs,
):
"""
Parameters
----------
policy :
RL policy for generate action
"""
super(RLStrategy, self).__init__(outer_trade_decision, level_infra, common_infra, **kwargs)
self.policy = policy
还有一个子类，带state和action的翻译器的类。

class RLIntStrategy(RLStrategy):
"""(RL)-based (Strategy) with (Int)erpreter"""
def __init__(
self,
policy,
state_interpreter: Union[dict, StateInterpreter],
action_interpreter: Union[dict, ActionInterpreter],
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
**kwargs,
):
"""
Parameters
----------
state_interpreter : Union[dict, StateInterpreter]
interpretor that interprets the qlib execute result into rl env state
action_interpreter : Union[dict, ActionInterpreter]
interpretor that interprets the rl agent action into qlib order list
start_time : Union[str, pd.Timestamp], optional
start time of trading, by default None
end_time : Union[str, pd.Timestamp], optional
end time of trading, by default None
"""
super(RLIntStrategy, self).__init__(policy, outer_trade_decision, level_infra, common_infra, **kwargs)

self.policy = policy
self.state_interpreter = init_instance_by_config(state_interpreter, accept_types=StateInterpreter)
self.action_interpreter = init_instance_by_config(action_interpreter, accept_types=ActionInterpreter)
当前qlib仅有一个真正的策略实现类：TopKDropoutStrategy，继承自ModelStrategy。

class TopkDropoutStrategy(ModelStrategy):
# TODO:
# 1. Supporting leverage the get_range_limit result from the decision
# 2. Supporting alter_outer_trade_decision
# 3. Supporting checking the availability of trade decision
def __init__(
self,
model,
dataset,
topk,
n_drop,
method_sell="bottom",
method_buy="top",
risk_degree=0.95,
hold_thresh=1,
only_tradable=False,
trade_exchange=None,
level_infra=None,
common_infra=None,
**kwargs,
):
它的核心逻辑如下：

TopK=5，表示持有分数最高的前5支股票；Drop=3，TopK好理解，就是得分最高的前N个，但DropN这个有点奇怪，代码里解释是要提高换手率，这有点不符合交易逻辑，可以把这个设置成零。

图片

它的核心函数是generate_trade_decision，类似传统回测系统里的on_bar。

传统回测系统里的on_bar会自己调api执行这些订单，而qlib只是返回这些order_list，这样倒也简洁。

def generate_trade_decision(self, execute_result=None):
# get the number of trading step finished, trade_step can be [0, 1, 2, ..., trade_len - 1]
其实，这里的逻辑，就是“轮动”策略，传统量化里的动量轮动，我们就是取动量最大的前N名持有。区别在于，根据当前的bar的指标，规则选择，但多支股票轮动最终一定会有一个排序，就是类似这个topK的逻辑。而规则就是模型给出的pred_score。

最后backtest_loop，调用strategy每一步产生交易订单，交给执行器去执行。

with tqdm(total=trade_executor.trade_calendar.get_trade_len(), desc="backtest loop") as bar:
_execute_result = None
while not trade_executor.finished():
_trade_decision: BaseTradeDecision = trade_strategy.generate_trade_decision(_execute_result)
_execute_result = yield from trade_executor.collect_data(_trade_decision, level=0)
bar.update(1)
客观讲，qlib这一块写得不好，也是我打算使用自己的回测引擎的原因。我仔细读过像Backtrader，PyalgoTrade的源码，不知为何qlib重新造了一个逻辑不太一样的轮子。 参考技术D Qlib的代码是以一个比较“松散”的结构，每一个模块都尽量做到可以最大程度的复用。这一点很好支撑我们的量化系统。即能够最大复用它的工程能力，又可以自主发展我们想要的功能。

今天看一下Qlib的投资组合策略。

传统的量化回测策略不同在于，Qlib的策略输出是由模型输出预测好的分数，由这个分数来构建投资组合。

策略的基类是qlib.strategy.base.BaseStrategy

class BaseStrategy:
"""Base strategy for trading"""
def __init__(
self,
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
trade_exchange: Exchange = None,
):
BaseStrategy是一个抽象类，就是定义了一些基础参数。

它的一个子类是ModelStrategy，顾名思义，基于模型的预测来交易的类。

它传入两个参数，一个是模型，一个是数据集。

class ModelStrategy(BaseStrategy):
"""Model-based trading strategy, use model to make predictions for trading"""
def __init__(
self,
model: BaseModel,
dataset: DatasetH,
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
**kwargs,
):
"""
Parameters
----------
model : BaseModel
the model used in when making predictions
dataset : DatasetH
provide test data for model
kwargs : dict
arguments that will be passed into `reset` method
"""
super(ModelStrategy, self).__init__(outer_trade_decision, level_infra, common_infra, **kwargs)
self.model = model
self.dataset = dataset
self.pred_scores = convert_index_format(self.model.predict(dataset), level="datetime")
if isinstance(self.pred_scores, pd.DataFrame):
self.pred_scores = self.pred_scores.iloc[:, 0]
使用model.predict(dataset)生成预测分数pred_scores。

源码中可以看出，qlib实现了两个关于强化学习的策略类，但它们都还没有具体的实现类。

传入重要参数是policy。

class RLStrategy(BaseStrategy):
"""RL-based strategy"""
def __init__(
self,
policy,
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
**kwargs,
):
"""
Parameters
----------
policy :
RL policy for generate action
"""
super(RLStrategy, self).__init__(outer_trade_decision, level_infra, common_infra, **kwargs)
self.policy = policy
还有一个子类，带state和action的翻译器的类。

class RLIntStrategy(RLStrategy):
"""(RL)-based (Strategy) with (Int)erpreter"""
def __init__(
self,
policy,
state_interpreter: Union[dict, StateInterpreter],
action_interpreter: Union[dict, ActionInterpreter],
outer_trade_decision: BaseTradeDecision = None,
level_infra: LevelInfrastructure = None,
common_infra: CommonInfrastructure = None,
**kwargs,
):
"""
Parameters
----------
state_interpreter : Union[dict, StateInterpreter]
interpretor that interprets the qlib execute result into rl env state
action_interpreter : Union[dict, ActionInterpreter]
interpretor that interprets the rl agent action into qlib order list
start_time : Union[str, pd.Timestamp], optional
start time of trading, by default None
end_time : Union[str, pd.Timestamp], optional
end time of trading, by default None
"""
super(RLIntStrategy, self).__init__(policy, outer_trade_decision, level_infra, common_infra, **kwargs)

self.policy = policy
self.state_interpreter = init_instance_by_config(state_interpreter, accept_types=StateInterpreter)
self.action_interpreter = init_instance_by_config(action_interpreter, accept_types=ActionInterpreter)
当前qlib仅有一个真正的策略实现类：TopKDropoutStrategy，继承自ModelStrategy。

class TopkDropoutStrategy(ModelStrategy):
# TODO:
# 1. Supporting leverage the get_range_limit result from the decision
# 2. Supporting alter_outer_trade_decision
# 3. Supporting checking the availability of trade decision
def __init__(
self,
model,
dataset,
topk,
n_drop,
method_sell="bottom",
method_buy="top",
risk_degree=0.95,
hold_thresh=1,
only_tradable=False,
trade_exchange=None,
level_infra=None,
common_infra=None,
**kwargs,
):
它的核心逻辑如下：

TopK=5，表示持有分数最高的前5支股票；Drop=3，TopK好理解，就是得分最高的前N个，但DropN这个有点奇怪，代码里解释是要提高换手率，这有点不符合交易逻辑，可以把这个设置成零。

图片

它的核心函数是generate_trade_decision，类似传统回测系统里的on_bar。

传统回测系统里的on_bar会自己调api执行这些订单，而qlib只是返回这些order_list，这样倒也简洁。

def generate_trade_decision(self, execute_result=None):
# get the number of trading step finished, trade_step can be [0, 1, 2, ..., trade_len - 1]
其实，这里的逻辑，就是“轮动”策略，传统量化里的动量轮动，我们就是取动量最大的前N名持有。区别在于，根据当前的bar的指标，规则选择，但多支股票轮动最终一定会有一个排序，就是类似这个topK的逻辑。而规则就是模型给出的pred_score。

最后backtest_loop，调用strategy每一步产生交易订单，交给执行器去执行。

with tqdm(total=trade_executor.trade_calendar.get_trade_len(), desc="backtest loop") as bar:
_execute_result = None
while not trade_executor.finished():
_trade_decision: BaseTradeDecision = trade_strategy.generate_trade_decision(_execute_result)
_execute_result = yield from trade_executor.collect_data(_trade_decision, level=0)
bar.update(1)
客观讲，qlib这一块写得不好，也是我打算使用自己的回测引擎的原因。我仔细读过像Backtrader，PyalgoTrade的源码，不知为何qlib重新造了一个逻辑不太一样的轮子

转载在Linux下，一个文件也有三种时间，分别是：访问时间修改时间状态改动时间

在windows下，一个文件有：创建时间、修改时间、访问时间。
而在Linux下，一个文件也有三种时间，分别是：访问时间、修改时间、状态改动时间。

两者有此不同，在Linux下没有创建时间的概念，也就是不能知道文件的建立时间，但如果文件建立后就没有修改过，修改时间=建立时间;如果文件建立后，状态就没有改动过，那么状态改动时间=建立时间;如果文件建立后，没有被读取过，那么访问时间=建立时间，因为不好判断文件是否被改过、读过、其状态是否变过，所以判断文件的建立时间基本上能为不可能。

 

如何查一个文件的三个时间呢？

先用下面的命令来建立一个文件
# date && echo "this is file be used test time of file" >filetime.txt && ll --full-time filetime.txt
Tue Aug  4 15:13:44 HKT 2009
-rw-r--r--    1 root     root           39 2009-08-04 15:13:44.000000000 +0800 filetime.txt

 

通过stat filename.txt来查，如：
# stat filetime.txt 
  File: `filetime.txt‘
  Size: 39              Blocks: 8          IO Block: 4096   Regular File
Device: 802h/2050d      Inode: 17          Links: 1    
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-04 15:13:44.000000000 +0800
Modify: 2009-08-04 15:13:44.000000000 +0800
Change: 2009-08-04 15:13:44.000000000 +0800

说明：Access访问时间。Modify修改时间。Change状态改动时间。可以stat *查看这个目录所有文件的状态。

ctime=change time
atime=access time
mtime=modifiy time

 

因为这是一个新的文件（filetime.txt），没做过内容、属性的更改，也没读过这个文件，所以三者（访问时间、修改时间、状态改动时间）的时间是一致的，这时文件的修改时间与这三个时间是一样的，是没有疑问的。

 

1、访问时间，读一次这个文件的内容，这个时间就会更新。比如对这个文件运用 more、cat等命令。ls、stat命令都不会修改文件的访问时间。
2、修改时间，修改时间是文件内容最后一次被修改时间。比如：vi后保存文件。ls -l列出的时间就是这个时间。
3、状态改动时间。是该文件的i节点最后一次被修改的时间，通过chmod、chown命令修改一次文件属性，这个时间就会更新。

 

另个除了可以通过stat来查看文件的mtime,ctime,atime等属性，也可以通过ls命令来查看，具体如下:

ls -lc filename 列出文件的 ctime （最后更改时间）

ls -lu filename 列出文件的 atime（最后存取时间）

ls -l filename 列出文件的 mtime （最后修改时间）

 

在linux中stat函数中，用st_atime表示文件数据最近的存取时间(last accessed time)；用st_mtime表示文件数据最近的修改时间(last modified time)；使用st_ctime表示文件i节点数据最近的修改时间(last i-node‘s status changed time)。

 

 字段           说明                  例子           ls(-l)
 st_atime  文件数据的最后存取时间       read            -u
 st_mtime  文件数据的最后修改时间       write           缺省
 st_ctime  文件数据的最后更改时间       chown,chmod     -c

 

 

在linux系统中，系统把文件内容数据与i节点数据是分别存放的，i节点数据存放了文件权限与文件属主之类的数据。

 

另外，可以格式化输出文件的三种时间，如：

find . -name file -printf "%AY-%Am-%Ad %AH:%AM:%AS"
find . -name file -printf "%TY-%Tm-%Td %TH:%TM:%TS"
find . -name file -printf "%CY-%Cm-%Cd %CH:%CM:%CS"

 

linux的ctime代表的是文件修改时间，如果文件被修改过就很难知道文件的创建时间，在某些特殊情况下，需要查看文件的创建时间，正常情况下查看文件的ctime是无法实现的。可以使用一个变通的方法来实现保留文件创建时间，但是同时也会牺牲一些其它特性。

 

可以在mount文件的时候使用参数-o noatime，来把系统更新atime的特性关闭。使用了noatime参数挂载后，在文件被修改后文件的atime是不会被改变的，使用stat查看到的atime就是文件的创建时间。

如：

# / sbin/mkfs -t ext3 /dev/ram10

# mount -t ext3 -o noatime /dev/loop0 /mnt/foo

# mount

/dev/ram10 on /mnt/foo type ext3 (rw,noatime)

# cd /mnt/foo

# touch filetime1.txt

# stat filetime1.txt 
  File: `filetime1.txt‘
  Size: 0               Blocks: 0          IO Block: 4096   Regular File
Device: 10ah/266d       Inode: 12          Links: 1    
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-04 20:51:32.000000000 +0800
Modify: 2009-08-04 20:51:32.000000000 +0800
Change: 2009-08-04 20:51:32.000000000 +0800

 

# echo foo.ok >> filetime1.txt 
[[email protected] foo]# stat filetime1.txt 
  File: `filetime1.txt‘
  Size: 14              Blocks: 2          IO Block: 4096   Regular File
Device: 10ah/266d       Inode: 12          Links: 1    
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-04 20:51:32.000000000 +0800
Modify: 2009-08-04 20:53:27.000000000 +0800
Change: 2009-08-04 20:53:27.000000000 +0800

 

# cat filetime1.txt 
  foo.ok
#stat filetime1.txt 
  File: `filetime1.txt‘
  Size: 14              Blocks: 2          IO Block: 4096   Regular File
Device: 10ah/266d       Inode: 12          Links: 1    
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-04 20:51:32.000000000 +0800
Modify: 2009-08-04 20:53:27.000000000 +0800
Change: 2009-08-04 20:53:27.000000000 +0800

 

# 通过以上实验可以看出文件的access time 是不变的。

 

接着向下多测试一下.

# vi filetime1.txt

# stat filetime1.txt 
  File: `filetime1.txt‘
  Size: 23              Blocks: 2          IO Block: 4096   Regular File
Device: 10ah/266d       Inode: 14          Links: 1    
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-04 20:55:05.000000000 +0800
Modify: 2009-08-04 20:55:05.000000000 +0800
Change: 2009-08-04 20:55:05.000000000 +0800

 

# chmod 777 filetime1.txt 
# stat filetime1.txt 
  File: `filetime1.txt‘
  Size: 23              Blocks: 2          IO Block: 4096   Regular File
Device: 10ah/266d       Inode: 14          Links: 1    
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-04 20:55:05.000000000 +0800
Modify: 2009-08-04 20:55:05.000000000 +0800
Change: 2009-08-04 20:57:36.000000000 +0800

可见，chmod后，Ctime的变化。

#########################################################

说到这里，大概大家也对在linux下文件的时间有所了解了吧！

那么以下的操作对文件的时间有什么影响呢？

 

操作                        atime        mtime       ctime

----------------------------------------------------------

mv

----------------------------------------------------------

cp

----------------------------------------------------------

touch

----------------------------------------------------------

cat/more/less

----------------------------------------------------------

ls

----------------------------------------------------------

chmod/chown

----------------------------------------------------------

ln

----------------------------------------------------------

echo

----------------------------------------------------------

vi

----------------------------------------------------------

(请大家测试完成这个表吧！！！！做完测试可以给我留言啊！）

##############################################################

 

另外，从kernel2.6.29开，还默认集成了一个relatime的属性。可能是因为在文件读操作很频繁的系统

中，atime更新所带来的开销很大，所以很多SA都在挂装文件系统的时候使用noatime属性来停止更新atime。但是有些程序需要根据atime进行一些判断和操作，所以Linux就推出了一个relatime特性。
使用这个特性来挂装文件系统后，只有当mtime比atime更新的时候，才会更新atime。事实上，这个时候atime和mtime已经是同一个东西了。所以这个选项就是为了实现对atime的兼容才推出的。并不是一个新的时间属性。使用方法就是通过mount -o relatime /dir来挂装目录。