All the algorithms presented above have theoretically a running time of O(m+n) where m,n are the sizes of the lists.
Not true. Since BrowserUK's algorithm needs to allocate and initialize a string with max(@a, @b) bits, it has O(n + m + max(@a) + max(@b)) run time (you mentioned another problem that arises from large numbers, but not in terms of complexity).
OTHO max(@a, @b) is the numerical value, not an input length.
To make the two things comparable, you'd have to settle on a representation, let's say binary. Then you'd say that length(binary($x)) is roughly log(x)/log(2), so that the overall runtime is actually O(m + n + log(max(@a)) + log(max(@b)), now with all factors being in the same units, so-to-say.
(I hope I didn't mess this up entirely, it's late at night here, I'll take another look tomorrow to see if it still makes sense to me)
In reply to Re^2: Fast, Efficient Union and Intersection on arrays
by moritz
in thread Fast, Efficient Union and Intersection on arrays
by barvin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |