duangsuse::Echo
712 subscribers
4.24K photos
127 videos
583 files
6.45K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
This media is not supported in your browser
VIEW IN TELEGRAM
#GitHub #Python #project duangsuse/extract-subtitles (a fork) 内嵌字幕提取(白字为提取后的字幕,半自动需要手工修改部分文本和设置优化滤镜Python代码) 视频来源YouTube
部分片段几乎一模一样,神同步
这个视频足足有 9090 帧
#DontKnow 🤔早上我起床前问了下duangsuse (自言自语)
代码风格上,为什么要把 ES6 generator 的 * 直接贴在 function 的后面呢
回答说,因为这样语义更明确, generator function 就是 function*
那 C++ 里为什么要写 Ui::MainWindow* ui; 呢?
“语义更明确,指针当然要贴着类型”
等等……
int *a, *b;
🤪看来以后得区别对待 C 和 ES6 的星号了”
为了在 #Python 里在保证类型安全的同时尽量减少开销,我决定新特性 "multi-crop" 直接这样实现:
-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
This media is not supported in your browser
VIEW IN TELEGRAM
看起来大功告成
duangsuse::Echo
看起来大功告成
现在终于大功告成了
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'
这个功能我 TM 加定了
This media is not supported in your browser
VIEW IN TELEGRAM
我成功了,但是感觉其实也没什么,可能是这个设计的确是半成品吧
而且我一点也感觉不到自己很机灵,草死了
要是我能再聪明点就好了
对了…… ParserKt v4 会不会加入 binary combinator,还有 org.duangsuse.bin 啥时候继续维护啊
Forwarded from いっぽから
不好,看来 bandpass filter 对艺术字体的效果非常差劲
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 行代码,单就命名来看还是非常可以的(他懂得 n__0 这种按主次以及突出内涵的命名法,当然我觉得学物理带编程的都知道)
而且 for _ in ti.static(range(n)): 的注释结合受众也都相当的合适、突出重点(当时还在脑子里想了下编译器怎么做到把静态求值结果转化到最终程序里的呢……)

应该说单单就代码的简洁性上已经很难更进一步,不知道以后我有没有可能连这样的代码都能找到能够在可读性上进行改进的方法。