4 ms·
Thanks for writing this up. I'm solving a similar problem, albeit different in a few important ways, and was planning on taking a semi-similar approach. Like yo
by staticassertion 6y ago
Thanks for writing this up. I'm solving a similar problem, albeit different in a few important ways, and was planning on taking a semi-similar approach. Like you, today I'm using a fairly naive implementation with some less-than-ideal complexity.
I've never actually worked with a prefix tree before, so this was quite helpful for me.
This may be of interest as well - a related paper, Pigasus, does this with specialized hardware but it's a similar problem of applying 10s of thousands of rules as quickly as possible. I found it while reading through acolyer's morning paper.
https://blog.acolyer.org/2020/11/16/pigasus/ https://blog.acolyer.org/2020/11/16/pigasus/
Again, slightly different task - they wouldn't be going for the longest match exclusively, but all matches. Also, the rules they use are fundamentally regular expressions, so the filtering pass is to take advantage of the domain specific knowledge that rule-matches are very rare.
- taeric 6y agoMy guess is your "fundamentally regular expressions" is, in fact "fundamentally an automata". Which, my guess is even this article could have used an automata such that they are basically lexing the data they are using over.
- staticassertion 6y agoI assume you're saying that the regular expressions used are likely to be equivalent to a DFA? If so, I agree, that's very likely, and I was also thinking about that. I believe Go's regex engine is built on RE2 though, so idk.
- taeric 6y agoEssentially, yes. My point is if you implemented the dfa directly, then you could just iterate all the characters doing whatever the current state of the automata says to do at each character.
- nemoniac 6y ago"Automata" is plural. Its singular is "automaton".