最近用 3D 打印机做的两个东西。第一张是 5 个正四面体嵌在一起，这个我没在网上找到满意的模型，我要求不能打印出部件再组装，也不能打印出来是“焊死”的，5 个正四面体必须互相独立，能微微晃动。自己建模很容易，但很难打印好😂我学到了一些切片参数的调整要领。后两张是一种常见的玩具，但我一直不知道叫什么，似乎一个名字是 pin art。
👍7
几个月以来我玩 CS2 时一直有概率遇到游戏突然卡死的 bug，从每场比赛小概率发生 1 次逐渐变成每场比赛发生 4 次😂各种解决方案都没有用，而且玩其他游戏都没有类似问题。今天仔细研究了网上别人的经验后，打开垂直同步，问题终于解决！（推测原理为限制帧率降低了功耗）
arxiv 上极个别论文的 PDF 会在下载了一小部分后断开连接，这种情况似乎只出现在论文发布后一两天内，有问题的 PDF 会在一段时间里一直没法正常下载，直到随机某个时候变好。这个奇怪的现象一直在导致 https://paper.dou.ac/ 偶尔就有一天的论文列表发布得特别晚。
我终于找到了一个 workaround，能让论文列表再也不因此晚发布了。方法就是如果发现意外断连接，重新发断点续传（range）请求，加载剩下的部分。很可能需要发非常多次请求才能拼凑出整个 PDF 文件😂但总之不用等它随机变好了
我终于找到了一个 workaround，能让论文列表再也不因此晚发布了。方法就是如果发现意外断连接，重新发断点续传（range）请求，加载剩下的部分。很可能需要发非常多次请求才能拼凑出整个 PDF 文件😂但总之不用等它随机变好了
👍2
VS Code 中，如果文件内容是“a ab”，搜索“a|ab”，同时选中 Match Whole Word 和 Use Regular Expression 两个选项，居然只会匹配 a，不会匹配 ab。
（推测原因为 VS Code 实现成了先匹配，再过滤出 whole word 的结果，而不是在匹配阶段就考虑到 whole word 这个限制条件。）
补充：不开 Match Whole Word 的话，匹配的是 a ab。感觉这个也比较坑，会导致 http|https 只会匹配上“https”中的“http”。
（推测原因为 VS Code 实现成了先匹配，再过滤出 whole word 的结果，而不是在匹配阶段就考虑到 whole word 这个限制条件。）
补充：不开 Match Whole Word 的话，匹配的是 a ab。感觉这个也比较坑，会导致 http|https 只会匹配上“https”中的“http”。
kliksphilip 是我最喜欢的 YouTuber，我最近才意识到在我关注他的 7 年中，他一直保持了极高的内容质量和不错的多样性，不像很多其他频道火了后内容就变得单调和过于刻意，甚至是一个团队在按模板批量生产内容。我发现 kliksphilip 真心享受创作多样化的视频，就像他享受游戏开发、编曲、杂耍等活动一样。并且我发现我和他在很多人生经验和思考上是非常相似的，这直接导致我在这几年里也陆续尝试了视频制作、游戏开发、编曲、杂耍😂
我觉得这值得做点什么，所以把他的视频中最让我有共鸣的那些精选出来做了一个合集：
A 面：https://youtube.com/playlist?list=PLcao1uyoZ-6V3a1yE4t2PdKJR9TtGgtbh
B 面：https://youtube.com/playlist?list=PLcao1uyoZ-6WIDXShIfDS2yfroirjr9nX
我觉得这值得做点什么，所以把他的视频中最让我有共鸣的那些精选出来做了一个合集：
A 面：https://youtube.com/playlist?list=PLcao1uyoZ-6V3a1yE4t2PdKJR9TtGgtbh
B 面：https://youtube.com/playlist?list=PLcao1uyoZ-6WIDXShIfDS2yfroirjr9nX
👍3
当你看到“we made it 90% faster”，你会想到……
Final Results
43%
这个过程需要的时间缩短了 90%，现在是原来的 10% 了
37%
这个过程的速度提高了 90%，因此需要的时间变成了原来的 52.6%
20%
有歧义，就不该这样写
1👍2
关于“90% faster”我的一点思考：
这里有 3 个概念：工作量（或者距离、产量等）、时间、速度。前两者很简单，显然可以说增加或减少百分之多少。但“faster”这个词对应的是速度，因此我本来觉得逻辑上唯一有道理的理解是单位时间完成的工作量增加了 90%，也就是单位工作量需要的时间变成了 52.6%。
但然后我意识到这似乎并不是唯一有道理的理解。速度是工作量与时间的比值，还是时间与工作量的比值？我知道物理学上速度被定义成了前者，但这可能只是一个任意的选择？当我们说一个人跑得很快时，逻辑上来说我们是在说单位时间内跑过了很远，还是跑过单位距离只需要很短的时间？我觉得这两种理解似乎是比较对称的，速度也可以被定义为时间与工作量的比值，这种情况下越快的速度由越小的速度数值刻画，这种定义（虽然不符合物理学选择的约定）似乎更符合一般日常生活的直觉？
或许还是说“快这个概念本身就没法说变了多少百分比”比较好🤔
但然后我意识到这似乎并不是唯一有道理的理解。速度是工作量与时间的比值，还是时间与工作量的比值？我知道物理学上速度被定义成了前者，但这可能只是一个任意的选择？当我们说一个人跑得很快时，逻辑上来说我们是在说单位时间内跑过了很远，还是跑过单位距离只需要很短的时间？我觉得这两种理解似乎是比较对称的，速度也可以被定义为时间与工作量的比值，这种情况下越快的速度由越小的速度数值刻画，这种定义（虽然不符合物理学选择的约定）似乎更符合一般日常生活的直觉？
或许还是说“快这个概念本身就没法说变了多少百分比”比较好🤔
我觉得 iOS 这几个界面设计问题很大。
首先，极其相似的界面上，相同功能的按钮可以出现在不同位置，很影响快速辨认和肌肉记忆。尤其是这个界面会响，让用户有压力要尽快做出正确的选择让它不要响了。我每次点这个界面上的按钮都像是在开盲盒：“上次点中间居然是稍后提醒，要注意其实要点下面”“上次点下面居然是重复，要注意其实要点中间”
其次，下面的选项并不是非常特殊/不常用的，不需要同时用颜色、大小、位置来区别。两个按钮应当上下或左右并列，大小相同，只用颜色区分主要和次要动作即可。静态的信息和需要选择的行动也应该分开，现在这个屏幕上，中央既有信息又有行动，下面又有另一个行动，这种分组方式不好。
灵动岛的版本好得多，信息和行动分开了，行动也很直观，想让它彻底不要响了的话总是应该点叉，这个很容易辨识，3 种情况下叉按钮的颜色和位置也是稳定的。但为什么按钮的颜色和锁屏界面不对应？麻烦想清楚哪个是主要动作哪个是次要动作，然后保持统一。
首先，极其相似的界面上，相同功能的按钮可以出现在不同位置，很影响快速辨认和肌肉记忆。尤其是这个界面会响，让用户有压力要尽快做出正确的选择让它不要响了。我每次点这个界面上的按钮都像是在开盲盒：“上次点中间居然是稍后提醒，要注意其实要点下面”“上次点下面居然是重复，要注意其实要点中间”
其次，下面的选项并不是非常特殊/不常用的，不需要同时用颜色、大小、位置来区别。两个按钮应当上下或左右并列，大小相同，只用颜色区分主要和次要动作即可。静态的信息和需要选择的行动也应该分开，现在这个屏幕上，中央既有信息又有行动，下面又有另一个行动，这种分组方式不好。
灵动岛的版本好得多，信息和行动分开了，行动也很直观，想让它彻底不要响了的话总是应该点叉，这个很容易辨识，3 种情况下叉按钮的颜色和位置也是稳定的。但为什么按钮的颜色和锁屏界面不对应？麻烦想清楚哪个是主要动作哪个是次要动作，然后保持统一。
👍3
Forwarded from Hacker News 摘要
Telegraph
可能是一个严重的可能性
原标题：Possibly a Serious Possibility 在2025年5月3日，亚当·库查斯基发表了一篇文章，标题为《可能是一个严重的可能性》。文章探讨了冷战时期情报沟通中的模糊语言是如何影响决策的。故事的中心是1951年3月，时任CIA分析师的舍曼·肯特在讨论一份关于“1951年南斯拉夫入侵的可能性”的报告时，发现自己的措辞造成了严重的误解。 肯特在报告中使用了“应该被视为一个严重的可能性”这一表述，但他的上司和同事们对这个短语的理解大相径庭。一位政策规划委员会的主席甚至询问了肯特此语的具…
我也注意到这个问题还挺严重的，而且不限于表述概率，例如表述一些东西的质量时，“好”、“还行”、“一般”等词的含义也常常在对话双方之间有不同的认识。把词语的含义标准化成一些量化区间似乎不是好的解决方式，因为上下文就是很重要的。我常遇到的两种表达需求：
1. 表达一个事情发生的概率极其小（亿分之一到千分之一这种量级），对于当前目标来说造成的影响可以忽略，例如“有人一次就猜对了 6 位数验证码怎么办”。没有一个标准化词语对应这种概率，而且什么概率可以忽略也取决于具体业务情况。
2. 表达一个事情发生的概率虽然很小（1% 到 20% 这种量级），但对当前目标来说造成的影响是很大的。如果有人用英国这套标准化词语说我们网站有“remote chance”（0%-5%）或者“highly unlikely”（10%-20%）给用户显示错误的结果，我肯定不会理解为有 5% 甚至 20% 的用户受影响😂。我有时会说“这个功能会给很多用户显示错误的结果，当然这些用户占的比例数字是很小的，但是绝对数量上是很多用户了”。
当然了，在情报工作中，分析师可能不知道自己正在估计的一个概率对宏观目标的影响程度，这是情报使用者负责判断的，双方的上下文自然会有区别。“serious possibility”在我看来既有可能表示我们不能忽略这个可能性，要开始严肃地考虑它了（像是 30%），也有可能表示这个危险已经到了严重的程度（像是 70%）。除了故意用模糊的语言避免承担责任的情况，还是直接说数字吧。
1. 表达一个事情发生的概率极其小（亿分之一到千分之一这种量级），对于当前目标来说造成的影响可以忽略，例如“有人一次就猜对了 6 位数验证码怎么办”。没有一个标准化词语对应这种概率，而且什么概率可以忽略也取决于具体业务情况。
2. 表达一个事情发生的概率虽然很小（1% 到 20% 这种量级），但对当前目标来说造成的影响是很大的。如果有人用英国这套标准化词语说我们网站有“remote chance”（0%-5%）或者“highly unlikely”（10%-20%）给用户显示错误的结果，我肯定不会理解为有 5% 甚至 20% 的用户受影响😂。我有时会说“这个功能会给很多用户显示错误的结果，当然这些用户占的比例数字是很小的，但是绝对数量上是很多用户了”。
当然了，在情报工作中，分析师可能不知道自己正在估计的一个概率对宏观目标的影响程度，这是情报使用者负责判断的，双方的上下文自然会有区别。“serious possibility”在我看来既有可能表示我们不能忽略这个可能性，要开始严肃地考虑它了（像是 30%），也有可能表示这个危险已经到了严重的程度（像是 70%）。除了故意用模糊的语言避免承担责任的情况，还是直接说数字吧。
👍3