你需要的关键词是 vertex connectivity 。这个问题可以用（数次调用）最大流—最小割算法解。

@yjim #22 见 https://www.zhihu.com/question/334099609/answer/744530484 这里的照片，或者 https://www.zhihu.com/question/19627126/answer/38549201 （我自己的答案）。

> “因为运算符紧密，所以优先级高。”这是我第一次听见有这么个说法

这件事情就是自然现象而已。

>，请问阁下是研究数学的博士生吗？不知道您如何看待这篇文章 https://math.berkeley.edu/~gbergman/misc/numbers/ord_ops.html

我是否研究数学和我使用的数学记号没有必然联系，这个问题也不是数学研究的范围。

我的习惯是加减乘除都是左侧结合，乘方是右侧结合，运算的优先顺序是 连写乘法 > 乘除 > 加减，因此 a^b^c/de/f 的意思是 (a^(b^c) ÷ (de)) ÷ f 。

你引用的文章同时讨论了好几个问题，例如用 / 表示除法（对比分数线）是否改变结合顺序以及“没有分开的字母”（即我说的“紧密”）是否引起更高的优先级。

我的印象里，中学教科书教整式（多项式）的部分明确表示 AB ÷ CD 的意思是 (AB) ÷ (CD)。

“连写”的“结合”比二元运算符紧密，因此优先级高，从排版也可以看出来，连写的运算数之间没有多余的空白，但普通二元运算有多余的空白。

当然，除这种题目单纯为了考这个知识点就没有必要了，考试中属于坏题目，作业中属于可以的题目。

@yjim #6 您看起来混淆了“等号”的含义，

A = B

的意思是 A 和 B 两个字符串所表达的东西相同，并不是 A 和 B 在任何其他字符串里可以互相替换的意思，很明显 1 + 2 = 3 但是 1 + 2 × 3 不等于 3 × 3 。同理 0.5x = 0.5 × x ，但两者并不可以做字符串替换，如 sin 0.5x 是正确的，但 sin 0.5 × x 是不可理解的（应该写 x sin 0.5 或者 sin(0.5) × x 或者 (sin 0.5) × x 之类的）。

@yjim #10 “公认”并不是教材编写的标准，世界各地“约等于”符号是不同的，但是教材仍然可以教“约等于”是 ≈。过了中学阶段几乎不再有人用“整式”这个词儿了（总是使用“多项式”），但这也不妨碍中学教学中使用“整式”。

看文档就知道了，LiteralPath 可以 ByPropertyName 而且有别名 PSPath ，而 PowerShell 的 provider 返回的对象都用 PowerShell 扩展系统增加了 PSPath 属性。

传入 Path 是错误的，，当然不能认为传入了 Path ，因为中括号既是合法文件名也是 PowerShell Path 字符串的通配符，这会导致带有中括号的文件名解读错误。此外 Path 的性能也不如 LiteralPath 。

除了看文档，搜索也可以解决这个问题 https://stackoverflow.com/questions/57456944/nonexistent-literalpath-property-of-system-io-fileinfo-object-bound-to-parameter

卖的时候就没收的钱在会计上就不存在，商品进价 500 ，用银行存款买，推荐零售价 1500 ，实际以 1000 售出，收的现金，那么会计分录是这样的（先忽略税的问题）：


借 库存商品 500
贷 银行存款 500


借 主营业务成本 500
贷 库存商品 500

借 库存现金 1000
贷 主营业务收入 1000


如果退款，当然是反向。

不谈物理，我想到了上古时代（可能是我做梦梦见的）如果把 DirectX 区域用 Print Screen 截图再粘贴到画图里，可能会导致粘贴的部分是动态的，被 DirectX 渲染而且随着控制 DirectX 渲染的软件画不同的内容，画图里已经粘贴的（理论上我们认为是静态的）图会跟着变化。 🤣

另外为本地账户关联微软账户的方法有两种：一是在设置应用里管理本地账户时选择“使用 Microsoft 账户登录”，这是明显的；另一种是登录 Microsoft 账户 SSO 的时候 Windows 推荐你使用微软账户登录，这是不明显的，随意点过去就会关联。

