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

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
Forwarded from 芝士和培根 (Channel Helper)
芝士和培根
CNBlackListR项目组公开说明:反思与新思路 https://github.com/CNBlackListR/white-book/blob/master/公开说明/反思与新思路.md 消息来源: https://t.me/times001/58253 #未分类
其实虽然对于计算机视觉来说,肯定是比简单的计算机图形学生成算法要耗时的
但是可以考虑有一些算法低劣的 spam bot,没有自动生成图片,沿用老图片在,所以可以保存已经判断为 spam 的图片 hashcode 再发封禁

再不济一点,可以找一下有没有图像的 SimHash 实现,先对比图片像素大小,完全等同就对比哈希码,类似就认为是 spam 图片,或者让机器人自动收集所有是 spam 的图片使用机器学习找出其中类似的像素簇、然后按大小模糊判定再加权回归,是个比执行 OCR 算法要好的方案或许吧(考虑到很少有 Telegram 用户发微信二维码?

二维码的判断对于对面是傻逼的情况也比较好做,扫描一遍检查连续的黑块块隔白块块算出总长度就能判(其实应该找专门的算法吧...

对于关键词列表,可以使用 Trie tree 和分词算法来优化

对于追踪,其实也不必要谁一加进来就立即检查的,或许可以维护一个队列慢慢查?(不过如果 Telegram 没有提供查询用户消息记录的方法,就只能另外弄个记录表实现了,也是有不少开销的)
duangsuse::Echo
其实虽然对于计算机视觉来说,肯定是比简单的计算机图形学生成算法要耗时的 但是可以考虑有一些算法低劣的 spam bot,没有自动生成图片,沿用老图片在,所以可以保存已经判断为 spam 的图片 hashcode 再发封禁 再不济一点,可以找一下有没有图像的 SimHash 实现,先对比图片像素大小,完全等同就对比哈希码,类似就认为是 spam 图片,或者让机器人自动收集所有是 spam 的图片使用机器学习找出其中类似的像素簇、然后按大小模糊判定再加权回归,是个比执行 OCR 算法要好的方案或许吧(考虑到很少有…
因为我也不是机器学习和计算机图形学、信息学、密码学领域的人 #machl #ann #cg ....
自然语言处理我也是正在想办法准备学

所以我只好看看关键字匹配... 发现的确就是分词算法啊

https://github.com/CNBlackListR/CNBlackListSoamChecker/blob/aa281efd716a8c11876d755868125cd117aa38cb/CommandObject/SpamMessageChecker.cs#L37


简而言之,spam 打分算法就是接受 SpamMessage 配置和目标判断消息,返回 possibility 值的函数

这个关键字匹配算法虽然优化过,不过也是『简单』算法,因为它还是得判断 n 次加权(一个关键字判断一次,不能扫描一遍消息一起判断了)

具体的匹配算法就是:

如有字符串 "abcde" 关键字列表 [(1, "a"), (2, "de")]

foreach kw in kws
if strstr(snd kw, mesg) > 0: points +=
fst kw


而 strstr 是 libc 里的一个字符串搜索子串函数

这里要的是匹配,比如我们有字符串

a "hello fish sea world" 和 b "fish"

要判断 b 在 a 里出现了几次,我们可以这样:

枚举 a 里的索引『i』且『i + (b 的长度)小于 a 的长度』(就是所有 b 可能和 a 的某个子序列匹配的索引们)
对于所有 b 里的字符
如果『该字符』等于『a 枚举到的字符』继续判断
假如已经枚举到了最后一个字符,则匹配成功
否则 打断循环,跳过当前字符串的长度 — 我们只需要判断一个字符串,前面的索引 n 都不匹配后面的 x > n 匹配也没有用, skip 掉

好吧,如果你觉得上面的还是难于理解,那么这是一种算法:

它是从这里,Line range 47-75 抽提出来的一种字符序列匹配算法

它有两个输入,String str 和 String part、一个输出,int,返回 str 中 part 子序列的个数

比如 str = "12345ab3243ab..23ab", part = "ab" 输出 3

显然,它要计数数目、检查 str 和 part 相关索引的匹配,有

int count
size si, pi
size matched — 已经匹配的长度

它的逻辑很简单,就是枚举所有 str 和 part 可能重合的索引(str.length - part.length)
(si, pi) =>
再进行 str.subseq[si..].startWith(part) 判断

然后得基于当前的 si 位置再进行匹配,如果成功,则 ++count,如果还在判断 ++matched; ++pi; ++si,如果失败 si += (part.length - matched); pi = 0 // 跳过剩余,重新 match

这样碰到显然不是子序列的,直接跳过就好。

如果你还是无法理解,我正在做动态图....
好奇怪,这里有个 if (...) {...} else if (x != 0) {...} else { x = 0; } 出现,第二个 else if 已经接受了所有 x != 0 的情况,也就是说最后一个 else 那里 x 显然是 0... 那么这个 x = 0 有什么用...
原来你你们写代码都不是给人看的...
不错不错(上面的那个是抄代码的,连名字都不舍得改)
一个个 show 破天际,可是逻辑也没什么异于常人的,就这种代码还好意思谈什么优雅性,该抽提的不抽提该泛化的不泛化... 一大堆辣鸡超长代码堆积在一起,看这种代码我也是扑街了... 🤔
越复杂越容易堆砌,越简单越难于设计,好好把脑子用来想该想的东西,这些不良设计实践少做,不然遇到再难写一点的算法,该怎么办?
都去尝试理解你之前写的那些难看的算法了,复杂一点的算法,架构更大,怎么留出脑力去设计真正有用的东西?
重构火葬场?
This media is not supported in your browser
VIEW IN TELEGRAM
#Gimp #CG 尝试利用 GIMP 的 Python 脚本接口完成移动一堆固定模式 layer 的功能...
但是没有回应,因为他们吃光了所有牡蛎...
duangsuse::Echo
但是没有回应,因为他们吃光了所有牡蛎...
🤔 文本图层和普通图层、移动对象的方法都容易找到,我觉得如果有下次,可以写一个 GIMP 插件来画类似这样的动态图... 甚至可以自动执行过程可视化
辣鸡 GIMP 没有提供相应接口,但是有这样的福利可以制作快捷方式
总算让人省了一回心... (辣鸡 #Python 的 Unicode 支持不好,我使用 Unicode 符号做图层名,结果 python 索引到的字符串里居然都是不完整编码的,直接区间下标访问不方便,气死
不是不能这样,我不想... 人家是一个字符不是三个 unsigned int8...
anim_BlakcListRstrstr.xcf
1.6 MB
#Gimp #mulitmedia 一个小实验
实验需要使用到 #gui, Python 作为『脚本语言』自然带有一个,Tk Toolkit 的 TkInter,类似 Java 的 Swing