 |
ExplodingDragon🏢 Umbrella Corporation V2EX member #461106, joined on 2019-12-24 22:13:39 +08:00 |
Raccoon
 |
Per ExplodingDragon's settings, the topics list is hidden |
Deals info, including closed deals, is not hidden
ExplodingDragon's recent replies
1 day ago Replied to a topic by PeterTerpe › Minecraft › 基于 P2P/F2F 的封禁名单共享 |
> 玩家向管理员申诉，管理员就能封禁那个恶意节点
那如果管理员有坏人或者玩小团体有偏向呢
那如果管理员有坏人或者玩小团体有偏向呢
3 days ago Replied to a topic by layxy › OpenAI › openai 周限又重置了，已经放弃 claude 了 |
现在 pro 5x 额度掉的比之前快多了
6 days ago Replied to a topic by lizhian › 程序员 › ChatGPT Pro 20x 才是归宿 |
> “ 6 个相信你的人” , “初期一个 pro 账号廉价账号加廉价账号甚至日抛,” “余量还能往外卖” , “掺水血赚一波”
这就是不要相信任何中转站的很小部分原因
这就是不要相信任何中转站的很小部分原因
7 days ago Replied to a topic by goofish › Claude › 充了 20 刀 Pro 订阅，不到半小时被秒封，兄弟们引以为戒啊 |
A ➗ 都已经这样子了就不要给他当狗了 ...
7 days ago Replied to a topic by meetyuan › 程序员 › 大家都是怎么判断中转站安全性呢？ |
中转站没有安全的，没给你响应内容替换为病毒脚本算良心的
9 days ago Replied to a topic by iqoo › 程序员 › 只有 3 个运算操作的解密函数，破解奖励一杯咖啡 |
顺便贴一下使用 chatgpt pro 的结果 , 无法跳步或 SIMD 就没继续看了 （：
这段原始代码不能直接用“常数快速幂”或“矩阵快速幂”跳过 1e14 轮。关键原因是：x ^= x >> 32 不是高低 32 位交换，而是把高 32 位异或进低 32 位；它虽然可逆，但和普通整数乘法的进位混在一起后，整体既不是模 2^64 乘法，也不是 GF(2) 线性变换。
设 B = 2^32 ，C = 0xD1342543DE82EF95 = aB + b ，x = hB + l 。一轮乘法后：
```
L = b*l mod B
H = b*h + a*l + floor(b*l / B) mod B
```
随后：
```
T(h, l) = (H, L xor H)
```
问题就在这里：H 里有整数乘法进位 floor(b*l / B)，而低位又用了 xor 。这会把“模加/乘”的结构和“GF(2) 异或线性”的结构打碎。
一个很小的反例就能排除快速幂假设：
T(1) = 0xd13425430fb6cad6
T(2) = 0xa2684a871f6d95ad
如果它等价于某个常数乘法 T(x)=Kx mod 2^64 ，那么应有：
```
2*T(1) mod 2^64 = 0xa2684a861f6d95ac
```
但实际 T(2) 多了 0x100000001 。这就是进位和异或混合造成的偏差。
同样，它也不是 GF(2) 线性的：
```
T(1 xor 2) != T(1) xor T(2)
```
所以这类写法都不成立：
```
// 错：只能用于纯乘法状态转移
x *= pow_mod(C, n, 2^64);
// 错：只能用于真正的 GF(2) 线性 xorshift
matrix_pow(M, n) * x;
```
这个常数本身确实是常见的 64 位 LCG/LXM 乘子； OpenJDK 相关实现也把 0xd1342543de82ef95 用作 LCG 乘子并说明其谱测试分数。也就是说，如果状态转移只是 LCG 乘法/加法，它能快进；但你这里把 mix 结果反馈回状态了，结构就变了。
这段原始代码不能直接用“常数快速幂”或“矩阵快速幂”跳过 1e14 轮。关键原因是：x ^= x >> 32 不是高低 32 位交换，而是把高 32 位异或进低 32 位；它虽然可逆，但和普通整数乘法的进位混在一起后，整体既不是模 2^64 乘法，也不是 GF(2) 线性变换。
设 B = 2^32 ，C = 0xD1342543DE82EF95 = aB + b ，x = hB + l 。一轮乘法后：
```
L = b*l mod B
H = b*h + a*l + floor(b*l / B) mod B
```
随后：
```
T(h, l) = (H, L xor H)
```
问题就在这里：H 里有整数乘法进位 floor(b*l / B)，而低位又用了 xor 。这会把“模加/乘”的结构和“GF(2) 异或线性”的结构打碎。
一个很小的反例就能排除快速幂假设：
T(1) = 0xd13425430fb6cad6
T(2) = 0xa2684a871f6d95ad
如果它等价于某个常数乘法 T(x)=Kx mod 2^64 ，那么应有：
```
2*T(1) mod 2^64 = 0xa2684a861f6d95ac
```
但实际 T(2) 多了 0x100000001 。这就是进位和异或混合造成的偏差。
同样，它也不是 GF(2) 线性的：
```
T(1 xor 2) != T(1) xor T(2)
```
所以这类写法都不成立：
```
// 错：只能用于纯乘法状态转移
x *= pow_mod(C, n, 2^64);
// 错：只能用于真正的 GF(2) 线性 xorshift
matrix_pow(M, n) * x;
```
这个常数本身确实是常见的 64 位 LCG/LXM 乘子； OpenJDK 相关实现也把 0xd1342543de82ef95 用作 LCG 乘子并说明其谱测试分数。也就是说，如果状态转移只是 LCG 乘法/加法，它能快进；但你这里把 mix 结果反馈回状态了，结构就变了。
9 days ago Replied to a topic by iqoo › 程序员 › 只有 3 个运算操作的解密函数，破解奖励一杯咖啡 |
@iqoo #29 所以这是打算利用 wasm 嵌入到浏览器做 PoW 来对抗爬虫或者其他自动化工具 ?
我去，初音未来！
13 days ago Replied to a topic by street000 › Node.js › Bun 从 Zig 到 Rust 的迁移已经实锤，下个版本可能成为最后一个 Zig 版本 |
看了下 bun 已经合并了 rust pr 了 hhhh ，这种项目还是在小圈子自萌去吧，架构/语言说变就变，旧的 pr / issue 完全不管，藐视贡献者玩独裁主义
https://github.com/oven-sh/bun/pull/30412
https://github.com/oven-sh/bun/pull/30412
Select Language