@geelaw #77

根据 c24-ver1.pdf 第 25 页的内容，两个方案，一个有 Ω(N) 的时间复杂度和常数的空间复杂度，另一个有 Ω(N) 的空间复杂度和常数的时间复杂度，你能得到了结论说

> 总能耗（在渐近意义下）相比朴素算法会增加

你自己觉得这个结论能成立么？

我给出一个我能想到的最简单的模型，x y 都未知的情况下，Nx+y 和 x+Ny 哪个大？或者说你凭什么认为 x>y 或者 x<y ？
还是说这个“渐近意义”是指把数据加载到内存里面然后把解密跑 N 遍？

@nomagick
@sniperboy0829
@jhdxr

11 楼 lovelylain 的回复已经给出了详细的方案，楼主也认可了他说的内容。
有人 “没点开看链接” 就直接给出了答案，所以，这论文真没多少干货。
核心内容只有不到 10 行的汉字，楼主写了三十多页的论文。

虽然这么说，这个论文也不是全无新意，要获得 “密文长度和收件人数无关” 这个性质，还是需要折腾一些花样进去。
我相信楼主说的 “该问题是新的”，而且这个问题显然和 MPC 没关系，MPC 是比这个复杂多了。

而且确实不民科，这个论文是一个典型的正经科研的玩法。把一些实际上没啥意思的东西套上各种高级的词汇，当然也确实包含了一点点的新东西，写一遍超长的 “论文”，发表在一个没人听说过的期刊上，然后得到 毕业证/学位证/职称 之类的东西。确实是很正经的科研，只不过不是我做事的风格，我更喜欢看到一遍半页的小文章来讲解这个花样。
而且能写出这么长的论文也是高级能力，这东西给我就只能写出来半页的内容，所以我早就不玩这些 “科研” 的东西了。



另外，关于环保，为什么不讨论消息变长带来的额外能耗？数据的存储传输都要消耗能量，凭啥这部分就当零来算了？

@cmdOptionKana

> 性别歧视呢？我问你性别，你回答地域。我前面问你的问题，你顾左右而言他，为什么不敢正面回答：由于罪犯中男性占 70%，假如现在有个女人用看混混、看嫌疑犯的眼神去看你，看任何一个男人，你认为这个女人的想法太极端了不太对，还是说她的想法很合理？

如果白天在中国大城市的繁华地段有女人把周围的男人都当嫌犯来看待，那我觉得她太极端了。如果在一个犯罪率很高的地方，四下无人，天色昏暗，这个女人看到附近有一个男人，把他当嫌犯来看待所以刻意避开，那我觉得很合理。
实际情况通常介于这两种之间，一件事情并不是只有 “太极端” 和 “很合理” 这两个选项，还有很多介于中间的状态。
如果你要问说这个女人在任何情况下都把男人当嫌犯来看待，那她太极端了。理由是我已经给出了一个情况，在这个情况下她没有受到任何的威胁，或者说她的歧视没有给她带来任何的利益，我不认可这样的歧视。


同样性别的例子，比如有一个男人和一个女人打架，我觉得这个男的会赢，这是你不提倡的刻板印象么？
这不是我不提倡的刻板印象。


> 如果你认为性别歧视、地域歧视、种族歧视、年龄歧视有一定道理（只是不宜提倡），那你能不能告诉我，什么歧视是没道理的，人们为什么要反对歧视？

其它的歧视也是类似的，比如招聘中的性别歧视。
现在要自己出钱要招十个搬运工，你愿意男女平等按相同时薪来招聘么？
也许你愿意，但绝大多数人都不会愿意的。

不要来说“绝大多数”这个论断需要证据，如果你连这种基本事实都不认可，就没有讨论的可能性了。

加锁是对的，因为写了变量 std ，同时有两个线程写同一个变量是 data race 。
通常只会 init 一次，也不排除有人在多个线程上 init 这种情况。虽然这种用法大概率是错的，不过作为 library 让这种情况不出 data race 也是正常的。

使用的时候不需要加锁，因为同时有多个线程读同一个变量不是 data race

单踏板模式不适合把车开快，因为"把车开快" 的前提是 "把车开平稳" (头文字 D 送豆腐的故事)，用单踏板模式开到很平稳要困难一些。

这也是 Tesla 的 Performance 版本可以把单踏板模式关掉的原因。

这个模式在城市里跟人抢道特别好用，其它情况基本上就是给不太会开车的人自嗨用的。

顺便一说

十进制
99.1*1.005 = 99.5955
round(99.5955, 3) = 99.596
我猜 Excel 能得到这个结果

Ruby
irb(main):005:0> (99.1*1.005).round(3)
=> 99.595

其它语言当然也是 99.595

这两个浮点数的精确值，实际上
99.1*1.05 是 104.0549999999999926103555480949580669403076171875
104.055 是 104.05500000000000682121026329696178436279296875
这两个数字之间没有其它的 float64 了

