【策略】大盘蓝筹策略,收益竟然可以这么惊人!

2024-02-18 12:10

本文主要是介绍【策略】大盘蓝筹策略,收益竟然可以这么惊人!,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

  • 前言
  • 因子选择
    • 无择时单因子eps_ttm
    • 无择时单因子margin_stability
    • 无择时三因子eps + margin_stability + circulating_market_cap
    • 择时后三因子
    • 市值的影响
    • 运行时间的影响

前言

使用聚宽提供的因子看板写了个三因子策略,比单因子收益有所提升。聚宽因子使用eps_ttm和margin_stability,克隆之后可以修改这两项测试其它因子,还可以加入其他因子,应该还有优化的空间。最后一项是市值因子,选大市值。感觉聚宽处理过的的因子还是不错的,去极值和标准化省了不少事儿。

因子选择

为什么选择这两个因子,原因很简单,每股收益肯定越高越好,但是公司不一定能做到持续的高收益,所以在选出前25%高收益的列表后,在这个列表里再选出收益最稳定的前25%。最后经过对比发现,市值大的公司要强于市值小的,有人可能会问为什么不选小市值更有成长性的,因为首要顾虑是盈利的稳定性,小公司抗风险能力差一些,稳定性自然也差,所以按照市值排序选择最大的五只。关于市值的影响后面还有探讨。
下图为单因子与三因子在最近十年的收益对比,可以看到明显差别,均未择时情况下,单因子最高才2倍多,而组合策略最高达到过6倍多。而且三因子策略与择时信号可以很好的结合使收益大幅提高。

无择时单因子eps_ttm

在这里插入图片描述

无择时单因子margin_stability

在这里插入图片描述

无择时三因子eps + margin_stability + circulating_market_cap

在这里插入图片描述

择时后三因子

在这里插入图片描述

市值的影响

1.在详细查看持仓后发现一个现象,就是这个策略会长期持有茅台,所以我想看看策略的收益在多大程度上依赖茅台,因为我不想这个策略是无意中过拟合买入茅台的策略,于是进行了不含茅台的对照实验。筛选方法是前两项因子不变,再选择市值第2-6名的股票,因为茅台在这段时间内市值基本上都是排第一的。

eps+ms不变,市值选择2-6位,择时后结果如下:
在这里插入图片描述
可以看出首先茅台确实提高了策略的收益,但是去除后的收益没有下降太多,说明茅台(即最大市值股票)的影响力有限。

2.接下来思考这样一种情况,如果选择的股票违规造假,出现明显利空,而上季度财务指标还没来得及变化,因子没有变化也不会有调仓信号,那么实盘中我可不可以手动换仓?这时因子上的微弱优势肯定抵不住基本面上的巨大利空,所以可以换成排名稍微靠后的基本面正常的一只股票。但是我担心会不会排名靠后会导致收益快速平庸化,所以我测试了在前两项因子不变的情况下,按照市值顺序买入排名最大的6-10位的五只股票。

eps+ms不变,市值选择6-10位,择时后结果如下:
在这里插入图片描述
可以看出担心的情况发生了,收益明显衰减了很多,在有择时的情形下也只能略微跑赢基准,所以万一前五大持仓中的股票出现基本面巨大利空,可以出于安全性考虑选择卖出问题股票,额外资金直接国债逆回购或者买入沪深300etf,而不是买排名靠后的股票。这里可能有人会问,为什么差5个差别就这么大,是因为前两种因子选股后的列表一共就只有20只左右的股票,5只正好相当于差了一个四分之一分位,所以差别会比较明显。
额外多说一句关于对基本面利空的判断,至于能不能量化它不太清楚,不过市场混久了的人肯定会有一些经验,比如之前的东阿阿胶利润减少,或者长生生物的问题,一般身处其中多多少少都会有些感受。

3.最后贴一下沪深300只买市值最大5只股票进行对照,可以看出只用大市值是没有意义的(结果已添加择时)
在这里插入图片描述

运行时间的影响

这里我没有深入研究,仅随机挑选了一个不同的时间运行,之前是9:30,改为11:00运行,效果如下,有一定影响,个人感觉还可以接受。另外也可以尝试每周运行等等。(结果已添加择时)
在这里插入图片描述

这篇关于【策略】大盘蓝筹策略,收益竟然可以这么惊人!的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/721112

相关文章

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

缓存策略使用总结

