从符号上推测诸 y_i 是数（投影的长度，带符号），然后 y_i = x_i^T u 右边是列向量的转置乘列向量，即 1x1 矩阵。虽然我个人觉得把 1x1 矩阵和数等同会带来很多混乱，但这似乎是习惯了。

注意数和数相乘，就是数和自己的转置相乘，因此 (x_i^T u)(x_i^T u) = (x_i^T u)^T (x_i^T u) = u^T x_i x_i^T u ，这就是最后一个等号，其目的大概是提取左右公因式 u^T 和 u 。

os.walk 没有定义顺序，因此不存在一个特别的顺序，你可以先把所有的结果拿出来，再自行排序。

很可能 os.walk 的实现就是调用文件操作的 API ，通常这个 API 不容许任何复杂的排序逻辑。

例如，Windows Explorer 里面的排序就是 explorer 自己做的。

@ColorfulBoar #10 🤔 我是不是识别出来你是谁了？

@mgrddsj #13 DRM 防截图在 Windows 上就是 app 告诉 Windows 在截图得时候阻碍自己被截图，即 @crab #16 说的那个 API ，就行了。并且不存在“DRM 实现不好得电脑”，只存在“DRM 实现不好的软件”。

远程桌面可以绕过这个 API 的限制，和虚拟机一样，在客户端（宿主机）截图的时候，远程桌面客户端（虚拟机程序）不会通知服务器（客机）。我并不知道 Windows 8 以来用来测试的 nested session 版远程桌面（即提供 Windows 应用商店应用开发时模拟器测试的基础设施）是否也能，不妨一试。

@v2genesis #5 您的 could have 翻译更符合汉语习惯，赞！

DeepL 的翻译错误，是方式的数量而不是数据的数量。正确的解析是

主语 Posterior probabilities
谓语动词 state
宾语的中心语 the relative numbers
宾语中心语的修饰 of ways
修饰 ways 的关系从句
- 从句主语 each conjectured cause of the data
- 从句谓语动词 could have produced
- 从句宾语 the data

后验概率描述每个所猜想的（被观测到的）这些数据的产生原因可能产生（被观测到的）这些数据的方式的相对数量。

每个所猜想的（被观测到的）这些数据的产生原因可能产生（被观测到的）这些数据 = each conjectured cause of the data could have produced the data
方式 = ways

用设问，可以说

In how many ways could each conjectured cause of the data have produced the data?
The numbers of ways are stated by posterior probabilities.

@ysc3839 #7 这是不行的，因为通知区域图标关联的窗口可能是高权限进程（或者另一个非管理员用户的进程），窗口消息仍然可以送达（ Explorer 有 UIAccess ），但 Explorer 无权访问该进程。此外关联窗口可以变更，要恰当实现等待进程结束还是挺复杂的（需要用 WaitForMultipleObjects 技巧）。

首先，那个东西叫“通知区域”，不叫 tray 。即使你认为 tray 来自于早期代码里的命名，tray 也是指整个任务栏。

这个问题的成因是通知区域图标是程序通知任务栏创建的，崩溃时程序没有通知删除，所以不会立刻消失。

鼠标放上去会消失是因为 Explorer 会给图标对应的窗口发消息，如果窗口句柄已经无效，则会删除图标——注意窗口句柄是 USER 句柄，因此既没有计数也会复用，在极限情况下可能新程序被分配到已经崩溃程序使用过的句柄，导致新程序莫名其妙收到消息。

Explorer 崩溃重启后程序需要重新添加图标，获取这一信息的方法是注册“任务栏创建好了”消息。

为什么不能轮询——因为不存在一个“心跳”消息，也不应该随便给窗口发送消息（虽然理论上可以注册一个新名字，这样任意窗口都不会对该消息有特殊反应才对），也不应该轮询（性能问题）。

