碧蓝幻想很休闲的.jpg

ac 自动机

@gulu 有的， python tornado 的团队，下周一会有人联系你的。另外提点小建议 SICP 和 CLRS 虽然都很好但是作为对应领域的第一本书是不一定合适的， SCIP 建议计算理论（ theory of computing ）方面的书作为前置补充， CLRS 则建议先学好高德纳的具体数学，有了这些基础你看这两本书得到的理解会是完全不一样的。

楼主愿意来上海吗？

@yangxin0 https://github.com/google/re2/blob/ee55a8f64d253bdf5bfa98e8d09901a5fb9ee13c/re2/set.cc 这是 re2 的统一自动机构建
https://github.com/google/re2/blob/ee55a8f64d253bdf5bfa98e8d09901a5fb9ee13c/re2/filtered_re2.cc
这是我前面提到的大量正则过滤模式
一般来说超过三位数的正则 filtered_re2 性能就要好于 set 了

@7sDream 其实 NFA 转 DFA 状态是会指数爆炸的，现在主流的 dfa 引擎像 Google 的 re2 都只是做了部分转换也只能 handle 不超过三位数的并行匹配，对于更大数量的 Google re2 的做法是构建一个 ac 自动机，将每条正则的元字符组成字串塞进去，当一个 input 进来的时候如果匹配就将他加入 potential match list 最后匹配这个 list ，总之做法非常工程非常“ low ”（并不

重新排版编辑了，简单来说是一个用 Haskell 写的可以对正则表达式求交集，子集和相等性的库，实际适用场景是像有海量正则需要同时过滤的时候用于消除冗余逻辑， 不过其实比起实际价值这种用抽象代数的方法计算正则表达式的形式更加值得关注。

啊发现排版一塌糊涂忘了写 md_(:з」∠)_ 可是已经来不及编辑了....

自己移好了...实在抱歉没认真看

啊...发现发错区了...请 @livid 移动到技术区去吧

@menc 嗯 LDA 确实不太适合短文本，实际上我们自己的短文本聚类都是用 w2v+sparse encoding 做的

@lijinma 我们公司语料比较特殊，为了处理多语言分词是自己定制的。一般对于分词不准的情况可以使用 2gram ，就是比如“我爱北京天安门”分成 我爱 爱北 北京 京天 天安 安门

最简单的思路是做一个超级大的向量，对于词表里面的词如果这个用户提过就记 1 否则记 0 ，分布到向量空间里面通过求欧氏距离来做聚类，数据用 kd-tree 来存这样每次查找都是 log 时间了。但是你这样做维度肯定非常大，可以用 kmeans 直接聚中心点，我做过的 case 聚到 300 维效果还是非常好的

@lijinma 不是大神_(:з」∠)_ ，工作是做 nlp 对这方面有点了解，你在 6 楼提到的问题可以用 knn 来算，维度在 100 以下还可以用 kd-tree 来加快检索

更简单点的方法是基于词做 embedding 然后对每个短文本做 bow 的 sparse encoding, 然后对每一条短文本再做一次 sparse encoding 最后用 distance 求相似度，如果维度太高用 pca 或者 sparse coder / auto encoder 降个维

从纯文本分析的话可以考虑 LDA 做主题模型，分词不准的话用 ngram 来做

@lidatui 您是 iOS 那位吧，我已经通知 hr 联系了，她们办事可能比较拖...

本来不想写薪资所以上面写的很保守是要求不高的应届生都能胜任的批发价，可能不适合 V2EX 大大们的逼格，这里先道个歉。
如果你觉得不只值这么多，纯技术人员最高 50 都是可以谈的。如果 50 还不能满足你我们不是还在招技术负责人吗

总之我的意思是薪资真的不是问题，只要你能说服我你真的值这个薪资

有楼主头像相关的职位吗（