Big-O表示法和循環遞歸

Question

以下方法中最壞情況的Big-O表示法是什么：

 /**
 * @best-case  O(1)
 * @worst-case O(?)
 *
 * {@link NTree#contains(Comparable)}
 */
public boolean contains(T elem) {

    if (this.data.compareTo(elem) == 0)
        return true;

    for(NTree<T> t : children) {
        if(t != null)
            return t.contains(elem);    
    }


    return false; 
}

這是n元的通用樹，每棵樹都有n個孩子。 最佳情況是當elem等於root.data 。

但是我不確定在最壞的情況下我們必須經歷樹上的每個孩子。

Answer 1

在最后引用您：

...最壞的情況下，我們必須穿過樹上的每個孩子 。

如果在最壞的情況下經歷每個孩子，那將是O(n) ，其中n是樹中的節點數。

您可以這樣考慮：如果這是一個簡單的鏈表，並且您必須在最壞的情況下完全搜索它，那么最壞情況下的復雜度是什么？ 這里是一樣的。 只是在這種情況下，每個節點可以有多個子節點。

遞歸在改變復雜性方面實際上並不起作用。 這只是循環的手段。 如果您使用標准循環結構進行迭代搜索，那將是相同的。

Answer 2

如果n元樹沒有結構（子項/節點的鍵沒有基於比較的排序），則最壞的情況是O（N）。

如果n元樹不一定是平衡的（意味着在最壞的情況下每個節點可以有一個孩子），那么最壞的情況也將是O（N）。

如果樹是平衡排序的n元樹O（log ₂ （n）log _n （N））其中：

• N =樹中的＃個節點
• n =每個節點中的子節點數

說明：

在n個孩子中進行二元搜索將在樹的整個深度取O（log ₂ （n）），這在平衡n元樹中最大為O（log _n （N））。

Answer 3

在最壞的情況下，您將始終必須遍歷所有元素。 您可以想象在現實世界的應用程序中，當N元樹用作文件系統的數據結構時。 每個節點都是文件（目錄或常規文件），並且您想通過樹的右下角的名稱查找文件，因此如果不檢查所有節點就無法存儲所有其他信息以指導您，這是不可行的更快地歸檔（例如，這是Linux下按名稱搜索文件時的find命令）。