更专业的github

• README
  • 隐私声明： 明确告知用户“纯前端运行，图片数据不离机”。这是这个产品最大的卖点之一。如果你的算法能在本地跑，一定要大写加粗告诉用户。
  • 开源/原理透明：在页面底部放上原理解释和原理的文章链接
  • 安装方法
  •  免责声明：Disclaimer（仅供学习交流，后果自负)
• Demo GIF
• LICENSE
• Shields.io badges
• About 区域填满

降低使用门槛

• 纯前端实现(不登陆, 不注册, 不配置)
• Web版
  • 极简的功能
• 插件化
  • 通用Userscript

试验

尝试小范围的宣传自己的开源项目, 发现很困难

1. 设计了很多开放性接口, 但是没人会使用, 没有配套文档. 别人并不会看readme. 想要的是安装后就能直接使用的app
2. 不够通用.
3. 每个界面, 每个按钮都要有用.

1: RankIC (Spearman) 公式推导

Spearman相关系数本质上是秩(Rank)变量之间的Pearson相关系数。

对于 $N$ 个样本，alpha排名和returns排名 $x_i, y_i$ 均为 $1, 2, …, N$ 的排列。 已知前 $N$ 个整数的性质:

1. 均值: $\bar{x} = \bar{y} = \frac{N+1}{2}$
2. 方差项: $\sum (x_i - \bar{x})^2 = \frac{N(N^2 - 1)}{12}$

定义秩差 $d_i = x_i - y_i$，则: \(\sum d_i^2 = \sum (x_i - y_i)^2 = \sum x_i^2 + \sum y_i^2 - 2\sum x_i y_i\) 由于 $\sum x_i^2 = \sum y_i^2$ (都是 $1^2 + … + N^2$)，代入得: \(\sum x_i y_i = \sum x_i^2 - \frac{1}{2} \sum d_i^2\)

代入 Pearson 相关系数公式: \(\begin{aligned} \rho &= \frac{\sum (x_i - \bar{x})(y_i - \bar{y})}{\sqrt{\sum (x_i - \bar{x})^2 \sum (y_i - \bar{y})^2}} \\ &= \frac{\sum x_i y_i - N\bar{x}\bar{y}}{\sum (x_i - \bar{x})^2} \quad (\text{分母两项相等}) \\ &= \frac{(\sum x_i^2 - \frac{1}{2}\sum d_i^2) - N\bar{x}^2}{\sum x_i^2 - N\bar{x}^2} \\ &= 1 - \frac{\frac{1}{2}\sum d_i^2}{\frac{N(N^2-1)}{12}} \\ &= 1 - \frac{6 \sum d_i^2}{N(N^2 - 1)} \end{aligned}\)

组合alpha的性能

2. 风险分解

用协方差矩阵 $\Sigma$ 衡量样本的组合相关性

其中关于 $w^T\Sigma w$ 的求导细节展开如下: \(\begin{aligned} \frac{\partial (w^T\Sigma w)}{\partial w_i} &= \frac{\partial}{\partial w_i} \left(\sum_j \sum_k w_j \Sigma_{jk} w_k\right) \\ &= \frac{\partial}{\partial w_i} \left( w_i \Sigma_{ii} w_i + \sum_{k \neq i} w_i \Sigma_{ik} w_k + \sum_{j \neq i} w_j \Sigma_{ji} w_i + \sum_{j \neq i, k \neq i} w_j \Sigma_{jk} w_k \right) \\ &= 2w_i \Sigma_{ii} + \sum_{k \neq i} \Sigma_{ik} w_k + \sum_{j \neq i} w_j \Sigma_{ji} \\ &= \sum_{k} \Sigma_{ik} w_k + \sum_{j} w_j \Sigma_{ji} \\ &= (\Sigma w)_i + (\Sigma^T w)_i \\ &= 2(\Sigma w)_i \quad (\text{因协方差矩阵对称 } \Sigma = \Sigma^T) \end{aligned}\)

🧩 一、从语言设计角度看：从「物理模块」到「语义模块」

传统语言的模块系统是文件层级绑定的命名空间：

• Python：import module.submodule
• Java：package com.example.util
• C++：基于 include 路径
• Rust：基于 mod 文件树

但未来趋势正往语义模块（semantic module）发展，也就是：

模块不由文件夹决定，而由「意图」或「语义标签」定义。

一些现代语言的迹象：

• Swift Package Manager 已经支持 target-based 依赖，可跨文件复用；
• Rust Crates + feature flags 开始允许 feature-based 组合；
• CUE / Bazel 通过标签（labels）管理依赖；
• ReScript / Rome / Deno 正在探索 import maps 与语义分组。

