> Nevod is a language and technology that provide pattern-based text search. Nevod is specially aimed to rapidly reveal entities and their relationships in texts written in the natural language. This patent pending technology is unique on the market. What is this? A website, a tool? Can I run it locally? Is it free software, open source, close source? Where is the information about the patent? Also, you mention it's…
The patent kills it for me even though it may just be for defense (I didn't look and it sounds like they didn't say).
Show HN: Nevod is easier and faster than RegExp
31–40 of 82 posts
Re: Show HN: Nevod is easier and faster than RegExp
#32Earlier quoted context omitted.
Well, except Perl doesn't parse regular grammars (it parses much more) and is far from being "one pass" (since the complexity guarantees are not valid anymore) ....
Regular grammars a strict subset of what Perl 6 will parse, no? If you stick to that subset it will parse in a single pass.
My point is simply that Perl doesn't give you any guarantee except "we will try to parse it". Maybe you will hit the right case for the right version of Perl, who knows ? The Web is full of DDOS attack based on exponential PCREs.
With actual regular expression, the complexity is guaranteed.
Re: Show HN: Nevod is easier and faster than RegExp
#33Re: Show HN: Nevod is easier and faster than RegExp
#34You could easily do something like this using open source parser generators, like Pegjs( https://github.com/pegjs/pegjs ) and own the final code yourself.
I'm not familiar with Pegjs, but other PEG parsers I've seen tend to use the packrat algorithm, which is suboptimal for regular languages, because it memoizes parses to speed up backtracking, and regular languages do not need backtracking.
For example, if you were to write a recursive-descent parser for JSON and convert it to a packrat parser, you will often find the packrat parser is slower.
Now, extended regex's include backtracking, and that's where packrat parsers can soundly defeat recursive-descent parsers: super-linear time parses can become linear time. This makes packrat parsers a wonderful "default choice" but if constant factors are important and your language is regular, you will want to look beyond packrat parsers.
Re: Show HN: Nevod is easier and faster than RegExp
#35Like the other sibling comments mentioned, I too was confused about "100x faster than regex" and what the actual product was about. After digging around their website, I found this blog post which explains it better: https://blog.nezaboodka.com/post/2019/594-using-nevod-for-te... So my summary would be: 1) it works "faster" than regex in a specific scenario of treating text as entities in natural language . (E.g. hig…
The Nevod example translates to (ruby):
pattern = Regexp.new( "(?ejection fraction|LVEF)( by visual inspection)?
(?(is|of)( (at least|about|greater than|less than|equal to))?)
(?[0-9]+(-[0-9]+)?|normal|moderate|severe)".gsub(/\s+/, "\\s+"),
Regexp::IGNORECASE)
["ejection fraction is at least 70-75",
"ejection fraction of about 20",
"ejection fraction of 60",
"ejection fraction of greater than 65",
"ejection fraction of 55",
"ejection fraction by visual inspection is 65",
"LVEF is normal"].each do |line|
puts line
puts pattern.match(line).inspect
end
The only trick I used was to substitute literal whitespace in the regex with a whitespace pattern, so that the typed regex was more readable.Re: Show HN: Nevod is easier and faster than RegExp
#361. the ability to easily break patterns into named subpatterns which can be referenced later on
2. the `@` operator which gives you the ability to talk about things inside these subpatterns
These seem like worthwhile additions which would make regex more manageable. I don't see any reason why the whole of regex would need to be abandoned for some completely new, potentially proprietary technology, though.
It also reminds me of parser combinators (in the form they are popular in Haskell, for instance).
Re: Show HN: Nevod is easier and faster than RegExp
#37> Nevod is a language and technology that provide pattern-based text search. Nevod is specially aimed to rapidly reveal entities and their relationships in texts written in the natural language. This patent pending technology is unique on the market. What is this? A website, a tool? Can I run it locally? Is it free software, open source, close source? Where is the information about the patent? Also, you mention it's…
No thanks. Off you go.
Re: Show HN: Nevod is easier and faster than RegExp
#38Earlier quoted context omitted.
Regular grammars a strict subset of what Perl 6 will parse, no? If you stick to that subset it will parse in a single pass.
Except Perl 6 doesn't enforce it, so you have to guess yourself if you are really in the regular case. Additionally, PCRE used to be exponential for certain "bad cases", some of which were (truly) regular expressions. My point is simply that Perl doesn't give you any guarantee except "we will try to parse it". Maybe you will hit the right case for the right version of Perl, who knows ? The Web is full of DDOS attack…
Re: Show HN: Nevod is easier and faster than RegExp
#39> Pattern definition language is simple and clear, thus very easy to learn Once you get into more complicated expressions, I don't see this as much easier or simpler than regexes. For example, this expression from the tutorial looks as much like gibberish to me as an equivalent regex: Domain = Word + [1+] ("." + Word + [0+] {Word, "_", "-"}); That said, I can see some possible value in pattern matching based on text…
I think the hard part of pattern matching is reasoning about pattern matching. The obscurity of Regex notation is mostly a function of unfamiliarity with the concepts. [:word:]+ is not easier to reason about than \w+ and "\w+" is much better documented than "[:word:]+" or "Word + [1+]."
The other problem with learning Regex's is that regex notation is someone else's code. There's always the attraction of fixing it. I've dunning-kuger'ed it myself. Fortunately, making my new more sensible superduper regex notation complete required RTFM'ing...and then I'd read the manual and realized I'd already fixed regex notation by fixing the absence of knowledge in my head. Plus I could talk to other people about pattern matching using the common language of pattern matching.