3.18

#diary #2026/3

以下是一些可能没有详细阐述的记忆片段。

由于操作系统的高度实践性工程性，在学习的过程中应当放弃对一切进行理想抽象、归纳的执着。

当文本本身已经十分直接明了时，做笔记的意义又是什么呢？像 Operatin System: Principles and Practices、Computer Systems: A Programmer Perspective 这样的书，本身的语言已经十分平易通俗，涉及的知识也不是什么深邃的理论，像学数学一样用自己的语言、理解来重新叙述、结构化一套理论的必要性大大下降。

• 对于这样的书而言，做笔记的意义似乎只剩下了结构化和记忆这两个作用。
• 在这种情况下，重写这种笔记形式失去了存在的必要性。（从记忆的实现方式来看，将原有文本自己重新抄一遍的的形式显然是不必要的。）

尝试使用 Obsidian Spaced Repetition 插件来强化记忆。这种自己给自己出题的形式或许有一点 Feymann 方法的影子，从某种意义上来说这就像创造出了另一个虚拟的对象然后尝试让自己通过出题难倒它，不过虚拟对象终究还是虚拟的，所以感觉上这个形式并没有任何额外的正反馈或者记忆强化。自己给自己出题还是太难了，说不定可以由 gemini 老师代劳。

九键输入法实际上是一个成功的设计。在尝试去领 130 周年限定校园卡的路上，由于下雨一只手要打伞所以只能用另一只手打字，26 键的小方块实在是很难按的精准。以前我一直朦胧地认为 26 键的准确性要大大优于 9 键，因为九键的每一个字母格子至少有 3 个字母。9 键成功避免大部分混淆的地方就在于 aeiou 五个元音全部分布在不同的格子里面。

信息表格

• 声母包括：b p m f d t n l g k h j q x zh ch sh r z c s
• 声母分类：
  • 双唇音 b p m
  • 唇齿音 f
  • 舌尖中音 d t
  • 舌尖中音 n l
  • 舌根音 g k h
  • 舌面音 j q x
  • 舌尖后音 zh ch sh r
  • 舌尖前音 z c s
• 韵母包括
  • 单韵母：a o e e i u v er。其中的两个 e 是因为在发音上不同分开的（ei ie 中），在形式上来说二者同属一类。
  • 复韵母：前响 ai ei ao ou 后响 ia ie ua uo ve 中响 iao iu(iou) uai ui(uei)
  • 鼻韵母：前鼻韵母 an en in un(uen) vn ian uan van 后鼻韵母 ang eng ing ong iang uang ueng iong
• 韵母的四呼（不包括 er）：
  • 开口呼（无介母且非 i u v 韵母）：a o e ai ei ao ou an en ang eng ong
  • 齐齿呼（i 做介母或韵母）：i ia ie iao iu(iou) ian in iang ing iong
  • 合口呼（u 做介母或韵母）：u ua uo uai ui(uei) uan un(uen) uang ueng
  • 撮口呼（v 做介母或韵母）：v ve van vn
• 汉语拼音的组成有三种：
  • 声母 + 韵母构成：
    • 双唇音 b p m 可组合开口呼、齐齿呼、u
    • 唇齿音 f 可组合开口呼、u
    • 舌尖中音 d t 可组合开口呼、齐齿呼、合口呼
    • 舌尖中音 n l 可组合开口呼、齐齿呼、合口呼、撮口呼
    • 舌根音 g k h 舌尖后音 zh ch sh r 舌尖前音 z c s 可组合开口呼、合口呼
    • 舌面音 j q x 可组合齐齿呼、撮口呼
  • 单韵母构成：
    • 原始韵母：非 i u v 单韵母 a o e er、前响复韵母 ai ei ao ou、非 i u v 开头鼻韵母 an en ang eng ong
    • 变形韵母：
      • y + 齐齿呼（除 yi yin ying 之外其他的都删 i）yi ya ye yao you yan yin yang ying yong
      • w + 合口呼（除 wu 之外其他的都删 u）wu wa wo wai wei wan wen wang weng
      • y + 撮口呼（v 改拼为 u） yu yue yuan yun
    • m n hm（感叹词），在计算中忽略，仅仅是列出
  • 舌尖元音自成音节：
    • 舌尖前音 z s c + i 、舌尖后音 zh ch sh r + i
  • 儿化音，在计算中忽略，仅仅是列出
• 9 键的 8 个拼音格子 abc def ghi jkl mno pqrs tuv wxyz

