Live data from Hacker News

On the Worst-Case Complexity of TimSort

drops.dagstuhl.de

11–20 of 78 posts

Re: On the Worst-Case Complexity of TimSort

#11
post #5

Given that rho can vary with the input and is completely arbitrary value, shouldn’t be also called n? Memories on the subject are not great so might be saying bullshit in here

It shouldn't be called n because then `n log n` and `n log m` convey different meanings. In the first case, `n` is one and the same variable, where in the second, `n` and `m` are independent of each other. You can call it `m` or `rho` or whatever, just use a different variable.

Here, ρ is not independent of n, though

Re: On the Worst-Case Complexity of TimSort

#12

Given that rho can vary with the input and is completely arbitrary value, shouldn’t be also called n? Memories on the subject are not great so might be saying bullshit in here

In the worst case, rho is equal to n, and you get O(n log n). However, O(n + n log rho) gives a better description of how it performs on partially sorted arrays.

And in the best case (already sorted array), it's equal to 1 and the algorithm performs as O(n), which is nice to prove in one go.

In some other typical cases (otherwise sorted array with one element inserted, two sorted arrays appended to each other) rho is 3 and 2, so also O(n).

Re: On the Worst-Case Complexity of TimSort

#13
post #4

How is it that the abstract is talking about "Java version" and "Python version" when discussing computational complexity? Aren't algorithms algorithms, independent of the language you're implementing them in?

From the article:

> In fact, there are two slightly different versions of TimSort that are currently implemented in Python and in Java respectively.

Re: On the Worst-Case Complexity of TimSort

#14
post #11
post #5

Earlier quoted context omitted.

It shouldn't be called n because then `n log n` and `n log m` convey different meanings. In the first case, `n` is one and the same variable, where in the second, `n` and `m` are independent of each other. You can call it `m` or `rho` or whatever, just use a different variable.

Here, ρ is not independent of n, though

[deleted]

Re: On the Worst-Case Complexity of TimSort

#16
post #4

How is it that the abstract is talking about "Java version" and "Python version" when discussing computational complexity? Aren't algorithms algorithms, independent of the language you're implementing them in?

Yes. If the java have a different complexity it is a different algorithm. To the writers defense, they have to algorithm in pseudo code in the article

> If the java have a different complexity it is a different algorithm.

It doesn't seem wrong to me to talk about different versions of the same algoritm when there are only minor differences.

Re: On the Worst-Case Complexity of TimSort

#17
The linked java test file, http://igm.univ-mlv.fr/~pivoteau/Timsort/Test.java - still crashes the latest Java 10.0.2 with an 'Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 49'. Amazing! I wonder if this makes some web services vulnerable.. if the user can submit a just-so array of ints to be sorted? But it does seem like it would require uploading a really huge array (>4GB?)

Re: On the Worst-Case Complexity of TimSort

#18
post #11
post #5

Earlier quoted context omitted.

It shouldn't be called n because then `n log n` and `n log m` convey different meanings. In the first case, `n` is one and the same variable, where in the second, `n` and `m` are independent of each other. You can call it `m` or `rho` or whatever, just use a different variable.

Here, ρ is not independent of n, though

Rho is always 1 to n as defined.

In randomized input with uniform statistics, should be on average (n - log n) which also gives a handle on theta notation complexity.

Re: On the Worst-Case Complexity of TimSort

#19

Given that rho can vary with the input and is completely arbitrary value, shouldn’t be also called n? Memories on the subject are not great so might be saying bullshit in here

In the worst case, rho is equal to n, and you get O(n log n). However, O(n + n log rho) gives a better description of how it performs on partially sorted arrays.

Nitpick: \rho = n/2 in the worst case, if n > 1, but that still gives you O(n log n).

Re: On the Worst-Case Complexity of TimSort

#20

Given that rho can vary with the input and is completely arbitrary value, shouldn’t be also called n? Memories on the subject are not great so might be saying bullshit in here

In the worst case, rho is equal to n, and you get O(n log n). However, O(n + n log rho) gives a better description of how it performs on partially sorted arrays.

Exactly. Sometimes those are called "adaptive algorithms", in the sense that the complexity depends on some properties of the input, so even though the worst case complexity is still O(n log n), for many outputs it will do much better.
Post reply on HN