 jackyu66gitandCursor
|
bfdb2f2e2a
|
引擎四处「算了没人要的东西」，append_bar 13.9ms → 6.6ms
服务端把增量上线后回传两个热点：add_indicators 为加一根重算全表（占 34%）、
cal_bi_list 整表重扫（51%）。顺着查下来四处都不是算法慢，是算了没人读的结果。
1. cal_trend 挂到 lean 下。它不是笔的依赖（bi.py:221 在它自己的循环里读自身
序列状态），服务端 verify_incr_parity 三币 1800 根已对拍定论。web 走非
lean，klc_trend 图层不受影响。
2. check_fx_pattern 删掉拼完就丢的字符串。它把 klu.to_string() 拼成 p 只为
一行注释掉的 print——2000 根上近 3 万次 f-string 加 6 万次 enum 格式化，
而且在 cal_bi_list 内层。klu.pattern 只被 cal_klu_pattern 自己的双K/三K
判定读，不出模块不进 web，所以整个调用在 lean 下也跳过。
3. ChanBI.add_klc 去二次方。去重原本线性扫 klc_list，且每加一根就把整笔所有
KLU 的 macdhist 重累一遍，往一笔加 k 根是 O(k²)。改成下标集合加
macd_hist/macd_div 惰性求值。这两个值只有背驰判定（bsp.py）读，lean 下
bsp 根本不算。
4. add_indicators 批量挂列。2001 行上 TA 计算合计只有 2.5ms，而 30 多次
df['x']= 要 3.6ms——开销大头是 BlockManager 逐列插入不是计算，改为一次
concat。cal_volume_ratio 里为算一列 rolling 而 copy() 整张 40 列表，一并去掉。
实测（本机，2001 根窗口。服务端基线 21.8ms 是另一台机器，别直接比绝对值）：
append_bar 13.9 → 6.6ms
└ rebuild_bi_zs 8.7 → 2.8ms
└ add_indicators 4.4 → 3.5ms
TF_DF lean 49.8 → 32.9ms
TF_DF full 72.7 → 64.9ms
对拍用 git worktree 检出改动前的提交，同一份 BTC 1m 4000 根跑 38 项指纹：
full 模式 19 项全部一致（web 那条路没动）；lean 模式差 2 项，正是设计要它差
的 klc.trend 和 klu.pattern，而 lean 下 bi/zs/seg/bsp/dataframe 全部一致——
这就是「这两个字段没人读」的实测证据：打空它们，下游一位不变。
瓶颈已经换位置了。新增 probe_inner.py 拆 inner_ms 分档：本机 TF_DF 两条腿占
70%、build_htf_zones 13%、htf_fx_timeline 6%，而服务端报的是 chan 构建 22ms /
信号链 86ms，机器差解释不了这个四倍差距。曾怀疑是 payload 反序列化，实测
_rebuild 只有 1.0ms，假设不成立。两边跑同一探针对分档表才能定位。
HANDOFF 顺带修掉一处 5.6 重号（增量落地那节改为 5.7，本节挂 5.71）。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 16:01:26 +08:00 |
|
|
jackyu66gitandCursor
|
d2fcb27d01
|
否掉 bis[2]：修右边缘重画会把 alpha 打成零，重画是必付代价
§5.41 发现 available_ts 取「中枢最后一笔」是右边缘重画的根因，改取「第三笔」
能把重画率从 6.5% 压到 1.2%，当时据此判断它是「唯一可能同时改善收益与稳定性」
的改动。那个判断只测了稳定性，过早了。
8 个样本外币 × 30 万根 1m，两组共用同一个 TF_DF，只切 available_ts 的取法。
实盘口径（深色 ∧ ATR≥8bp，955 vs 989 笔）：
毛 R 0.933 → -0.000
净均 R 0.798 → -0.147
PF 3.22 → 0.80
滑点余量 15.07 → -2.20 bp
判决依据是毛 R 那一行：扣任何费用之前 edge 就没了，所以不是成本、门控或出场
参数的问题，是信号本身不再有预测力。逐币 8/8 全部变差。滞后确实降了
（2.16 → 2.01），但换来的是另一批交易——两组重合度只有约 30%。
原因是中枢没发育完就下注，支撑/压力还没立住。「等中枢最后一笔」那段等待不是
可以优化掉的延迟，它就是 alpha 本身。由此得一条一般规则：任何以「让信号更早
确定」为目标的改动，先测毛 R，不能只看重画率和滞后。
开关 AVAIL_BI_INDEX 保留只为可复现该 A/B，默认 -1 维持现行口径。环境变量在
调用时解析而非 import 时——fork 启动的子进程会继承已 import 的模块，import
时读会固化成父进程的值。
顺带交叉验证：现行口径本次算出滑点余量 15.07bp，与用优化前代码算的同组同期
15.19bp 吻合。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 04:05:01 +08:00 |
|
|
jackyu66gitandCursor
|
0b4d7693b8
|
缠论引擎提速 2.6x，瓶颈是逐行 Series 查找而非指标计算
原以为浪费在 add_indicators 算了太多用不到的指标，实测它只占全量构建的
1.3%——talib 是向量化 C 代码，便宜。真正的两处：
cal_kl_data 占 96%：每根 K 线 df.iloc[i] 新建一个 40 列 Series，再在其上做
几十次逐键查找。改为预取 ndarray 后 2 万根 1946ms → 824ms。
ChanKLC.cal_all_ema_status 占 25%：每次合并 KLU 都立即重算，而它产出的
ema_status / ema52_pos / ema52_status 全仓无任何读取方（含前端）。改为惰性
求值，保留属性形式以防将来有人读。顺带删掉 get_klc_list 里累加一整轮后直接
丢弃的 ema_up_list / ema_down_list。
另加 TF_DF(lean=True)：只构建到中枢，跳过线段/走势中枢/MACD 状态机——这些
只服务 bsp_list 与 web 展示，笔和中枢不依赖。研究与实盘走这条快 3.6x。
结果 2 万根 5m：full 1946 → 754ms，lean → 543ms。
step46_engine_parity.py 是配套的安全网，改引擎前先跑一次 --save。它对 KLC
端点与分型、笔起止价与 is_sure、中枢 zg/zd/available_ts/阶梯、信号全部输出列，
以及 26 个被下游消费的 dataframe 列取哈希。本次三处改动逐步验证，另用
git stash 切回改动前代码在 20 万根 × 5 用例上做了跨版本逐位对拍，全部一致；
增量路径与 web API 也各验一遍。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 04:04:44 +08:00 |
|
|
jackyu66gitandCursor
|
9b72173285
|
feat: 第四类买卖点（B4/S4）融入缠论引擎与 web 展示
研究侧的 fast_bsp3 一直只活在 research/lib/ 里，web 端看不到，回测与目视
两条线对不上。这次把它搬进引擎，作为独立的第四类买卖点。
之所以单独立类而不是当作 B3/S3 的低滞后版：step30/31 显示引擎原生的
B3/S3 统计上呈逆势、显著亏损（胜率 27.4%、PF 0.66、t −18.76），而同一组
过滤器把 B4 从 PF 1.59 提到 2.26 却对它无效（0.66→0.71）。两者选的是
不同的交易群体，不是同一信号的早晚两版。
- chanlun/analysis/fast_bsp.py 原样搬入 find_fast_bsp3 与 build_htf_zones，
另加 add_zone_ladder / htf_fx_timeline / attach_htf_agree
- research/lib/ 两个模块改为转发，所有 step 脚本导入不变，信号逐条比对一致
- 大级别上下文用 resample 从同一份 df 构建，不额外拉数据，因此与界面上选的
周期和时间范围无关
- 前端三个复选框 + 过滤模式下拉；未过滤的原始信号用浅色，避免与主口径混淆
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 00:05:26 +08:00 |
|
|
UbuntuandCursor
|
206b27fe72
|
refactor: 以自实现指标替换 talib 与 technical 依赖
chanlun/indicators/ta.py 接口兼容 talib.abstract，实现代码实际用到的
SMA/MA/EMA/RSI/ATR/MACD/BBANDS；chanlun/pipeline/resample.py 替代
technical.util.resample_to_interval。调用点只改 import，逻辑未动。
暖机长度与平滑种子按 TA-Lib 的约定实现，差一根 K 线就会让下游所有
笔/线段/中枢整体位移。其中 MACD 需特别处理：TA-Lib 让快慢两条 EMA
在同一根 K 线出首值，因而快线的种子取 x[slow-fast:slow] 的均值，而非
从 fastperiod-1 一路递推——两者在百元价位上相差约 0.17。
BBANDS 是有意的分歧：TA-Lib 用 sumsq/n - mean² 求方差，短窗口远离零
时灾难性抵消（timeperiod=2 误差 8.7e-7），本实现用 rolling std，对 50
位精度基准误差为 0。项目实际使用的周期两者一致到 1e-10。
顺带清理 12 个文件中 16 处从未调用的 talib/technical 导入。
验证：9440 组随机对拨；真实 K 线端到端比对 add_indicators 全部 33 个
指标列，NaN 模式一致、MACD 柱符号 100% 相同；屏蔽两个包后 60 个模块
均可导入。新增 test_ta_compat.py 将输出逐 bar 钉在 TA-Lib 上，但该文件
在 TA-Lib 缺失时静默跳过，改动 ta.py 需在装有 TA-Lib 的环境复跑。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-27 02:01:43 +08:00 |
|
|
jackyu66gitandCursor
|
7f393b93ed
|
refactor: 精简仓库为 chanlun 核心与 web 分析，移除威科夫与遗留模块
删除根目录旧 Chan 模块、策略、配置、文档及 wyckoff 相关代码；更新缠论 pipeline 与笔中枢计算；补充 research 研究与 web 测试。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-27 01:05:12 +08:00 |
|
|
jackyu66gitandCursor
|
8ee11317d3
|
fix(web): 自动刷新保留 K 线视窗；威科夫与图表增量更新
自动刷新改用 tail update 与 scrollToPosition 恢复视窗，避免 setData 后跳到最右；拆分 chart_tv 模块并扩展 analyze/recent API。同步威科夫分析、pipeline 增量构建及相关策略与配置。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-25 22:57:43 +08:00 |
|
|
jackyu66gitandCursor
|
d3188ca83c
|
fix: ECR-004 威科夫区间评分硬化与 VP 绘图减负（已审）
评分选 TR、阶段最小跨度、elements_only 门闩、Top-8 VP；无币种独立参数。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-06 18:46:08 +08:00 |
|
|
jackyu66gitandCursor
|
081a57a90e
|
feat: ECR-003 主站威科夫分析与图表叠层（已审）
独立 wyckoff 引擎 + 按需 include_wyckoff；主站 Lightweight 绘制区间/阶段/事件/VP。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-06 18:33:57 +08:00 |
|
|
jackyu66gitandCursor
|
9f1e7361b6
|
fix: 修复主站自动刷新内存泄漏，并完善 chan_tv 图表体验
主站重建前完整 dispose、去掉重复 sync 监听，自动刷新默认增量更新；顺带消除首屏重复 analyze、复用 ChanMACD，以及全版 TV 指标/未完成中枢/布局本地缓存。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-06 16:09:48 +08:00 |
|
|
jackyu66gitandCursor
|
74dec4e50b
|
refactor: 缠论引擎包化与 Web 分层（ECR-001）
将根目录引擎迁入 chanlun/ 并保留兼容 shim；拆分 TF_DF 与 web 服务；
前端模块化；strategies 改用 chanlun 导入；补充 ESS 文档与 golden 回归。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-05 18:48:20 +08:00 |
|