Hypercube's Channel

https://cs-syd.eu/posts/2017-08-28-the-annoyance-of-twelve-hour-clocks I always use 24h time format. Everytime I think about how weird the way AM and PM work, something like the graph in this article appears in my brain, and I think "this is bullshit". But I never actually tried to draw it out.

Linux 的 bind mount 不是按路径的，而是按 inode 的，我今天才意识到。也就是说： mount --bind /tmp/a /tmp/b 这条命令会当场解析 /tmp/a，找到相应的 inode，然后一直把它挂载在 /tmp/b 这个路径下。如果之后 mv /tmp/a /tmp/c，/tmp/c 仍然会挂在 /tmp/b 下。而如果这个目录被删掉又重新创建了，新的同名目录不会被挂载。 当然这样设计确实有合理性，如果按路径的话很多系统调用的语义会出问题。但感觉如果不知道这一点的话，这样的行为可能会产生一些坑吧。

以前用 SQL 数据库时数据量一般都很小，以至于无论生成什么样的 query plan，查询都能很快完成（尤其是一般 web server 使用数据库的模式都很少涉及到多个表的 join，非常容易规划） 最近需要对比较大量的数据做复杂的分析，然后将结果画在 Grafana 上，所以专门调研了一番怎么优化查询，确保秒级完成。才发现原来对 join 的规划几乎是这里面最复杂的问题，而我以前以为很棒的 PostgreSQL 的 query planner 其实因为是通用的，对一些具体场景能做的事情非常非常有限，远远达不到想象中什么都能优化好的状态。 在有多个表需要 join 时，需要知道每个表 where 选择出来的大致行数，以及两两 join 起来后的大致行数，才能决定最佳的 join 顺序，以及每一步 join 要使用的算法。但行数的估计是非常困难的，如果对具体数据库的使用场景没有额外信息的话。PostgreSQL 默认做法是把表中每一列看作相互独立的，分别采样。规划时对每一列上的 where 条件独立计算概率，这对于列之间有依赖关系的情况就会有问题。用户可以手工创建一些采样指示，要求数据库对某几列合起来采样，但创建这种指示比较麻烦而且成本也高。 另外，即使能很好地估计每一个原始表的行数，要估计 join 结果的行数也是很困难的。在我的查询中，经常先把原始数据降采样成某个间隔等间距的时序数据（比如每行有时间和值两列，时间都是整分钟），然后把多个这样的序列按时间列 join 起来。PostgreSQL 没法知道这样 join 的结果的行数一定和 join 的各个表的行数相等（因为它们的时间列已经对齐了），有时会认为结果是笛卡尔积，有时会认为结果非常小。 基于这个现象，目前我发现的最大的优化措施是 set jit=off; 😂因为我自己知道我用到的 join 都是很容易做的，结果行数也不多，而数据库常常误以为结果行数是笛卡尔积那么多，处理起来需要小时甚至天量级的时间，然后认为有必要启用 JIT。JIT 需要数十秒，但在我的查询中不会带来什么回报。 另一个简单又有效的优化措施是多用 with 语法（common table expressions），并且为每一个这样定义的中间结果手工指定 materialized 或者 not materialized：如果只是简单的扫描型查询，但会输出大量数据，或者后续需要过滤它的结果，就指定 not materialized，以便 inline 进用到的地方并且一起规划。如果是昂贵的查询，并且产生很小的结果，就指定 materialized，以便后续直接使用结果。指望数据库自己知道每个中间结果该不该 inline 是很不现实的。 （为什么要用 SQL 数据库/为什么要用 PostgreSQL？因为据我所知别的数据库在很多方面更糟。尤其不推荐 InfluxDB，如果你想做需要 join 不同的数据才能实现的分析型查询的话。）

玩 CS:GO 刚好 5 年了😃