这两个数字都不是刚好一半的情况，所以和舍入规则没关系
不论用不用 银行家舍入，round(99.1*1.05, 2) 都是 104.05 ，round(104.055, 2) 都是 104.06

Excel 可能是把 99.1*1.05 的结果直接算成了后面那个 104.05500000000000682121026329696178436279296875 ，然后再 round 当然就得到了 104.06
Excel 应该也能正确处理各种 .1+.2 == .3 的情况

这个问题在 Python 文档里面说得很清楚，https://docs.python.org/3/library/functions.html#round

> Note: The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float. See Floating Point Arithmetic: Issues and Limitations for more information.


Ruby 好像是额外处理了这种情况，Ruby 的 2.675.round(2) 是 2.68

irb(main):001:0> 104.054999999999978399500832892954349517822265625.round(2)
=> 104.05
irb(main):002:0> 104.0549999999999926103555480949580669403076171875.round(2)
=> 104.06
这个行为对我来说很 surprising ，还没写在文档里面。
https://ruby-doc.org/core-2.5.1/Float.html#method-i-round

@Worldispow

你说的 hdr 和他说的 hdr 是完全不相关的两个东西。
https://en.wikipedia.org/wiki/High_dynamic_range
你说的是 Capture ，他说的是 Storage

我大概查了一下，三星 Galaxy S23 Ultra 都不支持他说的 hdr
https://eu.community.samsung.com/t5/galaxy-s23-series/is-there-any-chance-to-get-ultra-hdr-hdr-hdr10-support-in-galaxy/td-p/8543523

人家来招聘，工资工时都说清楚了，招得到就招，招不到也是公司自己的事情，没什么值得争论的。

但是，对软件工程师这个职业来说，通常工资越高的人性价比越高。8k 工资在深圳招的人，在我看来价值基本上就是负的。工作经验其实也没什么大用，2 年经验和 5 年经验差不多的，如果限定工资 8k ，我还觉得招个本科生会更靠谱。

@wu67
神经病定价的华润其实很好的，他家神经病价格的东西几乎都对得起价格，比如水果牛奶牛肉和挂面。
有一个青海的牛奶，1L 装的大概 35 ，这个牛奶大约是能在零食店买到的最好的牛奶，没有范围。乌鲁木齐也有类似品质的牛奶，1L 的价格是 10 块钱。

如果对这种神经病价格的商品没有需求，那山姆就还不错吧，虽然我也对山姆不感兴趣。
山姆的牛肉在沃尔玛也经常有卖。

性价比和面子都不是能简单评价的指标。

A80 Supra 和 A90 Supra 和 BMW Z4 ，哪个有面子？
简单来说，面子也分两种，贵和稀少。你开个深圳很少见的车，我觉得 mx-5 在深圳就挺有面子的。panamera 烂大街了，感觉就很普通。如果大家都是 porsche ，深圳的 911 远比其它 porsche 罕见，那我觉得你开一个最低配的 911 也远比顶配卡宴/panamera 有面子。

说到电车，在某些情况下电车的性价比非常高，可能 model 3 比两三倍价格的油车都好。但是在某些情况下 100 万的电车还不如 3 万的五菱。
油车也分很多种不同倾向的，如果只考虑实用性，30 万差不多足够买到性能非常够用的车了，但也要看实用性上的需求具体在哪里。

楼主没说使用场景，也没说需要哪种面子，真没法评价。

如果能接受 OLED ，我觉得楼主应该去店里看一下，直接看能接受哪个屏幕就行。
13456 都可以直接在网上查到，2 要看自己能不能接受，每个人的标准都不一样，只有看到货了才能知道。
我自己觉得 Sony 的 OLED 还可以，能接受。

除了系统，iPhone se 应该符合楼主的要求，屏幕是完全不闪的高级 LCD ，我自己在用，我也看不出来它哪里不如 OLED 。问题是没有厂商还在做这种屏幕的高端机器了。

@rockyliang

程序员写代码不需要懂这么多的东西，如果你想深究这些知识，当然可以学，这些东西都还挺有意思的，但这些知识和 “写正确的代码” 不相关。让程序员不需要懂这些东西就能写代码，就是所谓 高级语言 的功能。

计算机这东西在各个领域都是分层的，设计 HTTP 协议的人不需要懂 IP 协议要怎么工作，他只需要懂 TCP 协议就行。CPU 指令和编程语言也是类似的情况，写代码的人只需要懂编程语言，不需要懂 CPU 的工作方式，不需要懂编译器的实现细节。
重复一下，你想学当然可以学，但这些知识不能帮你把代码写对。把代码写对需要的是编程语言本身的知识。

