in reply to Re^2: Patience Sorting To Find Longest Increasing Subsequence
in thread Patience Sorting To Find Longest Increasing Subsequence
A merge sort is only O(N^2) worst case so no,
No, a merge sort is worst case O(n log n).
You are welcome to use a Van_Emde_Boas_tree which claims to be able to do the whole thing in O(N Log N)
Actually the paper by Bespamyatnikh & Segal contains a proof that you can do it in O(N log log N) time. I havent verified it tho.
But I doubt that the vEB based algorithm would in practice beat a simpler algorithm to do patience sorting. Unless I guess if you were dealing with a deck with tens of thousands or even millions or billions of cards. The overhead of maintaining a vEB tree is prohibitive for small datasets. The cost of doing binary operations on the keys, maintaining the vEB tree and etc, would most likely outweigh that of a simpler less efficient algorithm.
As bart said, sometimes a binary search algorithm is not as fast a scan, even though one is O(log N) and the other is O(N). The reason of course is that big-oh notation glosses over issues like cost per operation, and only focuses on the "overwhelming factor" involved. So in a binary search if it takes 4 units of work to perform an operation and in linear search it takes 1 then binary search only wins when 4 * log N < N, so for lists shorter than 13 elements there would be no win to a binary search. And I'd bet that in fact the ratio is probably something like 20:1 and not 4:1. Apply this kind of logic to a deck of 52 cards, and IMO its pretty clear that vEB trees are not the way to go for this, regardless of the proof.
$world=~s/war/peace/g
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: Patience Sorting To Find Longest Increasing Subsequence
by Limbic~Region (Chancellor) on May 06, 2006 at 14:11 UTC | |
by demerphq (Chancellor) on May 07, 2006 at 19:10 UTC |