Hypercube's Channel

Python traceback 涉及好几个概念和各种转换函数，经常搞不明白我需要哪个，整理了一下。

研究了一下 compositing and blending 的原理，之前一直不太明白 alpha 如何影响各种 blend mode，以及结果的 alpha 是如何确定的。以下信息整理自 https://www.w3.org/TR/2024/CRD-compositing-1-20240321/ ，符号与之保持一致，Cs、Cb、Co 分别表示前景、背景、输出颜色，αs、αb、αo 分别表示其 alpha。 1. Cm = B(Cb, Cs) 混合前景色和背景色，这一步完全不考虑 alpha，其中 B 取决于 blend mode，并且大多数 blend mode 独立处理 rgb 三个通道。 2. Cr = αb * Cm + (1 - αb) * Cs 用背景 alpha 控制混合结果与前景色的比例。 3. αo = Fa * αs + Fb * αb 计算输出 alpha，其中 Fa 和 Fb 取决于 compositing operator。 4. Co = (Fa * αs * Cr + Fb * αb * Cb) / αo 计算输出颜色。 默认的 blend mode 是 normal，其定义 B(Cb, Cs) = Cs。默认的 compositing operator 是 source over，其定义 Fa = 1，Fb = 1 - αs。代入可知默认情况下： Cm = Cr = Cs αo = αs + (1 - αs) * αb Co = (αs * Cs + (1 - αs) * Cb) / (αs + (1 - αs) * αb) 这种默认情况被称为 simple alpha compositing，它具有结合律，多个层次用不同方式组合得到的结果相同。但使用不同的 blend mode 或 compositing operator 可能会破坏结合律，规定从下向上组合，也就是位于最底部的两层先组合，再与上层组合。 P.S. 原文第 6 节公式错了，Co 应改为 co，我发现有别人也注意到这个错误了： https://github.com/w3c/fxtf-drafts/issues/478

我才知道 Python 捕获异常得到的 traceback 是只从 try 这里开始的？！例如 f1 调 f2，f2 在 try 里面调 f3，f3 抛异常，在 f2 的 except 中捕获的异常带的 traceback 只会有两条，第一条是 f2 里面调 f3 的那一行，第二条是 f3 里面抛异常的那一行。当然了，未捕获的异常相当于在程序最外层被捕获，会带完整的 traceback。 明白了这一点后，读 traceback 就突然感觉清晰多了。

https://youtu.be/58hoktsqk_Q 这张专辑（Chromatica，2020）我倒是很早就听过，然而是工作的时候作为背景音乐听的，没看 MV，太可惜了！昨晚偶然看到这个视频，导致睡觉推迟一个多小时👀而且一晚上也很多次在想这个视频。 说不清楚具体是什么吸引我，可能是整个过程的艺术化表现非常精彩，可能是最后结尾处的短短几句话让我对事故原因和她的精神状态有很多思考，也可能是其中的人物形象太像我最近在玩的游戏《巴别塔圣歌》了😂

前段时间有个俄罗斯的学生突然加我，向我请教用 PyQt6 开发翻转棋游戏相关问题，说是课程大作业。帮他的过程中感觉好像曾经给 C 语言课带助教啊😂昨天他说成功赶上 ddl 交了，代码在 https://github.com/kkasuann2000/gameR 。 我问他到底在哪找到我的，为什么会这样跑来求助一个陌生网友，而且我也没发布过翻转棋或者 PyQt6 相关代码。他说是搜索 reversi game python 找到了 https://ibug.io/blog/2018/05/python-reversi/ ，侧栏有 Telegram Channel 链接 @iBugThought ，那天最新一条消息正好是我和 iBug 约饭时聊到的话题 https://t.me/iBugThought/4098 ，其中有我的 username。 原来是把我当成 iBug 了😂

这么多网站用 https://github.com/bilibili/flv.js 播放视频，yt-dlp 和 youtube-dl 怎么都没人做过下载 flv.js 中的视频的功能呢？网上一个相关内容都搜不到。

把我一直在用的 bashrc prompt 作为单独的项目开源了😃并给代码加了详细的注释以便修改，欢迎取用。 https://github.com/SmartHypercube/fancy-prompt

我做实验时常遇到这个需求：在对数意义下均匀地测试一个变量的一系列取值，例如每秒 10 个请求、100 个请求、1000 个请求时系统性能，或是 4KiB、8KiB、16KiB 等不同数据量的处理性能。 每次乘以 10 或乘以 2 都比较简单，但是如果希望乘以更小的数，还希望序列中的数字有效位数较少，对人来说看起来方便，就有点难了。例如每次简单地乘以 1.1 会得到 1.21、1.331、1.4641、1.61051。 于是我常在实验脚本中手写：[10, 13, 17, 20, 25, 30, 40, 50, 60, 80, 100, 130, 170, …]，相对来说比较好读，对数意义下切分也比较均匀。（不需要完美均匀，只是越不均匀的话实验效率越低，会有一些区间实验太多，另一些区间实验不足。） 今天才知道这个问题叫 https://en.wikipedia.org/wiki/Preferred_number ，一些例子： 1-2-5：1, 2, 5, 10 R5：10, 16, 25, 40, 63, 100 R10：100, 125, 160, 200, 250, 315, 400, 500, 630, 800, 1000 E3：10, 22, 47, 100 E6：10, 15, 22, 33, 47, 68, 100 E12：10, 12, 15, 18, 22, 27, 33, 39, 47, 56, 68, 82, 100 E24：10, 11, 12, 13, 15, 16, 18, 20, 22, 24, 27, 30, 33, 36, 39, 43, 47, 51, 56, 62, 68, 75, 82, 91, 100 E 系列的数还有一个好处，E6、E12、E24 分别近似每步加 50%、20%、10%，步长比较“整”。

IEEE 754 认为二进制规约浮点数应该视为 (-1)^s * m * 2^e，其中 s 是符号位，m 是一个二进制数，其整数部分总是为 1，小数部分每一位都是 0 或 1，e 是指数。 也就是说，一般来说系数 m 应满足 1 <= m < 2，在这个形式下才按照 m * 2^e 这个公式定义指数 e。提到指数的最小值和最大值时也都是按这个标准理解的，例如规定双精度浮点数的指数最大值是 1023，所以 1.999 * 2^1023 能表示，2 * 2^1023 就超出范围了。 但 C 和 Python 提供的提取浮点数指数部分的函数 frexp 居然用的不是这个定义。它总是把系数放到 0.5 <= m < 1 这个范围内，并相应返回指数，导致一般来说它返回的指数比 IEEE 754 中常说的那个指数概念大 1。它有可能返回的最大指数是 1024，不是 1023。 当然这里怎么规定都是可以的，但采用和 IEEE 754 不同的规定会导致 emin emax 对不上，感觉平添不少混乱啊。