Minimum depth of a leaf in a tree that corresponds to a comparison-based sorting algorithm





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}








3












$begingroup$


The lower bound of comparisons in a comparison-based sorting algorithm is $log_2 n!=Θ(nlog n)$. Yet there can be less comparisons needed in an algorithm.
If you take a sorted array, it will take $n-1 = O(n)$ comparisons (with insertion sort) to sort the array — comparing every adjacent pair of numbers. I don't understand then how is $log_2 n!=Θ(nlog n)$ the lower bound.



I also don't understand the corresponding trees to the sorting-based algorithms:
each leaf in the tree corresponds to one of the permutations of the $n$ numbers. If the minimum number of comparisons needed is $log_2 n!$ then the depth of every leaf should be at least $log_2 n!$, yet I saw that it's possible for a leaf to be with depth of $O(n)$.



Can there be leaves with depth even smaller than $n-1$?










share|cite|improve this question











$endgroup$





















    3












    $begingroup$


    The lower bound of comparisons in a comparison-based sorting algorithm is $log_2 n!=Θ(nlog n)$. Yet there can be less comparisons needed in an algorithm.
    If you take a sorted array, it will take $n-1 = O(n)$ comparisons (with insertion sort) to sort the array — comparing every adjacent pair of numbers. I don't understand then how is $log_2 n!=Θ(nlog n)$ the lower bound.



    I also don't understand the corresponding trees to the sorting-based algorithms:
    each leaf in the tree corresponds to one of the permutations of the $n$ numbers. If the minimum number of comparisons needed is $log_2 n!$ then the depth of every leaf should be at least $log_2 n!$, yet I saw that it's possible for a leaf to be with depth of $O(n)$.



    Can there be leaves with depth even smaller than $n-1$?










    share|cite|improve this question











    $endgroup$

















      3












      3








      3


      1



      $begingroup$


      The lower bound of comparisons in a comparison-based sorting algorithm is $log_2 n!=Θ(nlog n)$. Yet there can be less comparisons needed in an algorithm.
      If you take a sorted array, it will take $n-1 = O(n)$ comparisons (with insertion sort) to sort the array — comparing every adjacent pair of numbers. I don't understand then how is $log_2 n!=Θ(nlog n)$ the lower bound.



      I also don't understand the corresponding trees to the sorting-based algorithms:
      each leaf in the tree corresponds to one of the permutations of the $n$ numbers. If the minimum number of comparisons needed is $log_2 n!$ then the depth of every leaf should be at least $log_2 n!$, yet I saw that it's possible for a leaf to be with depth of $O(n)$.



      Can there be leaves with depth even smaller than $n-1$?










      share|cite|improve this question











      $endgroup$




      The lower bound of comparisons in a comparison-based sorting algorithm is $log_2 n!=Θ(nlog n)$. Yet there can be less comparisons needed in an algorithm.
      If you take a sorted array, it will take $n-1 = O(n)$ comparisons (with insertion sort) to sort the array — comparing every adjacent pair of numbers. I don't understand then how is $log_2 n!=Θ(nlog n)$ the lower bound.



      I also don't understand the corresponding trees to the sorting-based algorithms:
      each leaf in the tree corresponds to one of the permutations of the $n$ numbers. If the minimum number of comparisons needed is $log_2 n!$ then the depth of every leaf should be at least $log_2 n!$, yet I saw that it's possible for a leaf to be with depth of $O(n)$.



      Can there be leaves with depth even smaller than $n-1$?







      sorting






      share|cite|improve this question















      share|cite|improve this question













      share|cite|improve this question




      share|cite|improve this question








      edited May 27 at 11:11









      Yuval Filmus

      208k15 gold badges202 silver badges369 bronze badges




      208k15 gold badges202 silver badges369 bronze badges










      asked May 27 at 10:21









      marianovmarianov

      644 bronze badges




      644 bronze badges

























          2 Answers
          2






          active

          oldest

          votes


















          2














          $begingroup$

          The lower bound is for the worst-case number of comparisons. Every comparison-based sorting algorithm performs $Omega(nlog n)$ comparisons in the worst case. This means that the tree has depth $Omega(nlog n)$.



          If you don't like the tree argument, here is an adversary argument which is basically a reformulation of the tree argument. We will maintain the set $Pi$ of all permutations consistent with the answers so far. When the algorithm compares $i$ to $j$, we answer the result which reduces $Pi$ by at most a half (one of the two answers must have this property). After $log_2 (n!/2)$ steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least $log_2 n! = Omega(nlog n)$ comparisons on this branch.



          In fact, we can strengthen this result (going back to the tree argument): every comparison-based sorting algorithm makes $Omega(nlog n)$ comparisons on average (when the input is a random permutation of $1,ldots,n$). For the proof, note that there can be at most $2^k$ leaves at depth $k$. In particular, the number of leaves at depth $(log n!)/2$ is at most $sqrt{n!}$. Therefore for at least $n! - sqrt{n!}$ permutations, all leaves are at depth more than $(log n!)/2$, and for this $1-o(1)$ fraction of permutations, the algorithm will make at least $(log n!)/2 = Omega(nlog n)$ comparisons.



          Finally, let us show that you cannot possibly know the correct permutation if you perform less than $n-1$ comparisons. Construct a graph whose vertices are the elements of the array, and $(i,j)$ are connected if you compared the elements at these positions. If you make less than $n-1$ comparisons, then the graph won't be connected. In particular, you can partition the vertex set into two non-empty parts $A,B$ such that no element of $A$ was compared to any element of $B$. In particular, there is a permutation consistent with the performed comparisons in which all elements of $A$ are smaller than all elements of $B$, and another one in which all elements of $A$ are larger than all elements of $B$.






          share|cite|improve this answer









          $endgroup$















          • $begingroup$
            Can you please explain why does every comparison reduces Π (all the permutations consistent with the answers so far) by at most half? I have some intuition about this but I want to see an actual explanation.
            $endgroup$
            – marianov
            May 28 at 11:52










          • $begingroup$
            There are only two possible answers, so one of them reduces the size by at most a half.
            $endgroup$
            – Yuval Filmus
            May 28 at 11:53










          • $begingroup$
            Another thing: why "After log2(n!/2) steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least log2n!=Ω(nlogn) comparisons on this branch" ?
            $endgroup$
            – marianov
            May 28 at 12:22






          • 1




            $begingroup$
            Since $n!/2^{log_2(n!/2)} = 2$. Actually I'm cheating a bit since $log_2(n!/2)$ is usually not an integer, and so you need to consider $lfloor log_2(n!/2) rfloor$ instead.
            $endgroup$
            – Yuval Filmus
            May 28 at 13:34



















          2














          $begingroup$

          The worst-case time complexity of an algorithm is the time complexity for the worst-case input. Insertion sort takes $Theta(n^2)$ in the worst-case, not $O(n)$. However, mergesort and heapsort each take $Theta(n log n)$ in the worst-case, and so achieve the $Omega(n log n)$ lower bound.



          Suppose $n!$ is roughly $1000$, so that $log n!$ is about $10$ (I know $1000$ is not the factorial of any integer, but just suppose you have a $1000$ permutations that need to be put as leaves). A nearly complete binary tree with $1000$ leaves will have a height of about $10$ (plus or minus 1). If the binary tree is not complete, then the height (or depth) will be larger. So, if some leaves in the binary tree are at small depth, then there exist other leaves in the tree which have a large depth, and in fact these leaves would have a larger depth than would have been the case if all leaves had the same depth. But even in the best case situation - where the tree is the shortest - there will exist leaves of height at least $10$, and so the height of the tree is always at least $10$. Similarly, if there are $n!$ leaves in a binary tree, there will exist some leaves having height at least $log n!$. Therefore, the height of a binary tree having $n!$ leaves is at least $log n!$. This part of your question is about the maximum number of nodes (or just leaves) that can be accommodated in a tree having some fixed height, and isn't related to sorting.



          Now to show that there can't be any permutation at depth $n-2$. We need at least $5-1=4$ comparisons to sort five elements. To understand this intuitively, observe that if $a_i$ is the $i$th element and we know $a_1 < a_2$ and $a_2 < a_3$, then there is no need to compare $a_1$ with $a_3$ and we can sort the three elements as $(a_1,a_2,a_3)$. We can deduce how $a_1$ and $a_3$ fare (relative to each other) without making another comparison because the first and third elements are being compared indirectly (via the second element). But if there were 5 elements in the array, two comparisons are not enough to make all five elements directly or indirectly related to each other. This is because a connected graph on 5 vertices must have at least $5-1=4$ edges.



          If positions 1 and 2 are compared, 2 and 3 are compared, and 4 and 5 are compared, and no further comparisons are made, then the algorithm cannot correctly sort the five elements because there is no way to determine whether the elements in ${a_1,a_2,a_3}$ are smaller than or larger than the elements in ${a_4,a_5}$ - we would only know how the elements within each subset fare relative to each other. A correct algorithm should be able to produce one of at least two different outputs, depending on whether the first subset contains large values, or whether the first subset contains all small values. Similarly, for all $n$ elements of the array to be directly or at least indirectly compared to each other, at least $n-1$ comparisons must be made.






          share|cite|improve this answer











          $endgroup$

















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "419"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });















            draft saved

            draft discarded
















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcs.stackexchange.com%2fquestions%2f109917%2fminimum-depth-of-a-leaf-in-a-tree-that-corresponds-to-a-comparison-based-sorting%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            $begingroup$

            The lower bound is for the worst-case number of comparisons. Every comparison-based sorting algorithm performs $Omega(nlog n)$ comparisons in the worst case. This means that the tree has depth $Omega(nlog n)$.



            If you don't like the tree argument, here is an adversary argument which is basically a reformulation of the tree argument. We will maintain the set $Pi$ of all permutations consistent with the answers so far. When the algorithm compares $i$ to $j$, we answer the result which reduces $Pi$ by at most a half (one of the two answers must have this property). After $log_2 (n!/2)$ steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least $log_2 n! = Omega(nlog n)$ comparisons on this branch.



            In fact, we can strengthen this result (going back to the tree argument): every comparison-based sorting algorithm makes $Omega(nlog n)$ comparisons on average (when the input is a random permutation of $1,ldots,n$). For the proof, note that there can be at most $2^k$ leaves at depth $k$. In particular, the number of leaves at depth $(log n!)/2$ is at most $sqrt{n!}$. Therefore for at least $n! - sqrt{n!}$ permutations, all leaves are at depth more than $(log n!)/2$, and for this $1-o(1)$ fraction of permutations, the algorithm will make at least $(log n!)/2 = Omega(nlog n)$ comparisons.



            Finally, let us show that you cannot possibly know the correct permutation if you perform less than $n-1$ comparisons. Construct a graph whose vertices are the elements of the array, and $(i,j)$ are connected if you compared the elements at these positions. If you make less than $n-1$ comparisons, then the graph won't be connected. In particular, you can partition the vertex set into two non-empty parts $A,B$ such that no element of $A$ was compared to any element of $B$. In particular, there is a permutation consistent with the performed comparisons in which all elements of $A$ are smaller than all elements of $B$, and another one in which all elements of $A$ are larger than all elements of $B$.






            share|cite|improve this answer









            $endgroup$















            • $begingroup$
              Can you please explain why does every comparison reduces Π (all the permutations consistent with the answers so far) by at most half? I have some intuition about this but I want to see an actual explanation.
              $endgroup$
              – marianov
              May 28 at 11:52










            • $begingroup$
              There are only two possible answers, so one of them reduces the size by at most a half.
              $endgroup$
              – Yuval Filmus
              May 28 at 11:53










            • $begingroup$
              Another thing: why "After log2(n!/2) steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least log2n!=Ω(nlogn) comparisons on this branch" ?
              $endgroup$
              – marianov
              May 28 at 12:22






            • 1




              $begingroup$
              Since $n!/2^{log_2(n!/2)} = 2$. Actually I'm cheating a bit since $log_2(n!/2)$ is usually not an integer, and so you need to consider $lfloor log_2(n!/2) rfloor$ instead.
              $endgroup$
              – Yuval Filmus
              May 28 at 13:34
















            2














            $begingroup$

            The lower bound is for the worst-case number of comparisons. Every comparison-based sorting algorithm performs $Omega(nlog n)$ comparisons in the worst case. This means that the tree has depth $Omega(nlog n)$.



            If you don't like the tree argument, here is an adversary argument which is basically a reformulation of the tree argument. We will maintain the set $Pi$ of all permutations consistent with the answers so far. When the algorithm compares $i$ to $j$, we answer the result which reduces $Pi$ by at most a half (one of the two answers must have this property). After $log_2 (n!/2)$ steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least $log_2 n! = Omega(nlog n)$ comparisons on this branch.



            In fact, we can strengthen this result (going back to the tree argument): every comparison-based sorting algorithm makes $Omega(nlog n)$ comparisons on average (when the input is a random permutation of $1,ldots,n$). For the proof, note that there can be at most $2^k$ leaves at depth $k$. In particular, the number of leaves at depth $(log n!)/2$ is at most $sqrt{n!}$. Therefore for at least $n! - sqrt{n!}$ permutations, all leaves are at depth more than $(log n!)/2$, and for this $1-o(1)$ fraction of permutations, the algorithm will make at least $(log n!)/2 = Omega(nlog n)$ comparisons.



            Finally, let us show that you cannot possibly know the correct permutation if you perform less than $n-1$ comparisons. Construct a graph whose vertices are the elements of the array, and $(i,j)$ are connected if you compared the elements at these positions. If you make less than $n-1$ comparisons, then the graph won't be connected. In particular, you can partition the vertex set into two non-empty parts $A,B$ such that no element of $A$ was compared to any element of $B$. In particular, there is a permutation consistent with the performed comparisons in which all elements of $A$ are smaller than all elements of $B$, and another one in which all elements of $A$ are larger than all elements of $B$.






            share|cite|improve this answer









            $endgroup$















            • $begingroup$
              Can you please explain why does every comparison reduces Π (all the permutations consistent with the answers so far) by at most half? I have some intuition about this but I want to see an actual explanation.
              $endgroup$
              – marianov
              May 28 at 11:52










            • $begingroup$
              There are only two possible answers, so one of them reduces the size by at most a half.
              $endgroup$
              – Yuval Filmus
              May 28 at 11:53










            • $begingroup$
              Another thing: why "After log2(n!/2) steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least log2n!=Ω(nlogn) comparisons on this branch" ?
              $endgroup$
              – marianov
              May 28 at 12:22






            • 1




              $begingroup$
              Since $n!/2^{log_2(n!/2)} = 2$. Actually I'm cheating a bit since $log_2(n!/2)$ is usually not an integer, and so you need to consider $lfloor log_2(n!/2) rfloor$ instead.
              $endgroup$
              – Yuval Filmus
              May 28 at 13:34














            2














            2










            2







            $begingroup$

            The lower bound is for the worst-case number of comparisons. Every comparison-based sorting algorithm performs $Omega(nlog n)$ comparisons in the worst case. This means that the tree has depth $Omega(nlog n)$.



            If you don't like the tree argument, here is an adversary argument which is basically a reformulation of the tree argument. We will maintain the set $Pi$ of all permutations consistent with the answers so far. When the algorithm compares $i$ to $j$, we answer the result which reduces $Pi$ by at most a half (one of the two answers must have this property). After $log_2 (n!/2)$ steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least $log_2 n! = Omega(nlog n)$ comparisons on this branch.



            In fact, we can strengthen this result (going back to the tree argument): every comparison-based sorting algorithm makes $Omega(nlog n)$ comparisons on average (when the input is a random permutation of $1,ldots,n$). For the proof, note that there can be at most $2^k$ leaves at depth $k$. In particular, the number of leaves at depth $(log n!)/2$ is at most $sqrt{n!}$. Therefore for at least $n! - sqrt{n!}$ permutations, all leaves are at depth more than $(log n!)/2$, and for this $1-o(1)$ fraction of permutations, the algorithm will make at least $(log n!)/2 = Omega(nlog n)$ comparisons.



            Finally, let us show that you cannot possibly know the correct permutation if you perform less than $n-1$ comparisons. Construct a graph whose vertices are the elements of the array, and $(i,j)$ are connected if you compared the elements at these positions. If you make less than $n-1$ comparisons, then the graph won't be connected. In particular, you can partition the vertex set into two non-empty parts $A,B$ such that no element of $A$ was compared to any element of $B$. In particular, there is a permutation consistent with the performed comparisons in which all elements of $A$ are smaller than all elements of $B$, and another one in which all elements of $A$ are larger than all elements of $B$.






            share|cite|improve this answer









            $endgroup$



            The lower bound is for the worst-case number of comparisons. Every comparison-based sorting algorithm performs $Omega(nlog n)$ comparisons in the worst case. This means that the tree has depth $Omega(nlog n)$.



            If you don't like the tree argument, here is an adversary argument which is basically a reformulation of the tree argument. We will maintain the set $Pi$ of all permutations consistent with the answers so far. When the algorithm compares $i$ to $j$, we answer the result which reduces $Pi$ by at most a half (one of the two answers must have this property). After $log_2 (n!/2)$ steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least $log_2 n! = Omega(nlog n)$ comparisons on this branch.



            In fact, we can strengthen this result (going back to the tree argument): every comparison-based sorting algorithm makes $Omega(nlog n)$ comparisons on average (when the input is a random permutation of $1,ldots,n$). For the proof, note that there can be at most $2^k$ leaves at depth $k$. In particular, the number of leaves at depth $(log n!)/2$ is at most $sqrt{n!}$. Therefore for at least $n! - sqrt{n!}$ permutations, all leaves are at depth more than $(log n!)/2$, and for this $1-o(1)$ fraction of permutations, the algorithm will make at least $(log n!)/2 = Omega(nlog n)$ comparisons.



            Finally, let us show that you cannot possibly know the correct permutation if you perform less than $n-1$ comparisons. Construct a graph whose vertices are the elements of the array, and $(i,j)$ are connected if you compared the elements at these positions. If you make less than $n-1$ comparisons, then the graph won't be connected. In particular, you can partition the vertex set into two non-empty parts $A,B$ such that no element of $A$ was compared to any element of $B$. In particular, there is a permutation consistent with the performed comparisons in which all elements of $A$ are smaller than all elements of $B$, and another one in which all elements of $A$ are larger than all elements of $B$.







            share|cite|improve this answer












            share|cite|improve this answer



            share|cite|improve this answer










            answered May 27 at 11:20









            Yuval FilmusYuval Filmus

            208k15 gold badges202 silver badges369 bronze badges




            208k15 gold badges202 silver badges369 bronze badges















            • $begingroup$
              Can you please explain why does every comparison reduces Π (all the permutations consistent with the answers so far) by at most half? I have some intuition about this but I want to see an actual explanation.
              $endgroup$
              – marianov
              May 28 at 11:52










            • $begingroup$
              There are only two possible answers, so one of them reduces the size by at most a half.
              $endgroup$
              – Yuval Filmus
              May 28 at 11:53










            • $begingroup$
              Another thing: why "After log2(n!/2) steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least log2n!=Ω(nlogn) comparisons on this branch" ?
              $endgroup$
              – marianov
              May 28 at 12:22






            • 1




              $begingroup$
              Since $n!/2^{log_2(n!/2)} = 2$. Actually I'm cheating a bit since $log_2(n!/2)$ is usually not an integer, and so you need to consider $lfloor log_2(n!/2) rfloor$ instead.
              $endgroup$
              – Yuval Filmus
              May 28 at 13:34


















            • $begingroup$
              Can you please explain why does every comparison reduces Π (all the permutations consistent with the answers so far) by at most half? I have some intuition about this but I want to see an actual explanation.
              $endgroup$
              – marianov
              May 28 at 11:52










            • $begingroup$
              There are only two possible answers, so one of them reduces the size by at most a half.
              $endgroup$
              – Yuval Filmus
              May 28 at 11:53










            • $begingroup$
              Another thing: why "After log2(n!/2) steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least log2n!=Ω(nlogn) comparisons on this branch" ?
              $endgroup$
              – marianov
              May 28 at 12:22






            • 1




              $begingroup$
              Since $n!/2^{log_2(n!/2)} = 2$. Actually I'm cheating a bit since $log_2(n!/2)$ is usually not an integer, and so you need to consider $lfloor log_2(n!/2) rfloor$ instead.
              $endgroup$
              – Yuval Filmus
              May 28 at 13:34
















            $begingroup$
            Can you please explain why does every comparison reduces Π (all the permutations consistent with the answers so far) by at most half? I have some intuition about this but I want to see an actual explanation.
            $endgroup$
            – marianov
            May 28 at 11:52




            $begingroup$
            Can you please explain why does every comparison reduces Π (all the permutations consistent with the answers so far) by at most half? I have some intuition about this but I want to see an actual explanation.
            $endgroup$
            – marianov
            May 28 at 11:52












            $begingroup$
            There are only two possible answers, so one of them reduces the size by at most a half.
            $endgroup$
            – Yuval Filmus
            May 28 at 11:53




            $begingroup$
            There are only two possible answers, so one of them reduces the size by at most a half.
            $endgroup$
            – Yuval Filmus
            May 28 at 11:53












            $begingroup$
            Another thing: why "After log2(n!/2) steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least log2n!=Ω(nlogn) comparisons on this branch" ?
            $endgroup$
            – marianov
            May 28 at 12:22




            $begingroup$
            Another thing: why "After log2(n!/2) steps there will still be at least two permutations consistent with the answers so far, hence the algorithm must make at least log2n!=Ω(nlogn) comparisons on this branch" ?
            $endgroup$
            – marianov
            May 28 at 12:22




            1




            1




            $begingroup$
            Since $n!/2^{log_2(n!/2)} = 2$. Actually I'm cheating a bit since $log_2(n!/2)$ is usually not an integer, and so you need to consider $lfloor log_2(n!/2) rfloor$ instead.
            $endgroup$
            – Yuval Filmus
            May 28 at 13:34




            $begingroup$
            Since $n!/2^{log_2(n!/2)} = 2$. Actually I'm cheating a bit since $log_2(n!/2)$ is usually not an integer, and so you need to consider $lfloor log_2(n!/2) rfloor$ instead.
            $endgroup$
            – Yuval Filmus
            May 28 at 13:34













            2














            $begingroup$

            The worst-case time complexity of an algorithm is the time complexity for the worst-case input. Insertion sort takes $Theta(n^2)$ in the worst-case, not $O(n)$. However, mergesort and heapsort each take $Theta(n log n)$ in the worst-case, and so achieve the $Omega(n log n)$ lower bound.



            Suppose $n!$ is roughly $1000$, so that $log n!$ is about $10$ (I know $1000$ is not the factorial of any integer, but just suppose you have a $1000$ permutations that need to be put as leaves). A nearly complete binary tree with $1000$ leaves will have a height of about $10$ (plus or minus 1). If the binary tree is not complete, then the height (or depth) will be larger. So, if some leaves in the binary tree are at small depth, then there exist other leaves in the tree which have a large depth, and in fact these leaves would have a larger depth than would have been the case if all leaves had the same depth. But even in the best case situation - where the tree is the shortest - there will exist leaves of height at least $10$, and so the height of the tree is always at least $10$. Similarly, if there are $n!$ leaves in a binary tree, there will exist some leaves having height at least $log n!$. Therefore, the height of a binary tree having $n!$ leaves is at least $log n!$. This part of your question is about the maximum number of nodes (or just leaves) that can be accommodated in a tree having some fixed height, and isn't related to sorting.



            Now to show that there can't be any permutation at depth $n-2$. We need at least $5-1=4$ comparisons to sort five elements. To understand this intuitively, observe that if $a_i$ is the $i$th element and we know $a_1 < a_2$ and $a_2 < a_3$, then there is no need to compare $a_1$ with $a_3$ and we can sort the three elements as $(a_1,a_2,a_3)$. We can deduce how $a_1$ and $a_3$ fare (relative to each other) without making another comparison because the first and third elements are being compared indirectly (via the second element). But if there were 5 elements in the array, two comparisons are not enough to make all five elements directly or indirectly related to each other. This is because a connected graph on 5 vertices must have at least $5-1=4$ edges.



            If positions 1 and 2 are compared, 2 and 3 are compared, and 4 and 5 are compared, and no further comparisons are made, then the algorithm cannot correctly sort the five elements because there is no way to determine whether the elements in ${a_1,a_2,a_3}$ are smaller than or larger than the elements in ${a_4,a_5}$ - we would only know how the elements within each subset fare relative to each other. A correct algorithm should be able to produce one of at least two different outputs, depending on whether the first subset contains large values, or whether the first subset contains all small values. Similarly, for all $n$ elements of the array to be directly or at least indirectly compared to each other, at least $n-1$ comparisons must be made.






            share|cite|improve this answer











            $endgroup$




















              2














              $begingroup$

              The worst-case time complexity of an algorithm is the time complexity for the worst-case input. Insertion sort takes $Theta(n^2)$ in the worst-case, not $O(n)$. However, mergesort and heapsort each take $Theta(n log n)$ in the worst-case, and so achieve the $Omega(n log n)$ lower bound.



              Suppose $n!$ is roughly $1000$, so that $log n!$ is about $10$ (I know $1000$ is not the factorial of any integer, but just suppose you have a $1000$ permutations that need to be put as leaves). A nearly complete binary tree with $1000$ leaves will have a height of about $10$ (plus or minus 1). If the binary tree is not complete, then the height (or depth) will be larger. So, if some leaves in the binary tree are at small depth, then there exist other leaves in the tree which have a large depth, and in fact these leaves would have a larger depth than would have been the case if all leaves had the same depth. But even in the best case situation - where the tree is the shortest - there will exist leaves of height at least $10$, and so the height of the tree is always at least $10$. Similarly, if there are $n!$ leaves in a binary tree, there will exist some leaves having height at least $log n!$. Therefore, the height of a binary tree having $n!$ leaves is at least $log n!$. This part of your question is about the maximum number of nodes (or just leaves) that can be accommodated in a tree having some fixed height, and isn't related to sorting.



              Now to show that there can't be any permutation at depth $n-2$. We need at least $5-1=4$ comparisons to sort five elements. To understand this intuitively, observe that if $a_i$ is the $i$th element and we know $a_1 < a_2$ and $a_2 < a_3$, then there is no need to compare $a_1$ with $a_3$ and we can sort the three elements as $(a_1,a_2,a_3)$. We can deduce how $a_1$ and $a_3$ fare (relative to each other) without making another comparison because the first and third elements are being compared indirectly (via the second element). But if there were 5 elements in the array, two comparisons are not enough to make all five elements directly or indirectly related to each other. This is because a connected graph on 5 vertices must have at least $5-1=4$ edges.



              If positions 1 and 2 are compared, 2 and 3 are compared, and 4 and 5 are compared, and no further comparisons are made, then the algorithm cannot correctly sort the five elements because there is no way to determine whether the elements in ${a_1,a_2,a_3}$ are smaller than or larger than the elements in ${a_4,a_5}$ - we would only know how the elements within each subset fare relative to each other. A correct algorithm should be able to produce one of at least two different outputs, depending on whether the first subset contains large values, or whether the first subset contains all small values. Similarly, for all $n$ elements of the array to be directly or at least indirectly compared to each other, at least $n-1$ comparisons must be made.






              share|cite|improve this answer











              $endgroup$


















                2














                2










                2







                $begingroup$

                The worst-case time complexity of an algorithm is the time complexity for the worst-case input. Insertion sort takes $Theta(n^2)$ in the worst-case, not $O(n)$. However, mergesort and heapsort each take $Theta(n log n)$ in the worst-case, and so achieve the $Omega(n log n)$ lower bound.



                Suppose $n!$ is roughly $1000$, so that $log n!$ is about $10$ (I know $1000$ is not the factorial of any integer, but just suppose you have a $1000$ permutations that need to be put as leaves). A nearly complete binary tree with $1000$ leaves will have a height of about $10$ (plus or minus 1). If the binary tree is not complete, then the height (or depth) will be larger. So, if some leaves in the binary tree are at small depth, then there exist other leaves in the tree which have a large depth, and in fact these leaves would have a larger depth than would have been the case if all leaves had the same depth. But even in the best case situation - where the tree is the shortest - there will exist leaves of height at least $10$, and so the height of the tree is always at least $10$. Similarly, if there are $n!$ leaves in a binary tree, there will exist some leaves having height at least $log n!$. Therefore, the height of a binary tree having $n!$ leaves is at least $log n!$. This part of your question is about the maximum number of nodes (or just leaves) that can be accommodated in a tree having some fixed height, and isn't related to sorting.



                Now to show that there can't be any permutation at depth $n-2$. We need at least $5-1=4$ comparisons to sort five elements. To understand this intuitively, observe that if $a_i$ is the $i$th element and we know $a_1 < a_2$ and $a_2 < a_3$, then there is no need to compare $a_1$ with $a_3$ and we can sort the three elements as $(a_1,a_2,a_3)$. We can deduce how $a_1$ and $a_3$ fare (relative to each other) without making another comparison because the first and third elements are being compared indirectly (via the second element). But if there were 5 elements in the array, two comparisons are not enough to make all five elements directly or indirectly related to each other. This is because a connected graph on 5 vertices must have at least $5-1=4$ edges.



                If positions 1 and 2 are compared, 2 and 3 are compared, and 4 and 5 are compared, and no further comparisons are made, then the algorithm cannot correctly sort the five elements because there is no way to determine whether the elements in ${a_1,a_2,a_3}$ are smaller than or larger than the elements in ${a_4,a_5}$ - we would only know how the elements within each subset fare relative to each other. A correct algorithm should be able to produce one of at least two different outputs, depending on whether the first subset contains large values, or whether the first subset contains all small values. Similarly, for all $n$ elements of the array to be directly or at least indirectly compared to each other, at least $n-1$ comparisons must be made.






                share|cite|improve this answer











                $endgroup$



                The worst-case time complexity of an algorithm is the time complexity for the worst-case input. Insertion sort takes $Theta(n^2)$ in the worst-case, not $O(n)$. However, mergesort and heapsort each take $Theta(n log n)$ in the worst-case, and so achieve the $Omega(n log n)$ lower bound.



                Suppose $n!$ is roughly $1000$, so that $log n!$ is about $10$ (I know $1000$ is not the factorial of any integer, but just suppose you have a $1000$ permutations that need to be put as leaves). A nearly complete binary tree with $1000$ leaves will have a height of about $10$ (plus or minus 1). If the binary tree is not complete, then the height (or depth) will be larger. So, if some leaves in the binary tree are at small depth, then there exist other leaves in the tree which have a large depth, and in fact these leaves would have a larger depth than would have been the case if all leaves had the same depth. But even in the best case situation - where the tree is the shortest - there will exist leaves of height at least $10$, and so the height of the tree is always at least $10$. Similarly, if there are $n!$ leaves in a binary tree, there will exist some leaves having height at least $log n!$. Therefore, the height of a binary tree having $n!$ leaves is at least $log n!$. This part of your question is about the maximum number of nodes (or just leaves) that can be accommodated in a tree having some fixed height, and isn't related to sorting.



                Now to show that there can't be any permutation at depth $n-2$. We need at least $5-1=4$ comparisons to sort five elements. To understand this intuitively, observe that if $a_i$ is the $i$th element and we know $a_1 < a_2$ and $a_2 < a_3$, then there is no need to compare $a_1$ with $a_3$ and we can sort the three elements as $(a_1,a_2,a_3)$. We can deduce how $a_1$ and $a_3$ fare (relative to each other) without making another comparison because the first and third elements are being compared indirectly (via the second element). But if there were 5 elements in the array, two comparisons are not enough to make all five elements directly or indirectly related to each other. This is because a connected graph on 5 vertices must have at least $5-1=4$ edges.



                If positions 1 and 2 are compared, 2 and 3 are compared, and 4 and 5 are compared, and no further comparisons are made, then the algorithm cannot correctly sort the five elements because there is no way to determine whether the elements in ${a_1,a_2,a_3}$ are smaller than or larger than the elements in ${a_4,a_5}$ - we would only know how the elements within each subset fare relative to each other. A correct algorithm should be able to produce one of at least two different outputs, depending on whether the first subset contains large values, or whether the first subset contains all small values. Similarly, for all $n$ elements of the array to be directly or at least indirectly compared to each other, at least $n-1$ comparisons must be made.







                share|cite|improve this answer














                share|cite|improve this answer



                share|cite|improve this answer








                edited May 27 at 16:10

























                answered May 27 at 15:27









                mo2019mo2019

                3165 bronze badges




                3165 bronze badges


































                    draft saved

                    draft discarded



















































                    Thanks for contributing an answer to Computer Science Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    Use MathJax to format equations. MathJax reference.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcs.stackexchange.com%2fquestions%2f109917%2fminimum-depth-of-a-leaf-in-a-tree-that-corresponds-to-a-comparison-based-sorting%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum

                    He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

                    Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029