アルゴリズムの時間の複雑さ：対数の底を述べることは重要ですか？

19

対数の塩基間の唯一の定数が存在するので、書き込みにだけ申し分ない $f(n) = \Omega(\log{n})$ とは対照的に、 $\Omega(\log_2{n})$ 、または任意の塩基があるかもしれませんか？

algorithms time-complexity

— アレックス5207
ソース

1

関連/重複：バイナリ検索のbig-Oのログがベース2ではないのはなぜですか？

— ダケリング

63

対数がどこにあるかによります。それが単なる係数である場合、大きなOまたは $\theta$ 使用すると定数を乗算できるため、違いはありません。

あなたが取る場合は $O(2^{\log n})$ その後、ベースが重要です。基数2には $O(n)$ だけがあり、基数10には約 $O(n^{0.3010})$ ます。

— gnasher729
ソース

5

私はこれが唯一のような何かを思い付くために起こっていると思います

。数値を

-to-the-what-it-is-isではなく

として表現する理由はわかりません（おそらく計算の中間段階として）。

2^{\sqrt{\log n}}

$2^{\sqrt{\log n}}$

2^{c \log_{b} n}

$2^{c\log_b n}$

n

$n$

— デビッドリチャービー

7

「定数では定数が重要」の+1

— トログナンダー

50

漸近的な表記は定数因子の忘れであり、任意の2つの対数は、一定の係数によって異なるので、ベースは違いはありません： $\log_a n = \Theta(\log_b n)$ すべてについて。そのため、漸近表記を使用する場合、対数の底を指定する必要はありません。 $a,b > 1$

— ユヴァル・フィルマス
ソース

13

代わりに

を見るのが好きです

\in

$\in$

=

$=$

— Nayuki

16

標準表記では

使用しているのではないかと心配しています。

=

$=$

— ユヴァルフィルマス

4

@YuvalFilmus標準表記は誤解を招くものであり、他のすべての標準とはまったく異なり、アルゴリズムの複雑さをそれに非常に類似したものから完全に異質に思わせます。「標準表記法」は、より良く、同様に明確なソリューションよりも悪いソリューションを支持する理由になることはありません。（とにかく、シンボルの意味は通常コンテキストから明確です。）

— wizzwizz4

7

@ wizzwizz4一般的な慣行が優れた理由です。効率的なコミュニケーションを促進します。それが私たち全員が英語のスペルの癖に我慢している理由です。

— ユヴァルフィルマス

3

時には、

ちょうどより明確そこにあまりにも多くのものがある

。

n \mapsto \log_{a} n \in Θ (n \mapsto \log_{b} n)

$n \mapsto \log_a n \in \Theta ( n \mapsto \log_b n)$

\log_{a} n = Θ (\log_{b} n)

$\log_a n = \Theta (\log_b n)$

— JiK

15

$\log_xy = \frac{1}{\log_y{x}}$ and $\log_x{y} = \frac{\log_z{y}}{\log_z{x}}$ , so $\frac{\log_a{n}}{\log_b{n}} = \frac{\log_n{b}}{\log_n{a}} = \log_a{b}$ . As $\log_a{b}$ is positive constant (for all $a,b > 1$ ), so $\log_a{n} = \Theta(\log_b{n})$ .

— OmG
ソース

8

In most cases, it's safe to drop the base of the logarithm because, as other answers have pointed out, the change-of-basis formula for logarithms means that all logarithms are constant multiples of one another.

There are some cases where this isn't safe to do. For example, @gnasher729 has pointed out that if you have a logarithm in an exponent, then the logarithmic base is indeed significant.

I wanted to point out another case where the base of the logarithm is significant, and that's cases where the base of the logarithm depends directly on a parameter specified as input to the problem. For example, the radix sort algorithm works by writing out numbers in some base $b$ , decomposing the input numbers into their base- $b$ digits, then using counting sort to sort those numbers one digit at a time. The work done per round is then $\Theta(n + b)$ and there are roughly $\log_b U$ rounds (where $U$ is the maximum input integer), so the total runtime is $O((n + b) \log_b U)$ . For any fixed integer $b$ this simplifies to $O(n \log U)$ . However, what happens if $b$ isn't a constant? A clever technique is to pick $b = n$ , in which case the runtime simplifies to $O(n + \log_n U)$ . Since $\log_n U$ = $\frac{\log U}{\log n}$ , the overall expression simplifies to $O(\frac{n \log U}{\log n})$ . Notice that, in this case, the base of the logarithm is indeed significant because it isn't a constant with respect to the input size. There are other algorithms that have similar runtimes (an old analysis of disjoint-set forests ended up with a term of $\log_{m/2 + 2}$ somewhere, for example), in which case dropping the log base would interfere with the runtime analysis.

Another case in which the log base matters is one in which there's some externally-tunable parameter to the algorithm that control the logarithmic base. A great example of this is the B-tree, which requires some external parameter $b$ . The height of a B-tree of order $b$ is $\Theta(\log_b n)$ , where the base of the logarithm is significant in that $b$ is not a constant.

To summarize, in the case where you have a logarithm with a constant base, you can usually (subject to exceptions like what @gnasher729 has pointed out) drop the base of the logarithm. But when the base of the logarithm depends on some parameter to the algorithm, it's usually not safe to do so.

— templatetypedef
ソース