summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--content/posts/weekly/33.md18
-rw-r--r--content/一个电梯调度算法.md60
2 files changed, 78 insertions, 0 deletions
diff --git a/content/posts/weekly/33.md b/content/posts/weekly/33.md
index 3a945576..f98b7702 100644
--- a/content/posts/weekly/33.md
+++ b/content/posts/weekly/33.md
@@ -14,7 +14,16 @@ endnotes:
## 🙋 在做什么
+周六是我的新历生日,和朋友去海底捞聚餐啦。每次生日都在考试月,还和四六级考试在同一天,要约人出来真的好难,毕业以后摆脱考试了兴许就不用过这样东拼西凑的生日了吧。
+{{< gallery >}}
+![](https://image.guhub.cn/picgo2025/IMG_4179.jpeg)
+![](https://image.guhub.cn/picgo2025/IMG_4185.jpeg)
+![](https://image.guhub.cn/picgo2025/IMG_4194.jpeg)
+![](https://image.guhub.cn/picgo2025/IMG_4196.jpeg)
+{{</ gallery >}}
+
+把照片发出来才意识到自己二十岁了,很奇妙。
## 👀 在看什么
@@ -62,6 +71,15 @@ PPS. 我喜欢 Apple Music 的无缝切换,效果真的很惊艳,虽然有ç‚
[#AI](/tags/ai/) [#技术](/tags/技术/)
+### 孤独流行病
+
+{{< callout "油管链接:[The Loneliness Epidemic, in Data: Who Americans Spend Time With](https://www.youtube.com/watch?v=h7w339vE2F8)" "📺" >}}
+
+The Pudding 通过统计数据指出,自 1976 年以来,人们和自己相处的时间正在增加,和家人朋友相处的时间则普遍在减少,这一趋势在年轻人群体中最为显著。通过记录样本每小时正在做的事情,来分析他们陪伴家人朋友的时间,他们发现有一半认为自己过得很糟糕的人,在一天里几乎不会和任何人有交流。
+
+社交隔离会导致过早死亡的概率增加 50%,效果与每天吸 15 根雪茄或者每天喝 6 杯酒一样。视频的最后提到了一个很有意思的观点:==人们躺在床上整夜刷手机、看电视,可能只是不想孤独地睡去而已。==
+
+独居后,我的孤独感变得愈发明显,漫无目的地刷信息的时间也明显增加了,我在快一个月的时间里好像什么有意义的事情都没有干。我想是我不得不面对孤独,但却只会使用电子产品来逃避现实。一个令我瞠目结舌的事实是:哪怕和我共处一室的人是连呼吸都让我讨厌得想把他脑袋拧下来的存在,那也比一个人也没有更让人觉得安全。不过,除了建立更牢固、更有价值的关系,「如何独处」可能是所有人都需要面对的课题。我这周还写了[一篇关于塔罗牌中隐士牌的文章](/posts/玫瑰为自己还是为人开/),也是在尝试回答「如何面对孤独?」这个问题。
## 💡 新知复盘
diff --git a/content/一个电梯调度算法.md b/content/一个电梯调度算法.md
index 41bd4190..8b3d9e04 100644
--- a/content/一个电梯调度算法.md
+++ b/content/一个电梯调度算法.md
@@ -121,9 +121,61 @@ closestElevator.moveTo(userLocation)
在多用户的情况下,单个「召唤按钮」的模式就不那么好用了。还是那个例子,当有人从一楼前往五楼,我依然在三楼,但我打算下行前往一楼。这个时候,电梯不应该给我开门,应该在送完去五楼的用户之后返回时再给我开门。如果没有上行和下行按钮的区分,电梯就无法在接送时确定要不要响应用户请求,以及何时响应用户请求。
+为什么不能在另一个用户前往五楼的时候开门,让需要下楼的我乘坐电梯呢?毕竟只要等前一个人到达目的地,电梯再响应我的请求就好了。问题在于,电梯停考和开门的过程,为了保证停靠平稳,不会出现安全问题,耗费的时间是很长的,在中途给我开门会增加其他用户的等待时间。
+
+尽管电梯的上下按键可能会让人感到困惑,搞不清楚「上」指的是用户想要往上走,还是命令电梯向上运行,但这个操作逻辑在习惯之后是可以变得符合直觉的。相反,如果没有上下按键的区分,用户可能不会明白电梯为什么不响应自己的请求,自己明明想往下,而电梯却往上开。
+
### 接
+在多用户单电梯的情况下,接和送这两个步骤变得耦合了,似乎很难完全分离开,因为当一个用户正乘电梯前往目的地时,另一个用户可能希望搭上这部电梯,接和送是同时进行的。
+
+不过,我们依然先考虑电梯如何响应用户「接」请求。
+
+在单用户的情况下,电梯只需要直接前往用户所在的楼层就好了;在多用户的情况下,电梯则需要排序,即先前往哪个楼层,再前往哪个楼层。我们在此假设没有人按下楼层键,「送」的算法还没有开始。
+
+#### 单向运行的情况
+
+在一些情况下,电梯只需要单向运行。假设电梯在 6 楼,有两个用户分别在 3 楼 和 4 楼按下了电梯的下行按钮,有另一个用户在 1 楼按下了电梯的上行按钮,那么电梯只需要一直往下,分别在对应的楼层停下就好了。当前两个用户到达了 1 楼,最后一个用户正好可以上楼。
+
+#### 上下楼层都有用户呼叫的情况
+
+如果电梯在 4 楼,而 2 楼、3 楼和 6 楼都有用户希望下行,电梯应该如何响应呢?如果先去离得最近的 3 楼,再去 2 楼,在把这两个用户送到一楼之后再去接 6 楼的用户,显然是不合理的;电梯应该先往上,接到 6 楼的用户后再一路向下。反之亦然,如果电梯上方和下方的楼层都有用户在等待接送,而他们选择的运送方向都是一致的,那么先向反方向运行是最有效率的,可以避免走回头路——如果当前的所有用户都希望往上,那么电梯就应该先考虑向下,然后一路向上完成运送任务。
+
+听起来很美好,但真的可行吗?比较极端的例子是,电梯在 17 楼,现在 18 楼和 19 楼有用户希望向上前往更高的楼层,此时 1 楼又有用户希望往上,电梯显然不应该先去一楼。对于特别高的楼层来说,这个方法不一定能保证效率。
+
+虽然不能保证效率,但「反方向优先」的方案的确保证了电梯的资源消耗最低,也就是**路线最短**。如果先接送离电梯最近的用户,电梯的总运行路线长度是 41 层楼;如果先接送反方向上的用户,电梯的总运行路线长度是 35 层楼。如果电梯的运行速度是恒定的,不考虑在每个楼层的停靠时间,路线的长度就决定了时间长短。如果要保证时间最短,就应该采用「反方向优先」的方案。
+
+![](https://image.guhub.cn/picgo2025/IMG_0369.PNG "上为「最近用户优先」的方案,下为「反方向优先」的方案。")
+
+刚才我们一直假设所有用户都想去同一个楼层,那如果只有 18 和 19 楼的用户想去 20 楼,而 1 楼的用户只想去 8 楼呢?
+
+![](https://image.guhub.cn/picgo2025/IMG_0370.PNG)
+
+在这种情况下,「最近用户优先」的方案一共移动了 29 层,「反方向优先」的方案还是移动了 35 层。显然,「反方向优先」的方案连总运行时间都不一定能保证最小,而且无论运行时间如何,这种方案都会让高层的用户等待很久。
+
+等等,他们只是想去 20 楼而已,为什么不走楼梯?
+楼梯其实也可以分摊电梯的负担,但别忘了,这两个用户还没有上电梯,他们只是按下了「上行」按钮,电梯并不知道他们要去的是 20 楼还是 40 楼。况且,电梯的制造商应该也不想培养用户走楼梯的习惯吧——这样他们还怎么卖产品?
+
+问题又来了,如果 18 和 19 层的用户真的是想要去 40 层呢?
+
+![](https://image.guhub.cn/picgo2025/IMG_0371.PNG)
+
+「最近用户优先」的方案的总路线长度是 62 层楼,「反方向优先」方案的总路线长度是 55 层楼。
+
+……
+
+扯了这么多,结果还是没得出多用户单电梯情况下应该如何调遣电梯。显然,「最近用户优先」和「反方向优先」的方案都有弊端,各取所长应该是最好的。
+
+```javascript
+if (condition) {
+ elevator.moveTowardsClosestUserFirst()
+} else {
+ elevator.moveTowardsOppositeDirectionFirst()
+}
+```
+
+那么,这个 `condition` 应该如何计算呢?
### 送
@@ -132,3 +184,11 @@ closestElevator.moveTo(userLocation)
### 接
### 送
+
+## 一种新的电梯设想
+
+能不能模仿商场里的扶手电梯(Escalator),只设置一个只上行的电梯和一个只下行的电梯呢?
+
+---
+
+另,感觉电梯的调度其实可以让 AI 实时生成最优调度方案,编写精密的算法实在是太费脑子了。 \ No newline at end of file