醍醐灌顶！

面试的时候没法做，直接o了

花花这里combination解法redundancy太高了 对于每次不同长度的subset，结果的生成总是需要build from the scratch， 即从空subset开始。 这样算下来整个Time Complexity 是远远大于 O（N*2^N）的。 这样即可， 每到一个节点，基于当前的curr，遍历所有可以append 新元素的情况 （当然，也需要back track一下），当数组扫到底的时候，其实自然就会停止了： def backtracking(nums, i, curr): res.append(curr[:]) # shallow copy for idx in range(i, len(nums)): curr.append(nums[idx]) backtracking(nums, idx+1, curr) curr.pop() res = [] backtracking(nums, 0, []) return res

Cache怎么做sharding呢。按user_id咯？这都是key了。也没法按tweet_id了

面試的時候要做到這種程度的分析，真的只能說佩服了... 如果不夠強可能要分析超久

花花好久没发视频啦😅

你的方法現在是overflow了

Good that YT has auto generated captions and translation. :D Thanks for putting it together.

事实上代码里用的是permutation. combination是错的。 for (int i = 0; i < n; ++i) { if ((s & (1 << i)) == 0) continue; for (int j = 0; j < n; ++j) { 如果是combination,第三行的j = 0应该改为j = i + 1, 但改了之后，错误。当然如果sort之后用combination就可以了。

区别2，我测试了结果和你不一样

如果插你前面，那么就替换掉你；如果比所有的都大，就放在最后面

这么复杂的题也算medium

leetcode上的答案都是一维数组版的，完全看不懂，这个视频从二维数组开始推导一看就懂了

太牛逼了，感谢！

谢谢讲解，在看这个之前我老是把subproblem 想成 放在当前level 还是下一个level， 然后当前level还要考虑是否width够 也就是说之前的state还要知道remaining width， 就是没有想到 slicing

哥，你咋不更新了😢

great explanation. Thanks

来来，现在 Google 喜欢玩的 front load: 33/33/22/12

现在 Piper (No), Fig (Yes)

很清晰，赞

2024年python brute force 过了 不过要用花花这种pruning 不然确实过不了 花花程序写的真的elegant

謝謝花花的影片，想確認一下，表格最後兩 row，是不是應該是 {a:3, b:6, c:5} 和 {a:3, b:7, c:5} 呢？ (若我有錯誤歡迎不吝指教) 很喜歡花花的影片 品質很高

谢谢分享

思考了一下 如果左右两边一样高 任何一边往里面移一步 面积一定会小的 除非一边遇到更长的 促使另一边内移遇到也很长的 总面积大了 所以这个情况可以左右一起向内移一步 （来自刷题的第6天）

这种题真的有人能在不刷的情况下一次ace吗。。。

謝謝 加油

吐字太不清晰了。。

光盘那个是错的，那是北方的习语。大陆标准94年后，对于disk和disc翻译就加以区分了--因为disk和disc这两本是美英使用习惯，到了九十年代中期，业界就开始作出区分了，同样的，94年两岸汪辜会就谈过两岸术语问题，最后定的是optical disc就译成光碟，所以有“影碟机”不叫“影盘机”吧，硬盘那个disk才称盘--磁盘(盘跟碟区分，就是一个是磁一个是光存储，这就是为什么软盘能称盘的原因)。"光盘"完全就是北方人的习惯而已。我不知道94年两岸谈过后，台湾方面术语标准制定机构如何标准，但在英文界disk和disc就早就已经区分了，而且94年两岸谈后，按道理应是跟大陆一致，应该是标准化成：硬盘和光碟，估计台湾人跟中国大陆北方人一般沿用习语，对“硬盘”仍称“硬碟”。

不明白为什么还能length=1，length=1何来的红蓝交替之说。但是看了好几个视频似乎都默认一条边从node 0 到node n都算length 是1 而不是0.

不要意思请教一下 第四页PPT 如果 m + 1 是4， j 是5， k - 1 是10， 这个该怎么解释呢 将两个石头分成了10堆吗？

我去 太牛了，分类的太清晰了，一下听懂了

翻墙用不了啊

为什么获取时间间隔要用heap，用map记一下上一次时间不够用吗

1 +2+ ...+ k = target + d, (0 <= d < k) 為什麼 d不能是負數呢？

这个解法真的非常妙，谢谢花花

so clear 爱了

nice code

停更了？

有人可以解釋為何一定要用 for 嗎? 為何不能寫 while ( n != 0) 反正 n 最後會右移成 0不是嗎? 但寫 while ，leetcode 編譯不會過

讚!!

妙啊😀😀

谢谢花花 能不能讲讲unit test

用stack不就行了？

limitations 那一节，解释的有点欠缺。string应该是有优化的，短string不需要allocate内存。 你的两个例子都是在优化范围内。 第一个例子，如果新的string超过优化范围（8字节或者16字节），输出应该不会变，因为新的内容是allocate的，不会影响之前的。 - 我错了，打出来的是乱码，16字节内都不会重新分配内存。 第二个例子同理，长的有限并没有申请内存，string_view只是一个指针和size，能打印出H034恰恰表明没有重新分配内存，之后的解释全无根据的。

21:00 稍微用过数据库都不会这么设计啊，你需要对userid重建一个索引

我来大力喷一下，希望看到的人不要踩坑。视频里属于把算法优化错误用在系统设计上了。首先，存储的大头在values，不在keys，trie节省的存储空间有限。每次新敲一个字母，是一个全新的request，没有利用到tire的继续查找的优势。反而，把原来一次query变成了多次query，key有多长就访问多少次磁盘，白白增加了latency。那么假设视频里的方案是放在内存中，tire的方案很难horizontal shard，就算只有10 billion的keys，每个key有10个top 10，就算是UUID（姑且这里用视频里UUID to string hash的方案）每个都要16B，那就是1.6TB，已经很难放在内存了。视频提到了hash方案，这个hash table本身的size反而更大，更是不可能放进内存中。sharding的方案也可以商榷，以prefix shard总是难以避免uneven sharding的问题。up是狗的，不如直接看一下那边的docs比较靠谱

老师你说的完全对于没有基础的人来说，就和天书一样。

copilot 是輔助, pilot 還是你, 想要 copilot 自己撰寫功能而去想註釋怎麼寫這樣其實生產力就下降了

ccc daka day1

这个time limit exceeded