我们考虑的混淆只考虑一个拼音与另一个拼音的混淆，不考虑一连串拼音与另一连串拼音之间的混淆（拼音交界处的分词）。不考虑常用打字软件自带的模糊拼音处理和未拼完的前缀预测。考虑这样一个九键输入法：设按下键的序列为 $k_1,k_2,\cdots ,k_n$，任意一个键 $k$ 对应可选字符集合为 $\text{cand}(k)$，那么这个输入法显示的任意候选汉字的拼音（必须长度为 $n$） $s_1,s_2,\cdots ,s_n$ 必须满足 $s_i\in \text{cand}(k_i)$ 。我们称两个拼音是可以混淆的，当且仅当存在一个按键序列使得二者同时出现在其候选列表内。显然混淆关系在所有拼音构成的集合上是一种等价关系并且这种关系可以自然地拓展到所有字符串构成的集合。在后文中的部分地方为了叙述方便，我们将这种等价关系记为 $=$ 并舍弃其 Latex 语法。称一个拼音是不确定的，当且仅当存在另一个拼音，它们之间是可以混淆的。

记全体拼音集合 $\mathcal{P}$，对于任意拼音 $P\in \mathcal{P}$，假设其对应的汉字数（包括四个读音）为 $\text{count}(P)$。任取一个我们期待的汉字，取其拼音 $P$，其对应按键序列为 $K=(k_1,k_2,\cdots ,k_n)$，$K$ 对应的所有拼音为 $S_1=\prod _{i=1}^n\text{cand}(k_i)$，其中 $\prod$ 代表笛卡尔积的左结合连乘，对应的总汉字数量为 $\sum _{x\in S}\text{count}(S)$。对于二十六键来说，其是可以唯一确定拼音的，确定 $\text{count}(P)$ 个汉字。我们用 $\sum _{x\in S}\text{count}(S)/\text{count}(P)$ 来衡量所以九键相对于二十六键的膨胀的候选汉字倍数。实际上，应当考虑到日常中汉字被使用到的频率。To be continued。

• 单韵母构成的内部混淆
  • 不同元音前缀开头的原始韵母不可能相互混淆；不同长度不可能混淆。a ai ao an ang 有混淆 an=ao；e er ei en eng 没有混淆；o ou ong 没有混淆
  • 变形韵母只由 w y 开头。w y 不可能与元音混淆决定了不会与原始韵母混淆。y w 混淆，只需要观察剩余的介母 + 韵母 / 韵母部分。
    • 齐齿呼内部有混淆 yan=yao；合口呼内部无混淆；撮口呼内部没有混淆。
    • 齐齿呼和合口呼之间的混淆 ya=wa wan=yao yang=wang；
    • 撮口呼和另外俩的混淆，由于撮口呼的第二个字母都是元音 u，所以只能混淆另一个同长第二个字母为 u 的拼音。只有 wu=yu。
    • 可能混淆的一共 4 种包括 yu=wu wa=ya wan=yan=yao wang=yang
• 舌尖元音自成音节内部混淆：
  • z s c 的键位不同所以舌尖前音不会发生内部混淆，舌尖后音由于长度和 z s c 键位同样没有内部混淆。二者之间的混淆大多可以通过长度排除，仅仅有一种 ri=si。
• 舌尖元音自成音节与单韵母构成之间的混淆
  • 单韵母构成的原始韵母以 a e o 开头，舌尖前后音以 z s c r 开头，第一个字母仅仅有 c=a 这一种混淆，a ai ao an ang 和 chi ci 中能够形成完整混淆的只有 ai=ci。
• To be continued（本以为因为规则的复杂性，手数应该比写个程序快。。。）

CS162 的 HW0 words 的错误处理是一个很让人纠结的地方。这一点在此前的 coding 尝试中其实早已显现，只是一直没有找到一份所谓的 ”操作标准“。今日在 gemini 的老师的开导下终于大彻大悟。

"错误" 的来源可以分为三类：

• 与外部的交互中，外部提供的数据非法。注意 “外部” 和 ”合法“ 的界定范围都是相对于当前开发的程序的预期而言的。
• 程序设计者 ”粗心“ 造成的各种代码逻辑错误。
• 程序运行环境的限制，比如内存枯竭、硬件故障、操作系统约束等。

首先，对外部非法输入数据的筛选不属于 "错误处理"，因为非法输入是可以预见的，应当视为一种用户数据清理，是实现软件意图中必要的一环。

对于第二类，程序员写出的 Bug 的预防属于 "错误处理"。有两种设计哲学

• 契约式设计（Design by Contract）：函数开发者不进行参数检查，函数调用者负责遵守契约。只要调用者遵守契约满足前置条件，开发者就需要保证不定式和后置条件的成立。当调用者没有遵守契约，开发者不做出任何保证。
• 防御性设计（Defensive Programming）：我不相信任何人，我要检查所有输入。在开发阶段，一旦检测到非法状态，立即触发提示或崩溃，强制开发者在开发期间就解决掉隐藏的逻辑错误。

对于运行环境的限制的处理，也不应属于 "错误处理"。如果是软件检测不到的运行环境错误导致崩溃，那么开发者不用承担责任。如果是在软件应用范围内（需要划定一个预期的应用范围，忽略范围外的情况。如果最终需求超过了划定范围，归咎为软件设计者的失职），有机会进行处理却没有处理，归咎为程序员的失职。