@gitignore #10 关联微软账户的本地账户只有第一次登录需要联网（我不太记得在未关联的账户里关联之后是否算做已经登录过，但我的想像中应该算的），之后断网的时候可以用最后一次本地知道的密码登录。你看到欢迎屏幕持续转圈可能是已经登录成功但是 explorer 在准备。此时要检查是否登录成功，可以反复按 Ctrl+Alt+Del ，如果出现“Windows 安全”对话框（其中的选项包括锁定、切换用户、打开任务管理器之类的），则说明已经登录成功，在等 shell 准备，否则就是没有登录成功。

这个问题很好，下面是我的想法。

1. 异侧还是同侧？

别人发的、自己发的分别在两侧似乎仅适合窄界面（例如手机）。Windows 上的 Telegram 会根据宽度决定布局——如果聊天面板不够宽，则自己发的显示在异侧，否则显示在同侧。

2. 为什么要异侧？

异侧显示可以增加“发件人是谁”的视觉提示。窗口窄的时候异侧显示不会带来“行定位”的困难。

3. 为什么不异侧？

窗口太宽的时候，异侧显示在连续阅读历史时眼睛很累——需要不断切换方向，并且太宽的时候“找异侧的下一行”很困难。

4. 为什么其他人发的在左侧，自己发的在右侧？

这和文本的渲染方向有关系，中文、英文横排是从左到右书写，用户最需要的是阅读他人发来的消息（因为用户通常还记得自己发的消息是什么），设计上应该降低这件事情的难度，他人发来的消息的开头永远在窗口左边（阅读时一行开头的位置），非常容易定位——相比之下，用户自己发的消息的开头处于窗口中间，而且具体是中间的哪里和消息长度有关，定位起来稍微费力一些。

此外，“发送”按钮也在右侧，如果有发送动画，那么输入消息的文本框会移动到消息历史里的位置，此时移动到左边不如移动到右边（刚刚点击的按钮所在的位置）自然——即“局部性”（对右边进行了操作，自然希望效果出现在右边）。

阿拉伯文、希伯来文等横排从右到左书写的语言里，自己发的消息会显示在左边，其他人发来的消息会显示在右边。因为这些文本的用户每行是从右边开始阅读。

很有上古时期 Flash 做的模拟 UI 的内味儿

目前的实现是必须消耗能量的，因为计算过程不可逆，会擦除系统中的信息，根据 https://en.wikipedia.org/wiki/Landauer's_principle 这需要能量（会放热，即转换为内能）。

能量除了热损耗（变成内能）还可以暂时储存在元器件里面。

因为 C 的缘故，void foo(char x[10]) 和 void foo(char *x) 是一个意思。要传递数组引用而不是指针的话，应该 void foo(char (&x)[10])。

不太确定 OP 在期待什么。公司的电脑是公司控制的，公司可以不间断查看你的内存，那么 Chrome 记录不记录也没什么区别，你能做的就是不使用公司电脑做不能让公司知道的事情。

>反贼回复的指令和丞相的相反

这样的反贼过于友好了。

>如果进攻指令数过半数，就会进攻

这并不是惟一的策略。

您描述的并不是 Byzantine 将军问题，Byzantine 将军问题的设定是：

1. 反贼和其他人通信的时候可以 **任意使坏**，比如和一个人说进攻，和另一个人说撤退；
2. 忠臣最终需要统一决策，不能一个忠臣进攻，另一个撤退；
3. 如果将军是忠诚的，那么忠臣的决策和将军一致。

只会说反话的反贼是很弱的。

@julyclyde #34 CR 的作用是“回车”，也就是把光标移动到行开头，在 CR 之后继续打印，自然会踩踏先前的内容。理同 ab BKSP cd 看起来是 acd 一样。

@julyclyde #14 然而你的这个想法和 #3 体现的想法是矛盾的，如果你认为 curl 应该“按文本”输出，那也和 GitHub Web API 输出的是 CRLF 还是 LF 没有关系，因为此时你认为的 curl 的行为会让用户无法感知 HTTP 传输的到底是 CRLF 还是 LF 。

@julyclyde #11 是你对 shell 的期待有误，Unix 风格 shell 的管道完全是二进制的，任何对数据的解读都是程序完成。

Re: “OP 的假设就被推翻了呢”
为什么你会觉得 OP 的假设是自然的？那明明是《我比 GitHub 做 Web API 的员工更懂 HTTP 之口嗨 Windows 用户真时髦》最新一期。

@julyclyde #3 curl 不参与编码解析，自然是 HTTP 给什么就返回什么，否则（若是 curl 参与编码解析的话）你把 curl 传入管道的时候会出现非常糟糕的状况。