这个问题显然是可以解决的，比如任务栏上列举窗口的按钮可以对崩溃立刻作出反应，这个变化是 USER 监控，并发送 WM_SHELL_* 消息给任务栏的。然而通知区域图标并不是 USER 概念而是 shell 概念（只存在于 explorer.exe 进程中），虽然可以提升到 USER 概念实现之，估计是不值得吧（ USER 是 per-session 级别的，可以容纳的句柄数量也相当有限）。

更好的解决方法是——不要崩溃。

类似的问题也存在于 Application Desktop Toolbar 。还有更多设计 bug 导致 shell 的一些部分需要两次操作才能刷新（ COM categories 、shellnew 等）。

@Youngsun #16 iOS 和 Android 都可以是平板电脑操作系统。

虽然不是期望的解决方法，但是为什么这么多人认为要远程桌面客户端必须是 PC ？可以是 iOS 或者 Android 啊。

正经的解决方法是虚拟机，为了提升效率可以采用启动到虚拟磁盘。即使不用虚拟启动，也可以为朋友建立主机上的另一个账户，然后另一个账户自己用虚拟机。

注意双系统是不能实质上解决问题的，这是因为对文件系统的权限保护是操作系统进行的，因此在 A 系统里具有管理员权限的用户自然可以任意修改 B 系统的内容。表面上解决问题是没问题的，只要 A 系统不要给 B 系统的分区分配盘符也不要挂载到目录上（ B 对 A 亦然）即可阻碍大多数程序（刻意或无意）修改另一个系统。

在干净的 Windows 上建立受限账户，可以保证受限账户不能影响其他账户。然而如果受限账户以管理员身份运行另一个程序，那相当于用了管理员账户，自然可以修改操作系统进而影响所有用户。

关键词是 fairness 和 guaranteed output delivery 。

@Jooooooooo #10 关键词是 succinct proof 和 delegation of computation 。验证计算正确所需要的时间可以远远小于执行计算本身所需要的时间。

可能 Chrome 只支持 directory 而不支持 folder ，试试选择 C:\Users\<用户名>\Desktop 这个 directory ？

@liuidetmks #14 那么你不应该用“签名”，因为签名的最基本功能是让只有特定人才能产生有效签名，这里没有类似的场景。你可以用 #4 提到的 Hashcash ，通过恰当设置 scheme ，可以让长时间算不出来的概率可忽略，从而在一切现实场景下都不是问题；也可以用 #5 提到的 verifiable delay function 。

实际操作里非密码学方法更常用，比如用业务逻辑限制访问频率。

“耗费 1G RAM” “不影响用户体验”

如果你想要计算需要大内存，你需要寻找 memory-hard function ；如果你要时间长，则需要 time-lock puzzle 。

通常来说产生签名的人需要知道特殊的内容（ key ）。在楼主的场景下，验证签名的人因为有所谓的“快速验证”，所以知道（另一个）特殊内容（ key ）也算合理。但我没有明白搂住想要解决什么问题。

@Newyorkcity #4 提示“快慢指针”之后就应该自己搜索了。

#6 什么叫“这类”？
返回数组里第一次重复的索引本来就很自然地可以 O(1) 空间。

利用原来编码的冗余空间（比如这里是 32 位整数只用来表示 1 到 10000 ）的算法是比较作弊的方法，本质上还是（额外）空间 Omega(n) 的算法。

此题的标准做法是快慢指针

支持一下，我之前想要用 OneNote COM API 做些东西，但是感觉它的 marshal 有 bug 🤣 （见 https://github.com/GeeLaw/onenote-object-model ）

https://stackoverflow.com/questions/45991094/which-part-of-the-c-standard-allow-to-declare-variable-in-parenthesis

另外声明语句优先于表达式语句也会造成传统的 most vexing parse 局面。

你的每对报错 /可以编译的例子里，都是一个只能解读为表达式语句，另一个既可以解读为表达式语句，又可以解读为声明语句，然后声明语句优先，但是无效。