拼音词典的野路子
比如 王二姐 的 拼音是 wangerjie ，查词典时用下列字符串都要能找到：werj wangerj werjie
我们可以建个这样的目录树：wang/er/jie，然后用shell提供的glob去找 w*/er/j* 下的 所有文件，其中一个叫 王二姐 。
~$ md -p wang/er/jie ~$ touch wang/er/jie/王二姐 ~$ l w*/er/j* -rw-r--r-- 1 user user 0 11月18日 00:47 王二姐 ~$ make love make: *** 没有规则可制作目标“love”。 停止。
当然是开玩笑。首先每个目录/文件占了4KB，其次问了半天AI有无高效GLOB算法，它总免不了
for s in strings
为了touch 王二姐 强行举了个例子，起码可以把词们放在words.txt里么。
fd is a 用Rust写的 program to find entries in your filesystem. It is a simple, fast and user-friendly alternative to find.〔github〕
- Regular expression (default) and glob-based patterns.
- Very fast due to parallelized directory traversal.
- ...
Let's search my home folder for files that end in [0-9].jpg. It contains ~750,000 subdirectories and about a 4 million files.
find耗时约20秒；fd约0.9秒。
我觉得vector<string>还是不快。勤reserve可能好些。
这样呢？每个音节定长6个字母，如"chuang", "wang--", "er----", "w?????" AI写不出针对这个的二分搜索。
二分下再往两端找找？jj这样的反正要返回全部。好像不行，因为词不“扎堆”。还是trie吧，如ajmd要能查到阿基米德螺线。
我以前用整数来表示音节，用了点位操作。这个没啥意思，比较low.
推箱子我想不出启发函数，不过好像也没人想了出来，起码深度学习三巨头不研究这个。研究出来了“有如禽兽”，出不来“禽兽不如”，怎么都不划算。
如果微信输入法好用，那是因为电脑快，如果不好用，那是“禽兽不如”。:-)
有“四角号码”，可以有四数拼音么，print时方便。
带声调的拼音输入法没有流行起来，重码少很多啊。如果用00~99表示韵母和部分声调，从幼儿园开始强迫学…
也许还可以用SQLite的FTS5来检索匹配度最高的“文档”。
总之，做输入法不是不费吹灰之力的事，但涉及到的技术么，有更高档更专业的。
想输入ym 野猫 在 吖马 吖嘛 吖猫 吖妹 里翻半天？
还以词多为美？比如j 100个汉字，jj 100*100=1万，其中800个算词，还不如选字快呢。
和30年前的微软拼音整句输入相比，我简直怀疑如今做输入法的技术倒退了。
我幻想：转换正确率高到了默认显示首选汉字，拼音串不显示（或小字体低对比度）的程度。应用程序告诉输入法光标之前的汉字（串）是啥（考虑用户移动了光标）。
输入zu guo de z 出 祖国的壮丽山河？这才配叫智能吧？华宇拼音输入ajmd会出阿基米德原理和阿基米德螺线。
但我想说的是：在词库里没有阿基米德原理和阿基米德螺线的情况下预测。
好像#include <regex>后，程序的编译速度就慢了很多，用上预编译头文件效果也不明显。
/usr/include/c++/12/tr1/regex 2727行
/usr/lib/llvm-14/include/c++/v1/regex 6833行
但clang++比g++编译起来快一点点。
有些单头文件项目有点鸵鸟（头文件很长）。可能把#include <regex>的放在一个源文件里，定型后每次link它的.o才是最快的方式。
问AI RE2是Google开源的正则表达式库。在都编译了正则表达式的情况下，比C++ 11的regex快么？快多少？有实测数据么？
节选它的回答：
- 根据参考信息，在都编译了正则表达式的情况下，RE2 通常比 C++11 的 std::regex 更快，但具体的性能提升幅度取决于具体的正则表达式模式和使用场景。
- RE2采用确定性有限自动机（DFA）实现，避免了传统回溯引擎（如 PCRE、Python 的 re 模块）在复杂模式下可能出现的性能灾难（如指数级时间复杂度的“回溯爆炸”）。其最显著的特性是保证匹配时间线性于输入字符串的长度。
- C++11 的 std::regex 是一个功能完整的正则表达式引擎，支持复杂的特性（如回溯、环视等），但这也意味着其实现更复杂，性能开销相对较大。虽然 std::regex 在编译后可以重复使用，但其底层实现（通常是基于 NFA 的）在处理某些复杂模式时，性能可能不如 RE2 稳定。
- 对于动态正则表达式（如 std::regex），每次构造对象时都需要解析和编译模式字符串，这会产生显著的延迟。在 less_slow.cpp 的基准测试中，std::regex 的编译开销约为 2000 纳秒。
- 在长文本匹配场景下，std::regex 的单次匹配耗时约为 22 微秒。
- 如果您需要处理大量数据或对性能有严格要求，RE2 是一个值得考虑的选择。
一般来说，Google不会无缘无故做个啥。它开源的是自己需要的工具。它做RE2，一方面是数据本身海量，另一方面可能是高层次的low: 想不出更高档的算法，只好提高正则匹配的速度（按照这个强词夺理的说法，造CPU也low）。
AlphaGo处理的是19x19，这里 有些巨大的。
很久以前，在地铁上听到A女问B女干啥呢，B女作顾盼自雄or羞涩状，答曰：写circle呢。
我心中暗笑她把SQL读错。刚才问了下AI 正则表达式 环视、反向引用的例子，还有SQLite可以做Full Text Search，
笑自己正则和SQL都不会啊。干点啥能不闲置大显示器呢？
浙公网安备 33010602011771号