虽然楼主说的确实有道理，不过我个人确实不需要呼吸灯这种玩意儿。。。

毕竟电脑上该登陆的都登陆了。微信是肯定会打开的，那么大部分消息也就不会没看到了。

鲜榨果汁 = 饮料，没必要考虑它的营养价值，毕竟它也不剩啥营养价值了。

从饮料角度，你老婆是对的。

哦最大最小堆也挺好，可以处理在线情况。

换个几号吧，如果你的全数组长度是 M ，用最小堆找最大的前 N 个元素，那么时间复杂度就是 O(M log N)。
反之用最大堆可以找最小的 N 个元素。

快速选择，做一半的快速排序，期望复杂度 O(n)

先做一次快速排序，若轴枢元素是第 K 大。

* 如果 K < N 则对右侧做 N-K 的快速划分。
* 如果 K > N 则对左侧做 N 的快速划分。

df[column].rolling(window_size).rank(pct=True)

https://pandas.pydata.org/docs/reference/api/pandas.core.window.rolling.Rolling.rank.html

这种结论一般都是构造法证明。

首先图灵机是什么有清晰的定义。然后就是怎么用 sigmoid + rnn 表达任意给定的图灵机了。

随便搜一下可得：

Turing Completeness of Bounded-Precision Recurrent Neural Networks
https://openreview.net/forum?id=IWJ9jvXAoVQ

这篇 2021 年的 poster 说，前人的工作需要假定无穷精度的 RNN 才能表达任意图灵机。现在他们可以用有限精度 RNN 来表达了（可喜可贺

1. 坚果云的 WebDav 我印象中用 Joplin 容易冲突。不知道 Obsidian 怎么样，但我想这可能是 WebDav 的固有缺陷 —— 依赖客户端的冲突解决能力。

2. 所以我会更倾向于使用自带客户端的同步盘。其实按道理坚果云自己的同步盘效果还可以，冲突解决也还行。直接把 Obsidian 的 Vault 塞进去就行了。

3. 我自己用的是 Seafile 自建网盘，用的 Seafile 的同步客户端。

@mcone az 。我联通，当年支付宝健康码经常加载不了，我就换微信了

北京健康宝内部的扫码才能显示健康码。

我认为正常写法更好

@nthhdy “ 引入运动预测等机制，即使无损也能一定程度上提高压缩比。”

呃，真的存在无损运动预测压缩算法嘛

@nthhdy 其实如果外延一下的话，上面的乱七八糟的讨论和条件熵有关。

H[X|Y] = H[X,Y] - H[Y]

已知 Y: 数据是视频。

所蕴含的信息量其实是非常非常巨大的。同样的文件，没有 Y 这个信息的话，你无法自动推断出 “帧与帧之间有图像相似性” 这个结论的。因为每张图的 0-1 串其实相差巨大。图片就是这个样子，上面的 object 移动一个像素，二进制串就一大堆变化（而且还不是连续的二进制位发生变化）。通用压缩算法几乎不可能在有限的时间里面去 discover 这种信息。

@nthhdy 信息熵是个数学概念，在实际数据集上几乎无法计算。

任何计算“熵”、“概率”，都要先假设数据服从某些分布，然后才能进行计算。各种不同的压缩方法，显然是假设数据服从不同的分布，然后用这种假设去搞了具体的编码方案。

你在教材上看到的 Huffman 编码，是假设 alphabetic 是定长的（比如 a~z ），并且每个 alphabetic 都用定长的 0-1 串编码。在这个前提下给出的最佳编码方案是霍夫曼树。但是呢。。。

显然现实世界不是这样的。你完全可以用不定长的 alphabetic 去做不定长串的压缩。这就是各路通用压缩算法大显神通的地方了。然而即便如此，通用压缩算法处理 .avi 也达不到很高的压缩比。

各种视频和图片编码显然是做了更激进的概率建模，在这种特殊的概率分布上用了更高压缩比的方案。比如视频的帧间编码，显然是利用了你“视频的帧与帧之间的信息有很多重复”这个额外信息。在通用压缩方法里面可没有这个额外信息。

----

信息论有一条，“数据的信息量 = 编码后的信息量 + 编码器的信息量”。虽然和上面的论述其实没有多大关系，但是也能提示你一点：你给程序多一点信息，你压缩以后的东西就能变得更小。

1. 什么叫图片视频。。。
2. 现代视频编码确实是这么搞的。有兴趣可以看 h264, h265

其实我寻思，去掉唯大厂论，唯互联网论，期望工资放到 1W 上下，怎么会找不到 965 的写代码工作呢？