类比一下大学的（连续）数学。

如果你想学会如何计算导数和积分（知道实用算法是怎么跑的），那么随便看看各种科普文章，自己动手写写代码就 OK 。

如果你想学习实变函数（学习可证明安全、密码分析），那么需要看密码学教材。不需要先学习实用密码学算法也可以学习这个。

我主要学习可证明安全，启蒙教材是 A Graduate Course in Applied Cryptopgraphy （ Boneh 、Shoup 著）。

用隐函数定理理解也很简单，考虑 f(x, y) 在 g(x, y) = 0 约束下的极值。

假设极值点邻域内 g(x, y) = 0 可以显化为 y = y(x)，则在这一点
h(x) = f(x, y(x))
具有极值，因此 h'(x) = 0 即
f_x(x, y(x)) + f_y(x, y(x)) y'(x) = 0.
注意 n = (1, y'(x)) 是隐函数在该点处切线的法向量，隐函数求导定理表明该向量和 grad g = (g_x(x, y(x)), g_y(x, y(x))) 正交，而 grad f = (f_x(x, y(x)), f_y(x, y(x)))。
也就是说 n 和 grad g 、grad f 都正交，因此 grad g 和 grad f 线性相关。

考虑乘子函数 F(x, y, k) = f(x, y) + kg(x, y)，可以看出 F 仅当 g(x, y) = 0 且 grad f 、grad g 线性相关时有驻点，因此可以通过研究 F 的驻点研究 f 在 g=0 约束下的极值。

@xiaokongwu #16 浮点数是指对于数 X*B^Y 直接存储了 X 和 Y 的格式，且两者没有必然的绑定关系，在一定范围内可以独立变化。double 和 float 也都是存储了 X 和 Y 。如果你说的格式里 Y 被 X 决定，则不是浮点数。

BigDecimal 的开销主要不在于它是个 object，而是在于它可以达到任意精度，即使去掉 object 的 overhead 仍然不如 double 高效。另外 BigDecimal 看起来是可以根据需要变化自己的长度的，而 primitive 常常是定长的，因此 Java 的模型下它必须是 object 。

可以参考 CLR 的 System.Decimal，这是一个定长的十进制浮点数，但范围和精度也当然都是固定的。

另外你怎么就知道 BigDecimal 计算没有精度问题呢？根据文档，BigDecimal 是十进制浮点数，它不能精确表达 1/3 。

今日震惊小知识：你说的那种 decimal 也是浮点数。

浮点数和定点数是表示某进位制下有限小数的方法，然而楼主的问题和浮点不浮点没关系。
有限长度，无论什么编码都不能精确表达所有有理数；长度无上界时可以高效、精确表达所有有理数；不需要高效的时候可以表达所有可计算数；然而无论如何都无法表达所有实数。

很多场景不需要精确，但需要速度，所以采用简短但不精确的表达。它的意义在于够用。

@natsukage #4 很可惜，似乎 MS Todo 不支持跨 tenant 共享 https://techcommunity.microsoft.com/t5/microsoft-to-do/sharing-lists-with-others-outside-your-organization/m-p/1103759/page/3 所以暂时是无解了

不能，如果你用 federated sign-in，然后用了你的 Exchange Online 邮箱，它怎么知道你想使用的是微软账户的 identity 还是 Exchange Online 的 identity ？

即使你可以设置微软账户的别名为 Exchange Online 邮箱，你也拥有的是两个账户而不是一个账户，只是这两个账户有同一个别名。

让两个账户成为同一个账户的话，你不再续订 Exchang Online 会有什么情况？你想关闭 Microsoft 账户会有什么情况？你的使用受到 Microsoft 账户 ToS 还是 Exchange Online ToS 的约束？这本质上和你说“我希望我的微软账户和苹果账户是同一个账户”一样，你可以把 Microsoft 账户想象成一个特殊的 Office 365 tenant，因为任意两个 tenant 都可能是不同公司控制的，自然不可能自动有跨 tenant 的合并功能，否则数据归属就乱套了。

@geelaw *刘盼到一半 => 浏览到一半

上拉加载似乎是标准功能，就是一个超长列表只有在用户快到底部时才获取靠后内容。

下拉刷新，即用户滑倒顶部继续上滑时加载新内容，是 Britcher 的发明，最先出现于他个人开发的 Twitter 客户端，现在是 Twitter 的专利（无偿授权）。

标准的结合用法可以总结如下：app 的界面是用于观察一个只能在头部追加的链表用的，用户进入 view 时获取了该链表的快照，具体来说就是头节点。
app 从头节点开始遍历，把链表的每一项从上到下放置在 view 内，由于列表很长，可以只加载几屏幕的内容，用户上拉接近底部后继续放入更后面的项，当然也可以暂时删去已经过于靠上的内容。这可以一直进行到整个链表的快照遍历完毕。
当用户回到顶端后继续下拉、明显溢出时，理解为用户想要看（原先）头节点前面的内容，由于已经过去一段时间，所以原先的头节点可能不是现在的了。下拉刷新就是获得新的头节点并展示原来头节点以前的内容。这个逻辑和刘盼到一半往回是一样的，本质上都是让用户可以在（实时更新的）链表上前后移动。

这套逻辑最原教旨的用法里，刷新后不一定非要到新头节点，如果产生了很多新内容，从原来的头慢慢往前是最连贯的做法。当然实际情况很可能是一下蹦到最新的头节点。

微博的浏览界面不是按照时间排序的，所以这个链表的逻辑不适用，微博既可以下拉加载也可以上拉加载，可以认为是不断用新内容填充 view，至于新内容填充在哪里全凭用户怎么拉。（我不确定微博是否是这样安排内容的，可能它有更复杂的逻辑。）

另一个有趣的事情是我发现 Twitter app 的内容其实很短，可以很容易拉到底部（它不再加载更早的内容），也可以做到拉到顶部刷新后没有什么新内容。另外 Twitter 似乎也不全是按照时间排序的。

首先，CSS 的 1px 并不是对应显示器上一个最小可改变颜色的单元（即实体像素）。例如对于 200% DPI 的情况，浏览器默认会把 CSS 1px 对应为显示器上的 2px，于是 CSS 0.5px 对应显示器上的 1px 。通过有级别缩放可以调整对应比例，能放大自然也能缩小。

其次，即使 CSS 1px 对应显示器 1px，浏览器也可以采用超采样来反走样，比如需要渲染 10px 宽、1px 高的矩形，其中上 0.5px 是黑色，则浏览器最终可以让显示器显示 10px 宽、1px 高的矩形，其颜色的灰色。

尝试改变例子可能会起到反作用。

如果工具知道自己应该被谁使用，那么 ITool 可以有一个 CreateToolUser 方法。

@yangyaofei #6 您似乎混淆了方向导数和高阶导数。

@siyemiaokube #7 这里的问题应该对应高阶微分，即是要问为什么各个二阶偏导数组成的双线性形式就对应二阶微分里的二次形式。二次形式总是用对称阵描述，而双线性形式不一定。马后炮来说，从美感上讲应该有这件事成立，即双线性形式 A 就是它对称化的结果 (A+A')/2 。

这件事情对于“可分解”多元函数自然成立，所谓“可分解”二元函数，是指形如 f1(x)g1(y)+...+fn(x)gn(y) 的函数，其中各 f 、g 都可导，先对还是后对 x 求导数没有任何区别。

多项式函数就是“可分解”的，把多项式转换为幂级数，则可以看出此性质对多元解析函数成立。

实际情况是它对足够好的函数都成立，Peano 的版本是：如果 Dx 、DyDx 、Dy 在开集里存在，DyDx 内点连续，则 DxDy 存在且和 DyDx 相等。

在“好的函数”的世界里，各种操作可以换序是常态。

可以看到

为什么会觉得是 2038 问题？ Windows 自带的时间数据类型可以支持至少 30000 年，从 VS 2003 开始 time_t 就默认是 64 位了，很难相信微信还在用 32 位的 Unix 时间。

另一个问题是为什么就能确定是企业微信的问题。楼主也没说控制变量的尝试结果是怎么样的。一个很容易想到的理论是：因为时间改变，几乎所有的证书都失效了，从而导致各种代码验证失败（包括本机 Windows 程序的数字签名以及 TLS 证书等）。

@Tony042 #4 这里需要的是 ctor 不是 operator=。

@xuegy #2 因为 https://en.wikipedia.org/wiki/Most_vexing_parse
但比较奇怪，一般来说用 = 初始化不会有歧义问题，反而是用函数调用初始化容易有“最烦人的解读”。

这个东西是朴素的广播加密，也算不得“上当”。

在多个用户自行生成密钥时，更巧妙的工具叫做临场广播加密（ ad hoc broadcast encryption ）。

是有更多“临时对象”所以才慢。定量考虑的话，join 需要 N 的时间时，朴素累加可能需要 N^2 的时间，我能想到的最快的累加也可能会需要 NlogN 的时间。

什么叫做“自己实现 join 的功能”？

如果你要求相同的时间复杂度且不能用 Python 的 join 恐怕不行，因为 join 是 Python 自己实现的，可以想象它先算好最终长度，然后分配内存，最后写入数据。

如果只是希望实现相同的功能，不论时间，则用平衡分组连接比较好，这只需要 NlogN 的时间。

从逃逸分析的角度，比较像是 OnAfterDeserialize 改变了 name 。

这个问题和数组遍历几遍没关系，主要区别在于内存分配。

Array.map 每次都要分配新的数组，可以想象 no-stream 的 map 只是变换迭代器，当然快。当然这不能怪 Array，毕竟功能不同，要写出值得比较的代码可以对 mf 复合自己 map_count 次，再变换成 reducer，然后直接在 data 数组上用 reduce 。

而且好好写 for 循环不香吗？