You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
is_permutation() is, famously, a quadratic-time algorithm. It currently has a significant amount of logic attempting to avoid this worst case. It begins by trimming matching prefixes, and then trims matching suffixes, before running the quadratic-time algorithm on the presumably jumbled cores of the sequences.
There's a fairly simple improvement that could further improve performance. Note that if two sequences are the reverses of each other, then trimming matching prefixes and suffixes won't help (very much). But comparing opposite ends would help. Although that would spend more comparisons, I believe that the cost is inherently very limited, and worth it to reduce the quadratic part.
I haven't analyzed this in detail, but I initially believe that the right strategy would be to trim matching prefixes (as required by the Standard; this handles equal sequences in linear time, and works for forward-only iterators). Then we should repeatedly attempt up to 4 comparisons:
Back of A == Back of B (matching suffix)
Back of A == Front of B
Front of A == Back of B
Front of A == Front of B (matching prefix)
If any of these comparisons are equal, we should consume and repeat. (Although we initially drain matching prefixes, after we consume anything at the front, the prefixes might match again.) If none are equal, then we run the quadratic part.
is_permutation()
is, famously, a quadratic-time algorithm. It currently has a significant amount of logic attempting to avoid this worst case. It begins by trimming matching prefixes, and then trims matching suffixes, before running the quadratic-time algorithm on the presumably jumbled cores of the sequences.There's a fairly simple improvement that could further improve performance. Note that if two sequences are the reverses of each other, then trimming matching prefixes and suffixes won't help (very much). But comparing opposite ends would help. Although that would spend more comparisons, I believe that the cost is inherently very limited, and worth it to reduce the quadratic part.
I haven't analyzed this in detail, but I initially believe that the right strategy would be to trim matching prefixes (as required by the Standard; this handles equal sequences in linear time, and works for forward-only iterators). Then we should repeatedly attempt up to 4 comparisons:
If any of these comparisons are equal, we should consume and repeat. (Although we initially drain matching prefixes, after we consume anything at the front, the prefixes might match again.) If none are equal, then we run the quadratic part.
STL/stl/inc/xutility
Lines 4461 to 4595 in f9b1dcc
The text was updated successfully, but these errors were encountered: