@encro 封号是个问题，也许征集粉丝账号搞个投稿群可解？

@2i2Re2PLMaDnghL cc 字幕能替代弹幕？弹幕那么多，你别骗我

@garlics 其他平台的，不是 B 站直播

@banlifeather4 很正常的需求，不知道你想问什么，比如手机作为唯一身份认证终端的时代 ，丢手机当然不是 0 概率事件，其他认证方式同理，你这问题属于想的太多做得太少，做了就遇到这种需求了。

目前已经搞了个应该在哪个视频什么时间发什么弹幕的列表，但是不知道怎么自动化发，太多了又不能手动发

@duola 那也不便宜啊，换算成 GB 的话大概是 1M ，而 1GB 大概仅能看 5-10 集动画，假设网站每天走 10 万个播放，这个用户不算太大，那也是两个月就花光了 3W 块

@huxiaofan1223 jwt 只能应对它的初始设计场景，也就是令牌签发后有效期内一直有效。如果你有后续的需求，比如用户的令牌丢了，或者用户想要改密码，要让已签发的令牌失效，那么 jwt 就不能做到，需要在 jwt 基础上再加补丁。而补丁的实现，由于把存在性校验换成了不存在性校验，算法上确实可以做到一定的优化，但这种优化往往只有在特大数据量下才能表现出实际差距，考虑到开发成本，这未必值当。对于没想清楚需求的应用来说，直接保存 sessionid 是最直接也最方便的做法。

@Veneris 感觉问题不大，稍微切一切分一分，感觉大厂也能接受这种架构，挺合理的

@Veneris 懂了，所以你的意思是防止重放攻击的手段是 redis 上搞个队列，里面存全服所有的（ appId + 接口 + 时间戳 + 随机数）请求，比如维护一个三分钟队列之类的，这样队列也不会特别吃内存，搜索开销也不大，这样？

大概看了一眼楼上说的应该没问题，并非所有类型的任务都能通过异步加速，你要做好心理准备。另外 aiofiles 的实现其实很丑陋。。楼上说是线程池跑的，我有点忘记具体情况了，只记得以前读源码的印象是很丑陋。。

magic method 翻译过来是魔术方法，不是魔法函数，LZ 你还是别面试别人了，在我这首先不合格。所谓 python 的精髓在鸭子类型，好一个 javaer 发言，只能说这是在往 py 迁移多态中产生的错误想法，py 的精髓跟鸭子类型也一毛钱关系没有。啥水平的还能面试人还能出来发帖吐槽？

@xingzhi 个人看法，无论如何，开发中就算有一丁点可能性动到生产服务器的数据，我都觉得是一件很可怕的事情。。

不太理解是什么使用场景，如果每次都在 main 分支上提交的话，似乎与传统的锁行锁表也区别不大，如果在分支上再开新分支的话，这在数据库有啥用呢

@houshuu
@oblivious
@raycool 大佬们知不知道现在常用的激活函数是什么？我看一些文章写 elu 效果不错，可以在 elu 后不用接 nb 层以起到减小模型的目的，如果想要在网络里面自己调整激活函数（比如用一个经典的 resnet18 模型，然后想要改一改激活函数的话）有什么文章可以指导这种修改逻辑吗？

还有就是我想学习经典模型的话，我看 torchvision 里面有一些预训练好的模型，但是数量比较少，我看类似 resnet34 和 resnet50 这种都没有，我想学习 resnet34 的参数，网上写的比较详细的文章不是很好搜

其实我感觉倒不算滥用，毕竟 py 做胶水，其他语言做里子就是 py 的常见特性之一。分发方面我以前折腾过 win ，linux 的多发行版没折腾明白，如果 lz 明白还请教我。确实如 lz 所说无法直接部署到系统目录，需要使用 py 的构建命令能力，但是调用 api 的话 py 有多版本二进制重编译的问题，比如 cython 的构建结果不能跨版本，pyo3 也是一样，发布的 ci 上要费点功夫

非专业，不过 1 印象里类似超分这种算法确实是几层卷积，（印象里早期层数很少），后来好像要在后面加逆卷积层

@GuuJiang 感谢，所以一般说的矩阵乘法，不是指 element-wise product ，而是指这个 dot ，是按照这个逻辑计算，比如 2*3 矩阵乘 3*2 矩阵得到 2*2 矩阵这样？然后向量的点乘则是指矩阵点乘中的某一步，即按顺序每个位置相乘然后加和，向量的叉乘的话则使用其他逻辑，矩阵不存在叉乘这样？


@qq8331199 这个前几年看过，印象里他主要解释向量计算的物理含义的，看完有收获但是太长时间不用也忘了。而且向量和矩阵关系没搞明白也妨碍我理解

@binux 建议重修义务教育语文，本帖标题为“有没有将近似的 hash 认为是相同 hash 的 hashset ？”，一般认为 hash 是字符串结构，标题含义为，传统 hashset 精确匹配，如何应对不精确匹配的情况，不知道你在杠什么。另外实际使用中图片去重就是要对抗模糊剪裁缩放。实际使用场景就是互联网上的图片来源，相同图片会被各种裁剪 /调整比例 /反复压缩，我不知道你是哪里的实际使用经验，去重时不需要考虑这些问题。


@3dwelcome 老哥你是楼里唯一一个一直在认真回我的，我最后给你更新一下我的解决办法。首先我使用的 phash 算法没有进行 dct ，而是直接用 rgb 模式下的三平面的向量变化，也就是单个平面里面 8*8 向量的增加或减少来形成 hash 。我对我自己的场景做了一些小修改，因为我的图片大多为电脑或手机屏幕适配，通常为 16:9 或者 9 比 16 的近似比例，我把 8*8 稍微扩大了一些。

关于近似去重，最后采用的是多年前谷歌的近似 simhash 搜索的简化方法，需要储存结构做对应优化。其原理是，如果要求一个长度为 64 （或任意）的 binary ，与另一个等长 binary 的汉明距离小于 3 （意味着他们之间有 0 处或 1/2/3 处不同），那么只需要将 64 平均分割为 4 段，即使出现 3 处不同，4 段中的某一段一定完全相同。同理，如果要求距离小于 20 ，则平均分割为 21 段。将其转化为完全相同问题后，可以利用 hash 结构的索引能力，原先需要遍历十万次对比，现在只需要进行 4 次索引，挑选出完全相同的集合的并集，他们之中有可能存在不符合需求的结果，但符合需求的（汉明距离小于 3 ）一定在其中，在此基础上进行完全搜索，即可精准定位。

使用这个方法后，原先的 100k 数量级对象总共需要进行 5 亿次遍历（加上我的向量数量为 800+，总计需要 4000 亿次向量相等计算），可以优化到非常低的水平，我目前的数据集大小是可以 1s 内出结果的，优化之前速度非常慢。

@binux 朋友你真的认真看主题了吗？主题询问的是近似字符串去重算法，而不是图片摘要算法，提到图片无非是为了进一步解释背景而已，你在这里叫嚷说有很多成熟算法，如果你很熟悉，不屑于参与这种低级讨论，请直接发关键字或文章链接，而不是反复地发“有很多，为什么你不用”。如果你认为相同图片经过合适算法的摘要本身就是相同的，那只能说既然是感知哈希，无非是精度问题

@yfugibr aaaaa 变成 bbbbb 的问题是输入顺序导致的，排序后应该问题不大

@Vegetable 我知道，我觉得 timeit 不好用

@SmiteChow 如果要多写一行 runner(inner)我感觉直接写 for _ in range(100)也一样了。。