Special Complexity Handling for Left-Recursion Patterns?
See original GitHub issueHello, I have implemented the work here in C++ (https://github.com/schrodingerzhu/pika_cxx) but I found a special cases in the complexity analysis?
Consider
A <- (A ~ 'a') / 'a'
Of course, this should better be written in A <- 'a'+
, but the form should be okay for pika parser.
However, consider parsing aaaaaaaa
from the rightmost position,
at the k-th step:
parsed 'a' -> add A to queue -> parsed A with 'a' -> add A to queue -> parsed A with 'aa' -> add A to queue ...
This will repeat for k
times, so overall we should obtain a
1 + 2 + 3 + ... + length
steps and this should be quadratic?
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Analysis of Recursion in Data Structures and Algorithms
We will discuss these concepts of recursion analysis: recurrence relations of recursive algorithms, steps to analyze time complexity of recursion, recursion ...
Read more >Big O Time Complexity for Recursive Pattern - Stack Overflow
I'll take a stab at this. In a balanced binary tree, you should have half the child nodes to the left and half...
Read more >How to analyse Complexity of Recurrence Relation
Recurrence Tree Method: ... In this method, we draw a recurrence tree and calculate the time taken by every level of the tree....
Read more >L7. All Kind of Patterns in Recursion | Print All | Print one | Count
Check our Website: https://www.takeuforward.org/In case you are thinking to buy courses, please check below: Link to get 20% additional ...
Read more >8 time complexities that every programmer should know
To recap time complexity estimates how an algorithm performs regardless of the kind of machine it runs on. You can get the time...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@SchrodingerZhu I’m so sorry for the very delayed response. I was busy last October, then I forgot to come back to this.
Thanks for the detailed statistics and analysis. This does show that you are correct.
I think this is going to be unavoidable as a result of bottom-up, right-to-left parsing with this grammar, since the beginning of the
OneOrMore
run cannot be known a priori.The following grammar should exhibit linear performance, since the rule is right-associative:
The reason this degrades to O(N^2) in the left-associative (left-recursive) case is that the beginning (innermost match) of the tree of left-associative (left-recursive) matches cannot be known a priori when matching right to left. But all matches have to be memoized along the way – so this is wasted work.
I actually don’t see a way to fix this, and I don’t think it’s fixable for this algorithm. This does undermine the strongest claim of this algorithm – that it is linear in the length of the input, albeit with a large constant overhead of wasted work. (Now the overhead is itself linear in the length of the input, making the overall performance O(N^2) in the length of the input.)
I really appreciate you pointing this out! This makes me think I should not publish this paper…
Actually the reason I remembered to come back to this bug report though was because this evening I had an idea about an extremely simple modification of standard left-to-right, top-down packrat parsing to enable it to support left recursion. I am planning to implement this to test it. I can let you know whether it works, if you are interested.