缓存是提高系统性能的最简单方法之一。相对而言,数据库(or NoSQL数据库)的速度比较慢,而速度却又是致胜的关键。 如果使用得当,缓存可以减少相应时间、减少数据库负载以及节省成本。本文罗列了几种缓存策略,选择正确的一种会有很大的不同。缓存策略取决于数据和数据访问模式。换句话说,数据是如何写和读的。例如: 系统是写多读少的吗?(例如基于时间的日志)数据是否是只写入一次并被读取多次?(例如用户配

Flink任务重启策略

概述 Flink支持不同的重启策略,以在故障发生时控制作业如何重启集群在启动时会伴随一个默认的重启策略,在没有定义具体重启策略时会使用该默认策略。如果在工作提交时指定了一个重启策略,该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。常用的重启策略: 固定间隔 (Fixe

Java后端微服务架构下的API限流策略:Guava RateLimiter

Java后端微服务架构下的API限流策略:Guava RateLimiter 大家好,我是微赚淘客返利系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿! 在微服务架构中,API限流是保护服务不受过度使用和拒绝服务攻击的重要手段。Guava RateLimiter是Google开源的Java库中的一个组件,提供了简单易用的限流功能。 API限流概述 API限流通过控制请求的速率来防止

未雨绸缪:环保专包二级资质续期工程师招聘时间策略

对于环保企业而言,在二级资质续期前启动工程师招聘的时间规划至关重要。考虑到招聘流程的复杂性、企业内部需求的变化以及政策标准的更新,建议环保企业在二级资质续期前至少提前6至12个月启动工程师招聘工作。这个时间规划可以细化为以下几个阶段: 一、前期准备阶段(提前6-12个月) 政策与标准研究: 深入研究国家和地方关于环保二级资质续期的最新政策、法规和标准,了解对工程师的具体要求。评估政策变化可

面对Redis数据量庞大时的应对策略

面对Redis数据量庞大时的应对策略,我们可以从多个维度出发,包括数据分片、内存优化、持久化策略、使用集群、硬件升级、数据淘汰策略、以及数据结构选择等。以下是对这些策略的详细探讨: 一、数据分片(Sharding) 当Redis数据量持续增长,单个实例的处理能力可能达到瓶颈。此时,可以通过数据分片将数据分散存储到多个Redis实例中,以实现水平扩展。分片的主要策略包括: 一致性哈希:使用一

集群环境下为雪花算法生成全局唯一机器ID策略

雪花算法是生成数据id非常好的一种方式,机器id是雪花算法不可分割的一部分。但是对于集群应用,让不同的机器自动产生不同的机器id传统做法就是针对每一个机器进行单独配置,但这样做不利于集群水平扩展,且操作过程非常复杂,所以每一个机器在集群环境下是一个头疼的问题。现在借助spring+redis,给出一种策略,支持随意水平扩展,肥肠好用。 大致策略分为4步: 1.对机器ip进行hash,对某一个(大于

数据库归档策略

数据库迁移策略 为备战双11,需要将数据库中的相关表(历史订单)进行归档,以便腾出更多的空间迎接订单的暴增。作者经过尝试,得出自认为最优的解决方案。下面给出数据库归档策略及示例代码。 现有条件: 1.现有两个数据库:db-A 以及 db-B; 2.两个库中有字段相同的表:tba(表中只有字段订单id–rx_id(long型) 有索引); 3.归档库的tba中还有17年整年的归档数据。 4.由于单

2024 年高教社杯全国大学生数学建模竞赛 C 题 农作物的种植策略 参考论文 无水印

持续更新中,2024年数学建模比赛思路代码论文都会发布到专栏内,只需订阅一次!  完整论文+代码+数据结果链接在文末!  订阅后可查看参考论文文件 第一问 1.1 问题重述 这个问题围绕的是华北山区的某乡村,在有限的耕地条件下,如何制定最优的农作物种植策略。乡村有 34 块露天耕地和 20 个大棚,种植条件包括粮食作物、蔬菜、水稻和食用菌。除了要考虑地块的面积、种植季节等,还要确保

【redis】数据量庞大时的应对策略

文章目录 为什么数据量多了主机会崩分布式系统应用数据分离架构应用服务集群架构负载均衡器数据库读写分离 引入缓存冷热分离架构 分库分表微服务是什么代价优势 为什么数据量多了主机会崩 一台主机的硬件资源是有上限的,包括但不限于一下几种: CPU内存硬盘网络… 服务器每次收到一个请求,都是需要消耗上述的一些资源的~~ 如果同一时刻处理的请求多了,此时就可能会导致某个硬件资源不够用了