fix(pack): 编码取整与参考实现对齐 + 产物不再夹带测试夹具(v0.2.4)
两个缺陷,都由上一轮的验收机制暴露:
1) 编码取整与契约参考实现不一致(T-WIN-022)
KeypointFrame.encode() 用 GDScript 的 roundi(半数远离零),而契约参考实现
(Web 的 keypoint-codec.ts)与**生产发送方 Android**(Kotlin Math.round)都是
「半数朝 +∞」:-2.5 分别是 -3 与 -2。实测在 12 个跨实现向量里 1 例 33 字节不同。
本端是接收方、encode() 只用于自测与协议回归,对产品无影响;但它让「跨实现一致性」
只能停留在宽松口径("差异仅限 .5 取整边界"),而宽松口径会退化成没人看的已知差异。
修复:新增 _round_like_js(v) = floor(v + 0.5),用于 4 处取整(坐标 ×3 + 置信度);
夹紧顺序对任意实数与参考实现等价。
收紧:accept-frame-vectors.sh 的编码口径改为「必须为 0 项差异」。
新增单测(+11 断言):_round_like_js 的 5 个取值、端到端 -0.5/32767 → 0(roundi
会给 -1,是有效判别用例),以及 test_reference_vectors_decode_and_encode_exactly
—— 直接读锁定的参考向量逐值解码 + 用 f32InputPoints 重编码与 f32Hex 逐字节比对,
让 verify.sh(只跑源码、无需 pck)也覆盖「Web ↔ Windows」这条边。
2) 产物里夹带开发/验收工具(T-WIN-023)
export_filter="all_resources" 且 exclude_filter 没有 build/*,于是每次新增
构建/验收脚本都被编译进 pck —— 包括**故意不合规**的坏服务端夹具 probe-ws-bad.gd
与 frame-vectors.json。实测 OpenDance.pck 315,464 B →(排除后)145,400 B,
即 54% 的 pck 是测试夹具。已发布的 v0.2.3 同样带着这些残留。
修复:exclude_filter 增加 build/*;
新增产物级防线 build/integration/list-pck.gd(遍历包内条目、标出
res://build/ tests/ _scratch/ dist-release/ 与 *.md 残留,有残留即退出码 1),
并接进 accept-release.sh(打印条目总数并断言「无开发残留」)——否则下次加个新
工具目录又会重演。顺带确认 pck 没有把上一次导出的 pck 自嵌套进去。
实测(v0.2.4 发布包,三条产物级验收全绿):
* accept-release.sh:pck 58 项无开发残留 / PE 版本资源 0.2.4 / pck 启动 180 帧无错 /
运行时探针(包内版本号 0.2.4、AboutScreen 显示值、15 项关键资源、契约表比对)
* accept-ws.sh:客户端 30 通过 / 0 失败 + 服务端侧 16 项事实
* accept-frame-vectors.sh:解码 12/12、396 点 0 差异,
**编码器字节与参考实现完全一致(0 项差异)**
* verify.sh:785 通过 / 0 失败(原 774)
踩坑:给 -0.5/32767 这类值写断言时,第一版按"理想有理数"期望(2.5/32767 → 3)而
失败 —— PackedVector3Array 存的是 float32,乘回 32767 后略小于半整数,与 JS 对同一
float32 输入的行为其实完全一致。断言必须基于实际存储精度,或改用有效判别用例。
This commit is contained in:
@@ -20,9 +20,11 @@ extends SceneTree
|
||||
## 即 **float32**;参考实现是 float64。因此先把期望值收敛到 float32
|
||||
## (GDScript 里借 `Vector3(...)` / `PackedFloat32Array([...])` 天然完成)
|
||||
## 再比**精确相等** —— 这比用容差更严格,且把差异限定在「表示精度」上。
|
||||
## * 另附:用本端 `encode()` 对向量里的 `inputPoints` 重新编码,与参考字节比对。
|
||||
## 本端**不是发送方**(encode 只用于自测),因此这一项差异记为「已记录差异」
|
||||
## 而非失败;但差异必须**只出现在取整边界用例**上,否则说明别处也有问题。
|
||||
## * 另附:用本端 `encode()` 对向量里的 `f32InputPoints`(float32 同输入基准)
|
||||
## 重新编码,与 `f32Hex` 逐字节比对。v0.2.4 起本端取整已改为 `floor(x + 0.5)`
|
||||
## (与 JS `Math.round` 的「半数朝 +∞」一致),因此**差异必须为 0**;
|
||||
## 收敛前的宽松口径(只允许出现在 .5 取整边界)已废弃 ——
|
||||
## 规则性偏差留在日志里会变成"永远没人看的已知差异"。
|
||||
|
||||
const KeypointFrame = preload("res://src/net/keypoint_frame.gd")
|
||||
|
||||
@@ -202,7 +204,7 @@ func _run() -> void:
|
||||
if encode_differences.is_empty():
|
||||
print("[frame-vectors] ✓ 本端 encode() 与参考字节完全一致")
|
||||
else:
|
||||
print("[frame-vectors] · 本端 encode() 与参考字节的差异(仅记录,本端非发送方):")
|
||||
print("[frame-vectors] ✗ 本端 encode() 与参考字节存在差异(取整规则应已对齐,必须为 0):")
|
||||
for d in encode_differences:
|
||||
print(" · %s:%d 字节不同(量化前存在 .5 值=%s)" % [
|
||||
d["case"], d["diffBytes"], str(d.get("halfValueInput", false))])
|
||||
|
||||
Reference in New Issue
Block a user