函数式编程中有一个概念叫 state monad，它将所有数据用形如 λs1.(s2,a) 的函数来表示，其中 s1 是某种旧状态，s2 是新状态，a 是计算结果。一个普通的数字 3 被表示为 λs.(s,3)，加法运算则可以定义为让两个参数中包含的状态变化依次发生，作为最终状态，并把结果之和作为计算结果： add := λx.λy.λs1. 令 (s2,a) = x s1 令 (s3,b) = y s2 (s3,a+b) 这样一来，所有不涉及状态变化的普通操作还可以和原来一样进行，但额外可以增加一些新能力，例如这个操作将当前状态加一，并把旧状态作为计算结果：λs.(s+1,s) 用这些原语可以写出复杂的计算过程，最终得到一个形如 λs1.(s2,a) 的结果，这个结果表示“一旦给定初始状态，就可以算出最终状态和一个结果”，换句话说，是描述了依赖于一个初始状态的一整个计算过程。 Haskell 用这种方法表示和真实世界打交道的 IO 过程。在 Haskell 中有一个特殊的类型，这里为了简化，不妨叫 World，它表示真实世界状态。从键盘读入一行输入的函数 readLn 的类型是 World -> (World, String)，向屏幕输出的函数 putStr 的类型是 String -> World -> (World, ())。这些 IO 过程都需要提供一个 World 才能运行，并且会返回一个新的 World，可以理解为“发生过某个 IO 过程后的世界”。多个 IO 过程可以这样一个接一个地串起来，最终变成 main 函数（它的类型是 World -> (World, ())），表示整个程序的运算规则。 但这个模型其实很有问题，因为 state monad 是支持这种能力的：做一些操作，把状态改变了，并且看到了结果，然后不要新状态了，返回最初的状态和刚刚看到的结果。真实世界中的操作虽然也可以视为不断转换一个状态，但这种状态转换是无法逆转的，用 state monad 来建模它会导致非常荒谬的结果，比如这个函数“假想”自己从键盘上读入一行，但并不真的改变世界状态，然后输出这一行： λworld1. 令 (_, s) = readLn world1 # 注意我们扔掉了 readLn 返回的新的 world putStr s world1 这并没有违反任何类型系统中建立的规则，也没有使用任何一般被认为是“不安全”（unsafe）的操作，所以这样的程序可以顺利通过类型检查并编译😂我以前都没有意识到这个问题，还觉得这套表示 IO 的方式真不错。 感觉应该寻找一种新的、更恰当地建模真实世界中不可逆的操作的方式，但我也不清楚它会是什么样。

https://en.m.wikipedia.org/wiki/Mogensen%E2%80%93Scott_encoding

代数类型中的值可以按特定的规则对应到 Lambda 演算中的函数，例如： Bool 有两个情况：True 和 False，都不需要参数。True 可以对应到 λonTrue.λonFalse.onTrue，False 可以对应到 λonTrue.λonFalse.onFalse。这种对应关系也是最广为使用的。 Pair 有一个情况，但有两个参数。Pair a b 可以对应到 λonPair.onPair a b。使用示例：构造一个包含 1 和 3 的 Pair：p = λonPair.onPair 1 3。从中取出第一项：p (λa.λb.a) Maybe 有两个情况，第一个情况叫 Just，有一个参数。第二个情况叫 Nothing，没有参数。可以令 Just = λa.λonJust.λonNothing.onJust a，Nothing = λonJust.λonNothing.onNothing。 推而广之，考虑到自然数类型 Nat 有两个情况，第一种情况叫 Zero，没有参数。第二种情况叫 Succ，有一个参数。可以令 Zero = λonZero.λonSucc.onZero，Succ = λa.λonZero.λonSucc.onSucc a。在这种定义下，0 = Zero，1 = Succ 0，2 = Succ 1，… 这个定义和常见的 Church numbers 并不一样，但似乎更好用（也和其他类型的映射规则更统一），因为这个定义使得模式匹配成为可能，然后很容易定义减一函数，只要先写出伪代码： Pred Zero = Zero Pred (Succ n) = n 然后翻译过来： Pred = λx.x (Zero) (λn.n) （第一个括号中是 onZero，第二个括号中是 onSucc） 很好奇这种把代数类型对应过来的规则叫什么名字，以及这样构造的自然数叫什么，可是随便搜了一会什么也没找到

补充一下，我的 QQ 和微信都已实名认证和绑卡，现在是要填写更多信息（住址、工作信息等）才能使用支付相关功能

微信似乎开始要求必须填写住址、工作等信息才能发红包或接收转账了

微信似乎开始要求必须填写住址、工作等信息才能发红包或接收转账了

https://youtu.be/txa5ia2w7-k biweekly 一周两次或两周一次 bimonthly 一月两次或两月一次 biannually 一年两次 biennially 两年一次 bicentennial 两世纪一次

Zuma 的最后一关叫 Space，会在通过第 12 大关后出现，一旦耗尽生命，必须重新通过第 12 大关才能重试。这一关需要在一张太空背景，看不到轨道的地图上，达到比之前的关卡都更多的分数才能通关。经过一段时间的练习，以及利用从第 1 大关一路过来积累的额外生命，我终于完整通关了。结束后会显示统计数据和 credits，真可惜没有 steam 成就。