Live data from Hacker News

Show HN: Nevod is easier and faster than RegExp

nevod.nezaboodka.com

31–40 of 82 posts

Re: Show HN: Nevod is easier and faster than RegExp

#31
post #3

> 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).

Well, it will eventually expire so we can revisit this then

Re: Show HN: Nevod is easier and faster than RegExp

#32
post #29
post #23

Earlier 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.

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 based on exponential PCREs.

With actual regular expression, the complexity is guaranteed.

Re: Show HN: Nevod is easier and faster than RegExp

#34

You could easily do something like this using open source parser generators, like Pegjs( https://github.com/pegjs/pegjs ) and own the final code yourself.

[edit] After reading my comment it sounds like I don't like packrat parsers. I actually love them and when they are available for the language I'm using they are my first choice, but the first rule of engineering is everything has it's trade-offs, so...

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

#35
post #25

Like 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…

My reading of that is that they compared apples and oranges. They didn't use NLP there at all (stemming, parts of speech tagging, etc); they just relaxed handling of whitespace. The Nevod 'equivalent' was a less general expression to make it seem more maintainable.

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

#36
I see two novel aspects of this language:

1. 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
post #3

> 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…

When it comes to any kind of programming library:ish thing, there's no bigger turn-off than "patent pending technology".

No thanks. Off you go.

Re: Show HN: Nevod is easier and faster than RegExp

#38
post #32
post #29

Earlier 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…

The way regular expressions work in Perl doesn't randomly degrade across Perl versions. For a given regex you can determine what it's complexity would be across versions just like you would for an arbitrary chunk of Perl code. It's true you don't always get a complexity guarantee for free like in a DFA implementation of formal regular expressions.

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…

In the end, automata are automata and anything that tries to do what regex's do winds up looking a lot like regex's -- which look a lot like regular expressions (as a representation of a finite state machine). The difference between "regex alternatives" and regex's is that the alternatives tend to be more verbose and less well documented...and less likely to elicit good answers on StackOverflow...and perhaps less likely to generate good questions there.

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.

Post reply on HN