你举的例子说 flag = false 没有生效，这件事情的原因，如果非要深究到底，那确实是这一句被编译器优化掉了。
编译器把它优化掉了，这个叫 实现细节，编译器优化掉它，是因为根据编程语言的 spec ，flag = false 这一句可以被优化掉。编译器可以优化掉它，也可以不优化。
经常出现的一种情况是，程序员写了一段带有 undefined behavier 的代码，跑了一下发现一切正常，就认为代码是对的，之后升级了编译器程序就挂了。

从编程语言的角度来说 flag = false 没有被执行到的原因，或者说编译器可以把它优化掉的原因是
这两个 for 循环执行在不同的 goroutine 上，而且 Go 没有保证 goroutine 的执行顺序，也不保证 goroutine 被执行到。
for flag print sleep 的那个循环一直占用着 CPU ，sleep 的实现是忙等，而后面的 for 循环从来都没有执行到，这是一种符合 spec 的行为。
或者 for flag print sleep 的循环要执行了一亿亿亿次以后才会执行到后面的 for ，这也符合 spec
两个 goroutine 同时对一个变量做读写操作，这个叫 data race ，当然是 undefined behavier

两个线程不能同时读写同一个变量，这个算基础知识吧

这些可见性的问题，实际上属于 Instruction Set Architecture (ISA)，不属于编程语言。
每个 CPU 指令集都定义了自己的 CPU 上哪些内存操作在什么情况下可见，都不一样的，这是问题非常复杂。

一个高级程序设计语言，像 C 这种的，当然不需要程序员去处理不同 CPU 的不同行为，不然它就不叫 高级 语言了。
对这些内存操作的行为，高级语言必须有统一的定义，让这个语言写的程序在不同 ISA 上能得到相同的结果。这个定义叫做 memory model ，比如
https://en.cppreference.com/w/c/language/memory_model
https://en.wikipedia.org/wiki/Java_memory_model
https://go.dev/ref/mem

存在 cache 的情况确实会有不可见的问题（考虑一下 CPU 上没有 cache ，所有 core 直接写到主内存上的情况）。但你看 Go memory model 里面根本没出现过 cache 这个词。
就是说 Go 的这套定义里面，就没有 cache 这个东西。Go 的定义里面，程序的行为就像没有 cache 一样（因为他的文档里就没写 cache 的事），所以只要一个 write 发生在 read 之前，且这个 write 之后 read 之前没有发生其它的 write ，这个 write 就被这个 read 可见。
所以这个文档全在讨论顺序的问题。

楼主发的代码显然有明确的执行顺序，这个顺序显然满足上面的要求，所以内存操作是可见的。


顺便一说，程序员不需要知道 ISA 上的这些定义，这本来就是个高端问题。但是 x86 上的内存操作的行为特别简单，所以总有人写代码的时候依赖于这些 x86 的行为，实际上写的代码都是 undefined behavior ，还觉得自己特别厉害，写文章讲解什么内存可见性的问题，估计楼主是这种东西的受害者。

@Rehtt
@stinkytofu
在这件事情上，一个弹窗应该把其它所有东西都挡住。
比如 Windows 上请求管理员权限的弹窗，甚至会把所有东西（包括不重叠的东西）都置灰。这个网页上有很多例子。
https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/how-it-works

或者退一步，弹窗是一个整体，那个下划线和下划线对应的文字是另一个整体。这两个整体的东西不应该交错，要么 A 在上面，要么 B 在上面。A 的大部分都在 B 的下面，有一小部分在 B 的上面，这不是正常行为。

或者再退一步，现在要把 B 放在 A 上面但是需要开一个天窗，我认可有这样的需求。但我不认可有人需要开天窗显示出来一条下划线，而且我不认可“开天窗”是一个常见且普通的需求。

所以，一条下划线被显示在一个弹窗的上面，是一个 bug 。
我觉得这个点本来就很清楚，我真不懂为什么需要这样长篇地解释一件非常浅显的事情。

从 GitHub 的 issue 来看，属于很明显的 bug
问题很简单，其实就一句话

弹窗没把该挡住的东西挡住


讨论 z-index 就变成 xy 问题了，需求是该挡的东西都要挡住，z-index 是 y 问题

不同的人对待软件的态度不一样，比如有人说
> 明明可以传入 zindex 解决的问题

问题在于，有的人会以更认真的态度对待工程问题。
苹果之前的键盘会坏，当然可以说 “找售后换一台就能解决”，不过我们还是希望键盘本来就不坏。
某某车的发动机烧机油，也可以说 “机油不够了补上就能解决”，那有的车企还是会让发动机本来就不烧机油。

这个项目的人明显没打算修，指着糊弄过去就完事了，确实说了一大堆看起来友善专业的话，但实际上放着一个明显的 bug 却没有要修的意思。也算不上大厂风范吧，很多人就是没那么认真而已。
这就是常规情况，不值得这样，我都直接走人的。