这说明整个行业在从 “文件组织” 向 “语义组织” 过渡。

🧠 二、从工程实践看：tag 是“多维索引”的一种形式

软件结构现在普遍面对的一个问题是：

代码的「用途」比代码的「位置」更重要。

比如：

• 一个函数同时属于 “data-cleaning” 和 “ML-preprocessing”；
• 一个模块既是 “API endpoint” 又是 “business rule”；
• 一个 class 在 “experiment” 和 “production” 中都被使用。

文件夹结构只能表达单继承。 但现代系统需要多继承式逻辑分类，这就是 tag 的优势。

你可以理解为：

• 文件夹层级 = 树状组织；
• tag 体系 = 多维超图组织。

在大型项目中，已经有类似趋势：

• monorepo + metadata-based build（如 Google 的 Blaze / Bazel）
• component registry（如 Web Components、React Storybook、Unity ECS）
• ML pipeline DAG（节点通过类型和标签组装）
• Infrastructure as Code (IaC) 的资源管理，也通过标签做分组调度

这些都不是传统意义上的“目录组织”，而是“属性驱动组织”。

🤖 三、从 AI 辅助开发看：tag 模块是「机器可理解的知识单元」

在 AI 代码生成/检索领域，tag 化的组织方式简直是理想形态：

• AI 可以根据任务语义（“时间序列特征提取”）直接检索带有对应 tag 的函数；
• tag 可以承载更丰富的上下文（依赖关系、使用场景、复杂度、作者）；
• 在代码搜索、重构、自动文档生成中，这类“语义索引”比路径树高效得多。

这其实是代码转向知识图谱化（code as knowledge graph）的一个趋势。 未来 IDE（或 AI 编程助手）可能这样工作：

query: "Find all functions tagged with 'ts_zscore' and 'alpha_transform'"
→ semantic code graph lookup
→ compose into new alpha factor

这已经在 GitHub Copilot、Cursor、Sourcegraph Cody、Gemini Code Assist 的实验版本中初现端倪。

🌌 四、从知识结构演化看：从「树」到「图」

整个信息管理领域（文档、代码、数据库、笔记）都在经历同样的结构演变：

代码组织迟早会跟随这一趋势。 换句话说：tag-based 代码组织不是“异想天开”，而是文件系统式编程的下一步进化。

🚀 未来可能的形态

未来 IDE 或语言生态可能这样工作：

@tag("data", "io", "ml")
def load_dataset(...): ...

# 直接用语义查询或导入
from semantic import tag as T
data_utils = T("data", "io")

data_utils.load_dataset()

或者：

import @data, @ml

这种“tag 作为导入单元”的语法在一些研究语言（如 Eve、DarkLang、Unison）中已经开始出现。

🔮 总结判断

✅ 结论 是的——“tag 化代码组织”非常可能是未来方向， 但不是取代目录结构，而是覆盖在其之上的一层语义索引层。 文件树仍然存在，但它只是物理实现，tag 层才是语义组织的核心。

• 飞书: 支持富文本和卡片
  • 普通消息
  • 消息卡片
    • 打开 飞书开放平台。
    • 在企业自建应用, 创建机器人
      • 获得机器人的App ID, App Secret
      • 在权限管理, 给机器人添加上传图片的权限: im:message
        • 图片需要先上传到平台, 在消息里用链接
        • 每次token只能保存两个小时.
    • 在开放平台的开发文档里搜发送卡片的各种示例
      • llm没法知道专用格式. 可能需要可以上网的agent
• 邮件: 支持html渲染
  • 在gmail开启两步验证, 然后开启 https://myaccount.google.com/apppasswords 就可以

有些hash会非常相似. 目的, 得到alpha id的全部编码信息: 秒级的timestamp+machine id

44/s. 2640/min. 1w consultant. 每人回测100/ 5min.

44x3600x24/10000 = 380 次/天. 这和实际结果很不符合.

1天5w.

假设1:

• 假设1: 由pnl(长2496位的float vector)编码
  • pnl 是

相同pnl不同user -> hash不同 排除这个假设的原因: 生成一系列pnl完全相同的alpha, hash有些是相似但不同, 但有些完全不同.

假设2

user id和hash同为7位. 是否用xor加密. 验证.

hash_a ^ id_a == hash_b ^ id_b 也 不成立

假设2

expression

• ast clean

排除这个假设的原因: 两个表达式完全不相关的alpha, hash相似

• 猜测是不是settings, 表达式, user id的联合编码.

统计重复的hash前缀个数

假设3

时间

