backtracking

Consider this regex. a*b This will fail in case of aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac This takes 67 steps in debugger to fail. Now consider this regex. (?>a*)b This will fail in case of aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac This takes 133 steps in debugger to fail. And lastly this regex: a*+b (a variant of atomic group) This will fail in case of aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac This takes 67 steps in debugger to fail. When I check the benchmark atomic group (?>a*)b performs 179% faster. Now atomic groups disable backtracking. So performance in match is good. But why are the number of steps more? Can

The set [1,2,3,…,n] contains a total of n! unique permutations. By listing and labeling all of the permutations in order, We get the following sequence (ie, for n = 3 ) : "123" "132" "213" "231" "312" "321" Given n and k, return the kth permutation sequence. For example, given n = 3, k = 4, ans = "231". There are multiple solutions out there. But all of them uses either factorial or there complexity is larger than O(n) such as O(n!). If you use factorial and find the number at the position by k/(n-1)!, the problem comes when n is large(n = 100). Here as n is large, (n-1)! overflows and becomes

I am programming a Sudoku solver in Java for a 9x9 grid. I have methods for: printing the grid initializing the board with given values testing for conflicts (if same number is in same line or 3x3 sub-grid) a method to place the digits, one by one, which requires the most work. Before I go into detail with that method, keep in mind that I have to use recursion to solve it, as well as backtracking (watch the applet here as an example http://www.heimetli.ch/ffh/simplifiedsudoku.html ) Also, I am solving this Sudoku by moving vertically downwards, starting from the top left, through the first

I am trying to find the best way to solve the following problem. By best way I mean less complex. As an input a list of tuples (start,length) such: [(0,5),(0,1),(1,9),(5,5),(5,7),(10,1)] Each element represets a sequence by its start and length , for example (5,7) is equivalent to the sequence (5,6,7,8,9,10,11) - a list of 7 elements starting with 5. One can assume that the tuples are sorted by the start element. The output should return a non-overlapping combination of tuples that represent the longest continuous sequences(s). This means that, a solution is a subset of ranges with no overlaps

So the univ operator. I don't exactly understand it. For example this: foo(PredList,[H|_]) :- bar(PredList,H). foo(PredList,[_|T]) :- foo(PredList,T),!. bar([H|_],Item) :- G =.. [H,Item],G. bar([_|T],Item) :- bar(T,Item). What is this doing? This looks to see if another predicate is true. I don't understand what the ".." does. How would you rewrite this without the univ operator? Univ ( =.. ) breaks up a term into a list of constituents, or constructs a term from such a list. Try: ?- f(x,y) =.. L. L = [f, x, y]. ?- f(x,y,z) =.. [f|Args]. Args = [x, y, z]. ?- Term =.. [g,x,y]. Term = g(x, y).

Can someone explain why Java's regex engine goes into catastrophic backtracking mode on this regex? Every alternation is mutually exclusive with every other alternation, from what I can tell. ^(?:[^'\"\\s~:/@#\\|\\^\\&\\[\\]\\(\\)\\\\\\{\\}][^\"\\s~:/@#\\|\\^\\&\\[\\]\\(\\)\\\\\\{\\}]*| \"(?:[^\"]+|\"\")+\"| '(?:[^']+|'')+') Text: 'pão de açúcar itaucard mastercard platinum SUSTENTABILIDADE]) Adding possessive matching to some of the alternations fixes the problem, but I have no idea why - Java's regex lib must be extremely buggy to backtrack on mutually exclusive branches. ^(?:[^'\"\\s~:/@#\\