#DontKnow 🤔早上我起床前问了下duangsuse （自言自语）
代码风格上，为什么要把 ES6 generator 的 * 直接贴在 function 的后面呢
回答说，因为这样语义更明确， generator function 就是
那 C++ 里为什么要写
“语义更明确，指针当然要贴着类型”
等等……
“🤪看来以后得区别对待 C 和 ES6 的星号了”
代码风格上，为什么要把 ES6 generator 的 * 直接贴在 function 的后面呢
回答说，因为这样语义更明确， generator function 就是
function*。那 C++ 里为什么要写
Ui::MainWindow* ui; 呢？“语义更明确，指针当然要贴着类型”
等等……
int *a, *b; 呢“🤪看来以后得区别对待 C 和 ES6 的星号了”
为了在 #Python 里在保证类型安全的同时尽量减少开销，我决定新特性 "multi-crop" 直接这样实现：
参数输入上，外部利用 argparse 的
直接在主程序进行列表的填充工作。不过，我们会为
大致意图上是这样，在 make extractor 和 call extractor 里都得加逻辑，分支都不止两个，比较麻烦
不用额外判断的原因是直接利用 Python 的方法解析，传递不同 class 的对象进去
-crop "0 (x,y)(w,h)" -crop "233 (x,y)(w,h)" 参数输入上，外部利用 argparse 的
nargs="*" 来进行，内部使用 List<Rect>? (index=frame_no) 来进行表达。直接在主程序进行列表的填充工作。不过，我们会为
len(cfg.crop) == 1 的情况进行特殊处理，让每帧处理时不必显式判断是否要 index 这个 list。len_crop = len(cfg.crop)
(SimpleExtract if len_prop <= 1 else ComplexExtract) (None if len_crop == 0 else cfg.prop) 大致意图上是这样，在 make extractor 和 call extractor 里都得加逻辑，分支都不止两个，比较麻烦
不用额外判断的原因是直接利用 Python 的方法解析，传递不同 class 的对象进去
from itertools import repeat
def zipWithNext(xs: list):
for i in range(1, len(xs)):
yield (xs[i-1], xs[i])
def expandStartList(size, entries, key = lambda it: it[0], value = lambda it: it[1]):
sorted_entries = sorted(entries, key=key)
items = list(repeat(None, size))
def assignRange(start, stop, value):
items[start:stop] = repeat(value, stop - start)
for (a, b) in zipWithNext(sorted_entries):
assignRange(key(a), key(b), value(a))
last_item = sorted_entries[-1]
assignRange(key(last_item), size, value(last_item))
return items
duangsuse::Echo
看起来大功告成
现在终于大功告成了
In [18]: expandStartList(10, [(3, 5), (9, 1)])
Out[18]: [None, None, None, 5, 5, 5, 5, 5, 5, 1]
In [18]: expandStartList(10, [(3, 5), (9, 1)])
Out[18]: [None, None, None, 5, 5, 5, 5, 5, 5, 1]
cv2.error: OpenCV(4.2.0) /io/opencv/modules/core/src/arithm.cpp:669: error: (-209:Sizes of input arguments do not match) The operation is neither 'array op array' (where arrays have the same size and the same number of channels), nor 'array op scalar', nor 'scalar op array' in function 'arithm_op'草
要是我能再聪明点就好了
对了…… ParserKt v4 会不会加入 binary combinator，还有 org.duangsuse.bin 啥时候继续维护啊
对了…… ParserKt v4 会不会加入 binary combinator，还有 org.duangsuse.bin 啥时候继续维护啊
duangsuse::Echo
我成功了，但是感觉其实也没什么，可能是这个设计的确是半成品吧 而且我一点也感觉不到自己很机灵，草死了
https://github.com/duangsuse/extract-subtitles/commit/275f7c33999d8004164c0dad09d1c4a763b2ce87
push 上去了，感觉还能用。
push 上去了，感觉还能用。
GitHub
BREAKING: Implement "multi-crop" feature, cleanup code · duangsuse/extract-subtitles@275f7c3
Extract Subtitles From Video 视频字幕提取 帧间差分法识别关键帧 OCR识别 - duangsuse/extract-subtitles
https://zhuanlan.zhihu.com/p/97700605 #zhihu #recommended #cg #Python #China （<顺便说一句，总是强调 China, China…… 说的越多意义越小）
我居然看完了…… 给个总结吧，就是作者的性格我很喜欢，比 @ice1000 “阳光”很多（拍脑门瞎想的，没啥实际意义）
其实我也很想对数学和物理有点天才啊，反正微积分、机器学习、信号处理什么的都不会就是了。
观看的时候注意到作者说之前编译器 SSA IR 设计错了蹩脚，后来才弄出了“Hierarchical”的 IR，我顺便想了下，recursive data structure + "no" field，以我贫瘠的想象力没啥其他可能了，估计还是得要 iteration，多 adopt 一点处理算法才能找出最适合的建模方法。
科学研究的过程本身也是简化的过程，实现什么东西都太注重形式而非内涵这本身就是应该去掉的，所以说强调“只有 99 行”我觉得是个蛮正确的观念。
那我还能做什么呢…… 其实相比一些普通人/团体的开源项目，我能挑出一些可以等价置换的地方，但对于内涵比较学术系的程序我就没办法了，作者的 99 行代码，单就命名来看还是非常可以的（他懂得
而且
应该说单单就代码的简洁性上已经很难更进一步，不知道以后我有没有可能连这样的代码都能找到能够在可读性上进行改进的方法。
我居然看完了…… 给个总结吧，就是作者的性格我很喜欢，比 @ice1000 “阳光”很多（拍脑门瞎想的，没啥实际意义）
其实我也很想对数学和物理有点天才啊，反正微积分、机器学习、信号处理什么的都不会就是了。
观看的时候注意到作者说之前编译器 SSA IR 设计错了蹩脚，后来才弄出了“Hierarchical”的 IR，我顺便想了下，recursive data structure + "no" field，以我贫瘠的想象力没啥其他可能了，估计还是得要 iteration，多 adopt 一点处理算法才能找出最适合的建模方法。
科学研究的过程本身也是简化的过程，实现什么东西都太注重形式而非内涵这本身就是应该去掉的，所以说强调“只有 99 行”我觉得是个蛮正确的观念。
那我还能做什么呢…… 其实相比一些普通人/团体的开源项目，我能挑出一些可以等价置换的地方，但对于内涵比较学术系的程序我就没办法了，作者的 99 行代码，单就命名来看还是非常可以的（他懂得
n_ 和 _0 这种按主次以及突出内涵的命名法，当然我觉得学物理带编程的都知道）而且
for _ in ti.static(range(n)): 的注释结合受众也都相当的合适、突出重点（当时还在脑子里想了下编译器怎么做到把静态求值结果转化到最终程序里的呢……）应该说单单就代码的简洁性上已经很难更进一步，不知道以后我有没有可能连这样的代码都能找到能够在可读性上进行改进的方法。
刚刚突然想了一下绝句的『其中』块的必要性，居然得出了「为了少一次 private 自授，就可以如此草率地决定加入这个容易被滥用而且增加认知复杂性的语法吗」这个问题，问住我了，我觉得语法还可以进一步简化，但是实在是个问题。 🤔