#Math 如何看待《华裔教授发现二次方程「极简」解法:丢掉公式,全球教科书可能都要改了》? - 王ruo宇的回答 - 知乎
https://www.zhihu.com/question/359765958/answer/930330106
https://www.zhihu.com/question/359765958/answer/930330106
Zhihu
如何看待《华裔教授发现二次方程「极简」解法:丢掉公式,全球教科书可能都要改了》? - 知乎
对于全球几十亿人口来说,二次公式是必须记下来的一个复杂公式(可能也是唯一的一个),这也是我们必须学…
你以为文言编程只是闹着玩?三个月后,人家IDE、教程、包管理器都有了 - 机器之心的文章 - 知乎
https://zhuanlan.zhihu.com/p/112650761 #PLT #Python
https://zhuanlan.zhihu.com/p/112650761 #PLT #Python
知乎专栏
你以为文言编程只是闹着玩?三个月后,人家IDE、教程、包管理器都有了
用文言文写的官方编程教程《文言陰符》,类似 pip 那样的包管理工具「文淵閣」,还有文言编程开源 IDE「文言齋」,文言编程语言已经这么成熟了?机器之心报道,参与:思、Jamin。机器之心曾介绍过 CMU 计算机专业…
./gui_crop_select.py ~/视频/IMG_6302.MP4
./extract_subtitles.py -crop '593(85,287)[481,38]' --crop-debug -filter-code '~cvInGrayRange(it, 0xcc, 0xff)' -lang chi_sim --chunk-size 1000 --use-sharp ~/视频/IMG_6302.MP4 现场来提取一个字幕时轴^
./timeline_ops.py merge frames/timeline_IMG_6302.MP4.txt 0.25|./timeline_ops.py to-lrc 25 srt>test.srt
duangsuse::Echo
./gui_crop_select.py ~/视频/IMG_6302.MP4 ./extract_subtitles.py -crop '593(85,287)[481,38]' --crop-debug -filter-code '~cvInGrayRange(it, 0xcc, 0xff)' -lang chi_sim --chunk-size 1000 --use-sharp ~/视频/IMG_6302.MP4 现场来提取一个字幕时轴^ ./timeline_ops.py merge fra…
(\d{2}): (\d{2}): (\S+)-> (\d{2}): (\d{2}): (\S+)
$1:$2:$3 --> $4:$5:$6 然后到 Google 上翻译下,以这个正则替换修复破损的 SRT 格式。
ffmpeg -i IMG_6302.MP4 -vf subtitles=IMG_6302_en.srt IMG_6302_zhEn.mp4🤔 我们来说说之前的 Montage.py 策划。
蒙太奇图是一种艺术画,它用许多相对整齐的子构件来构筑一副图画。
之前我们的安排就是,利用 Python Pillow / Java AWT+ImageIO 的接口,有一个画布以后直接取 color average (实际图像一般有三个 channel,我们只需给这片区域
然后遮盖那一部分原图区域的项就用这个颜色。
不过还有个问题,就是怎么知道项都放哪,之前的项目是有一个 LayoutPlanner,它会 yield 给一大堆 Rect(矩形区域),然后作画也在那上面(准确的说是给 draw 的算法一个 "sub-image" (后来改 crop 了) )完成,结果最后改来改去失败了,效果很不好
但后来我发现呢…… LayoutPlanner 实际上是不能独立于绘制算法要绘制的区域而存在的,所以失败是当然的。
现在的抽象会是这样
然后布局就是经典的 for y for x 了, x >= width 就 y += avg_h 。
参数:
font, font-size
color-mode, crop, scale (float / tuple)
image items
后来看了另一个项目才想起来的:
space-hv (tuple)
tint-color (code on sub-image
draw-unless (code on sub-image
蒙太奇图是一种艺术画,它用许多相对整齐的子构件来构筑一副图画。
之前我们的安排就是,利用 Python Pillow / Java AWT+ImageIO 的接口,有一个画布以后直接取 color average (实际图像一般有三个 channel,我们只需给这片区域
int[3][] 取 avg 即可)然后遮盖那一部分原图区域的项就用这个颜色。
不过还有个问题,就是怎么知道项都放哪,之前的项目是有一个 LayoutPlanner,它会 yield 给一大堆 Rect(矩形区域),然后作画也在那上面(准确的说是给 draw 的算法一个 "sub-image" (后来改 crop 了) )完成,结果最后改来改去失败了,效果很不好
但后来我发现呢…… LayoutPlanner 实际上是不能独立于绘制算法要绘制的区域而存在的,所以失败是当然的。
现在的抽象会是这样
class Drawable:
def drawOn(img: Image) -> Rect: pass
class TintedDrawable:
def drawOn(img: Image, tint: Color) -> Rect: pass 然后布局就是经典的 for y for x 了, x >= width 就 y += avg_h 。
参数:
font, font-size
color-mode, crop, scale (float / tuple)
image items
后来看了另一个项目才想起来的:
space-hv (tuple)
tint-color (code on sub-image
lambda it: averageColor(it) )draw-unless (code on sub-image
lambda it: pixelsInRange((0xFF,0xFF,0xFF), 10) / it.count() > 0.5 )Telegram
duangsuse::Echo
#memo Doge
#dev #PLT 以前经常把类似 LuaJava, JamRuby, Lua-intrf 之类的东西称为“高阶语言桥”或“语言绑定” (相反 SWIG 之类的 bindgen 就不会了?)
想想这无非是一个好看没不讨喜、充满民科气息的名词。
给两门语言创建“绑定”,其中一般有一个采用比较“脚本化”的实现方式而非静态编译之类,但关键在于提供底层 API (如 C API),然后再把 API 和另一门语言创建更高层的绑定(整句话都不太严谨,毕竟涉及 FFI(foreign function interface) 这种非常实践性的问题)
绑定和一般的库绑定会有较大的不同之处,主要体现在数据对象的封送、类型转换(可能存在)、对应的 GC 接口互调等等。
一个主动一个从动,但从“语言实现”绑定的角度看,如 LuaJava 在 Lua 侧能访问 Java 的对象成员,Java 侧也能从 Lua 的 boolean, number, table 等获得信息,这是主要功能。
我应该多写点 C++,光 Java 是不够的,但是我现在真的熟悉 JDK 么……
想想这无非是一个好看没不讨喜、充满民科气息的名词。
给两门语言创建“绑定”,其中一般有一个采用比较“脚本化”的实现方式而非静态编译之类,但关键在于提供底层 API (如 C API),然后再把 API 和另一门语言创建更高层的绑定(整句话都不太严谨,毕竟涉及 FFI(foreign function interface) 这种非常实践性的问题)
绑定和一般的库绑定会有较大的不同之处,主要体现在数据对象的封送、类型转换(可能存在)、对应的 GC 接口互调等等。
一个主动一个从动,但从“语言实现”绑定的角度看,如 LuaJava 在 Lua 侧能访问 Java 的对象成员,Java 侧也能从 Lua 的 boolean, number, table 等获得信息,这是主要功能。
我应该多写点 C++,光 Java 是不够的,但是我现在真的熟悉 JDK 么……
duangsuse::Echo
Photo
我不是很喜欢最后那个算 padLeft 和 padUp 的
大致就是
🤔 很生的布局边界计算,难怪当时我想用一个
(啊不对,不是 line,应该是 item……)
差别大致在于预先算好了的项目布局不依赖执行顺序(这样就相对容易优化),看来我有必要把
这样的话既可以保证项目的灵活性,也能保证算法尽可能抽象。
大致就是
lineW = (cfg.font_size + sp_h) * scale
lineH = (cfg.font_size + sp_v) * scale
cols = int(image.width / lineW)
rows = int(image.height / lineH)
padLeft = (image.width - (cols*lineW) + sp_h) /2
padTop = (image.height - (rows*lineH) + sp_v) /2 🤔 很生的布局边界计算,难怪当时我想用一个
LayoutPlanner ,原来是这么算的 真的有预先算布局再区间迭代啊……(啊不对,不是 line,应该是 item……)
差别大致在于预先算好了的项目布局不依赖执行顺序(这样就相对容易优化),看来我有必要把
TintedDrawable 给细化一点了……class TintedDrawable:
def drawOn(self, img, rect, color): pass 这样的话既可以保证项目的灵活性,也能保证算法尽可能抽象。
#GUI 🤔 谁会画这种单元格?……
class Boxes: QWidget {
public:
Boxes();
~Boxes();
int width, height;
int n_rows, n_cols;
void setColor(QPoint p, QColor color);
QColor getColor(QPoint p);
}Forwarded from 坐和放宽的碎碎念 (坐和放宽 工图男儿不会早睡)
数据都迁移完了
目前发现损失的有
文化周的视频(可以重新编码出来)
PS安装包(可以重新下,反正到时也要换2020版的了)
红米3刷机包(重新解压的事)
Windows 8.1镜像(重新下)
腾讯会议安装包(这个其实也没啥留着的必要)
综合看来损失不算特别大,但万一以后损失的是其他东西呢
目前发现损失的有
文化周的视频(可以重新编码出来)
PS安装包(可以重新下,反正到时也要换2020版的了)
红米3刷机包(重新解压的事)
Windows 8.1镜像(重新下)
腾讯会议安装包(这个其实也没啥留着的必要)
综合看来损失不算特别大,但万一以后损失的是其他东西呢