我也不太想结婚…… 嘛我也不太了解其他人不想结婚的理由，不过我可以说说我的。

理由总结起来无非就一个词语：没钱。然而深层分析这个词语，我和楼主对于没钱的定义可能不太一样。我对于“有钱”的定义，是可以无视所有因生计而带来的妥协，一辈子投身于我想做的事情，这种程度的有钱。量化的话，我觉得王健林的一个小目标，应该是能让我毫无顾忌地结婚的“有钱”吧。

然而我并没有一个亿。

不该想办法维护中间结果的表，降低每次请求计算量么

和朗道十卷以及前置数学知识比起来应该还是容易的……

介绍一些背景知识吧。

设有两台主机，A 和 B。即使 A 发起 TCP 链接到 B，A 也要本地打开一个 TCP 监听端口，并且告知 B 回信数据包发到这个端口。一般而言，如果是客户端应用，A 上面跑的程序不需要指定这个监听端口是什么，由操作系统分配一个空闲的端口。这样的临时分配端口，可以参见 https://en.wikipedia.org/wiki/Ephemeral_port

在你的例子里面，链路是 A -> R -> B，其中 R 是路由器。由 A 发起的 TCP 链接携带了这个 A 的临时端口信息，被 R 看到。R 重写了发给 B 的包，重新分配了它自己的一个临时端口，把 R 的外部临时端口告诉 B，并在状态表里面把这个外部临时端口和 A 的回路端口进行关联，那么 B 发回给 R 的数据包会原路返回 A。直到这个 TCP 链接被关闭，这个 R 的临时端口和 A 的临时端口才会被关闭，状态表项被删除。这就是 NAT 技术。

DMZ 就是把所有不在这个状态表里面的端口接收到的数据，统一发给某个 R 下面的局域网主机。这台主机就是 DMZ 主机。
====

回到你的问题。理论上，UDP 和 TCP 类似，也可以采用相同的 NAT 技术。然而，UDP 没有链接状态。所以 R 无法根据 TCP 链接断开这个信息及时删除状态表，而只能靠猜（比如超时）。因此实现难度比 TCP NAT 要高。因为这些原因，也许一些廉价路由对 UDP NAT 的支持不是很好。。。

要用 python cuda 的话，那就只能 ubuntu 主机 win10 虚拟机了

@lc7029 事关安全，不扔等着过年?

看视频用啥 pro。。我那 pro 拿来看论文看书的，配合 apple pencil 做笔记。

我用 Ansible 安装各种服务器。

https://codecraft.co/2014/11/25/variadic-macros-tricks/

虽然我觉得整这么复杂没意义

愿意女装的话，大把角色……

配置文件，Node 系直接用 .js ，其他系用 YAML。

数据交换（ API ），根本不需要这么复杂的功能。

结论：毫无意义。

@okwork 用 Word 写大量公式才会疯掉 +1

我是说立刻返回结果给用户不合理。

因为这样可能导致大量用户得到了正反馈，然而你其实一个都没执行完。。。

loop.create_task

但你这么做不合理

@favourstreet LaTeX 标准就是不换行。

说到底换行以后应该怎么对齐比较好看？都是靠人肉的。

\begin{align*}
...
\end{align*}

那么问题来了，同步设置到哪里?

对象一复杂，formdata 你就哭吧

USB2.0 接口的速度

过一遍就行，不用过两遍。

https://ideone.com/dG4D2l