统计「前缀 → 时间」的关系 把 dateCreated 转成秒或分钟级的 时间戳。 按 hash 前缀分组，算时间戳的 均值 / 分布范围。 如果「相同前缀的时间非常接近」，说明前缀和时间相关

前缀与创建时间的相关性 出现次数多的前缀通常集中在较短时间区间内（span_sec 不大），说明相同前缀的 ID 可能是同时生成的。 反过来, 固定时间段, 前缀也固定同样的44种. 跨相邻时间段, 就变成88种.

这验证了你之前的猜测：hash 前缀和 dateCreated 时间有关，ID 的前缀不是完全随机，生成算法可能会受时间影响或按批次生成

可视化验证 可以画出 时间 vs hash 前缀 的散点图

这样你就能看到： 前缀长度为 1 → 有多少种不同前缀 前缀长度为 2 → 有多少种不同前缀 … 直到 max_len。 📈 如果前缀确实和时间强相关，你会看到 前缀长度增加时，唯一前缀数量接近样本数（说明前缀逐渐唯一化）。

时间主导，但横向有并发带 这就是我现在看到的情况

同样时间平行带大概有44个左右

歪路: 猜测prefix之间的关系. 👍 从你的结果可以看出明显的规律： mod 16 大部分前缀落在 [0,5,10,15,6,9,…]，集中在少数几个余数上。 说明前缀低位每 16 有一个间隔的规律，但还有一些偏移（可能是并发带/随机部分）。 mod 32 余数集中在 16,0,10 等位置，说明低位有更大的分段，仍然有少量分散。 mod 64 集中在 16 和几个其他余数上，每个余数对应大概一组“平行带”。 这非常吻合你观察到的 “同一时间平行带大概 44 个左右” 的现象。 低位取模 64 时，可以把并发带分离出来。 mod 128 更大模数开始显得稀疏，主要几个值有重复。 说明前缀的低位并没有均匀分布，而是有特定分片/并发槽的规律。

按 count 或 span_sec 排序，那就用 sort_values

只用到44个字符

为什么选择44字符? 可能是URL-safe / visually unambiguous alphabet 防止混淆 -> I/L, O/0 没有这种规律

有 纯数字 + 大写：0G, 1G, … 9G. 猜测不同平行带可能等距 -> 图上就能看出是个错误猜测

猜测同一种混淆方式? 没法验证

猜测通过出现频率计算混淆顺序 -> 这种想法没有道理

把平行带分开计算

• 发现hash变化有明显的周期,

• 画图

• 推测BASE44的顺序
  • 是统一的?
    • 如果是统一的, 应该是真正的进位. 但是同时出现了 0N-> 0x, PY -> Px, pM->px 所以我的猜测应该不对
  • 还是不同bucket 不同
• 指数假设: log(decoded-intercept) = log(A) + B * timestamp
  • 固定intercept的情况
  • exp优化的自由度太高了. 数值算法无法收敛

• rsv(未成熟随机值) = (close - ts_min(low, n)) / (ts_max(high, n) - ts_min(low, n)) n=9

对应关系

• cap = close x sharesout

修改局部

成功步骤

用脚本实现1-2-3步骤即可. 代码: mongo_2_dictionary.py

1. 把数据转成 Apple Dictionary 支持的 TSV 格式。
   • ⚠️ 避坑：不要用 \t\n , 用 HTML 标签来控制排版，用 <div> 表示新行，用 <br> 来做分隔。这样避免了特殊字符被误解析。
2. 用  PyGlossary 把 .tsv 转成 AppleDict 的源文件。pyglossary dictionary_dump.tsv output.dictionary --read-format=Tabfile --write-format=AppleDict
   • ⚠️ 避坑：不要用 CSV, 一开始我试过 CSV，但 AppleDict 的编译脚本会直接解析失败。
3. 编译 Apple Dictionary
   • PyGlossary 会生成一个字典目录，里面包含：.xml 源文件, .css 样式文件, .plist 配置文件, Makefile
   • 正常情况下，进入目录直接运行：make ; make install
4. 安装完成后，打开 macOS 自带的“字典”应用，在settting里勾选新字典。

工具和坑点总结

• 需要安装 Dictionary Development Kit (DDK)
  • 据说macOS 有自带的 dictutil 我没有找到。
  • DDK 要单独安装（Xcode 附带）。
• 不要用 DDK 官方的 build_dict.sh, 用  PyGlossary 生成
  • 这个脚本里调用的 make_line.pl ，perl 脚本里有 bug。无法解决. xml 格式也非常讨厌
• 样式限制
  • Apple Dictionary 对标题样式是写死的，没法自定义。
• 调试
  • 我在自己本地的dev版app上调试, 发现字典不是实时更新的, 需要重启之后才会加载新的 (可能是DictionaryServices.framework 的行为特性, 每个app单独一个缓存, 字典也在里面, 不会热更新)

结果

• 效果和官方字典差不多
• 但是在一些网页的在线代码编辑器(可能用的是自绘控件, 而不是macos的Cocoa文本系统)和微信(lookup被软件禁用)不能用

把 ...?...:... 处理成if_else(...,...,...) 的形式.

初衷是用正则替换把对应DSL的operator转换成python语言, 然后用python的ast 直接解析. 但是三元运算符的处理比较复杂, Python 中并没有直接对应的语法结构, 导致没法简单的替换.

可以把字符串token解析成AST 的构建过程理解成“对运算符按优先级排序”的过程.

直接用字符串替换

• 用字符串正则查找tenary并替换
• 递归处理?: 和括号, =, 逗号的关系
  • 处理 括号, 逗号 都依赖栈来正确处理嵌套结构

写parser处理

可以通过编写自定义的解析器来处理三元运算符。下面是一些处理流程：

1. 定义:
   1. 定义 AST 节点：设计不同类型的节点来表示表达式，如常量、变量、运算符等。
   2. Tokenize：将源代码字符串分割成 tokens（例如：数字、运算符、字符串等）。
      1. 例如: ``a<0.2? → [(“NAME”,”a”) (“OP”,”<”) (“NUMBER”,”0.2”) (“QMARK”,”?”)]`
   3. 定义优先级: 找表达式中最低的优先级处理.
2. 具体流程:
   1. 预处理（字符串替换/注释/关键字替换）
      • 把wq expr 中的'...' / "..." 用占位符替换
        • ts_sum(group_zscore(a<0.2? (a+0.7):(a>0.9? a:0.9),bucket(rank(cap),range='0.1, 1, 0.1')),5) -> ts_sum(group_zscore(a<0.2? (a+0.7):(a>0.9? a:0.9),bucket(rank(cap),range=__STR_CONST_0__)),5)
      • 做若干文本替换（or/and/not → logical_or/logical_and/…、–→+、NaN→nan 等）。
      • 删除注释（/* … */ 与行注释 // 或 #）。
      • 按分号 ; 切分成多条语句，逐条 tokenize() → parse_expr() → to_python()。
      • token 化
      • 自顶向下递归解析（赋值 → 三元→ 二元按最低 precedence 为根 → 原子/函数/一元）
   2. 解析每句代码:
      • 顶层赋值检测
        • 去掉最外层的分号
        • 检查最外层(用括号记录层数)的赋值 =, 把赋值语句的左右两侧分开.
      • 三元检测
        • 检查最外层 ? 的第一个位置作为三元入口, 再从 ? 后扫描并找到对应的最外层 :（depth=0）的位置
        • 每当遇到括号要剥去括号重新检测三元
      • 二元检测(binop)
        • 检查最外层优先级最低的op. 优先级相同, 取最右边的op拆分(左结合)
      • 一元检测(atom):
        • 检查 一元运算符(!, -) -> 单token原子(number, string, name) -> function call -> 检查每个参数
   3. 构建 AST
      • 递归生成 Python 代码: 对不同节点分别处理
      • 还原字符串并输出
      • 每条语句生成的 Python 片段再还原字符串常量占位符.
   4. 收集所有处理过的语句并最终用 \n 拼接返回

• ⚠️ 注意点: ast解析一定要注意代码的覆盖率. 保证不会出现不认识的token, operator, 分支情况.

parse优化

token优化

把预处理步骤内化到token中统一处理.

pratt优化

Pratt parser 其实是 自顶向下递归下降解析器的一种优化方式: 不是从最低优先级的字符开始, 而是随着解析从左往右动态的构建ast.

• 每个token除了优先级外, 定义两个方法: (nud和led)
  • nud(null denotation, 前序) 当token出现在表达式开头时
  • led(left denotation, 中序) 当 token 出现在 表达式中间（左边有东西）时调用

下面是一个DSL对应的token行为表格.

表格解释 $\downarrow$ :

• lbp（left binding precedence, 左操作数绑定优先级, 当前op的优先级）, rbp (右操作符绑定优先级, 上一个op的优先级)
  • 当下一个op优先级更高时, ast会不断加深. 当下一个op优先级不足时, ast会从底向上直到找到合适的位置添加
  • 比如 a = b = c, 在第二个等号处, 把第一个等号的优先级稍稍降低, 保证右侧的优先级更高. 解析为 a = (b = c)
  • 括号总是最优先的, 直接把rdp降到最低

a + b x c -d:

a = b = c:

代码

• replace_ternary.py
• parser.py
• pratt_parser.py