O (N log N) Складність - схожа на лінійну?

Тож я думаю, що мене поховають за таке тривіальне запитання, але я дещо в чомусь розгублений.

Я застосував швидке сортування на Java та C, і я робив деякі базові порівняння. Графік вийшов у вигляді двох прямих ліній, причому C був на 4 мс швидшим, ніж аналог Java, понад 100 000 випадкових цілих чисел.

Код моїх тестів можна знайти тут;

Android-тести

Я не був впевнений, як буде виглядати рядок (n log n), але не думав, що це буде прямо. Я просто хотів перевірити, чи це очікуваний результат, і що я не повинен намагатися знайти помилку в коді.

Я встромив формулу в Excel і для бази 10, здається, це пряма лінія з перегином на початку. Це тому, що різниця між log (n) та log (n + 1) збільшується лінійно?

Дякую,

Гав

Зробіть графік більшим, і ви побачите, що O (n logn) - не зовсім пряма лінія. Але так, це досить близько до лінійної поведінки. Щоб зрозуміти чому, просто візьміть логарифм кількох дуже великих чисел.

Наприклад (база 10):

log(1000000) = 6
log(1000000000) = 9
…

Отже, для сортування 1 000 000 чисел сортування O (n logn) додає мізерний коефіцієнт 6 (або лише трохи більше, оскільки більшість алгоритмів сортування залежать від логарифмів основи 2). Не дуже багато.

Насправді цей часовий коефіцієнт настільки надзвичайно малий, що для більшості порядків встановлені алгоритми O (n logn) перевершують алгоритми лінійного часу. Яскравим прикладом є створення структури даних суфіксних масивів.

Нещодавно мене покусав простий випадок, коли я намагався поліпшити швидке сортування коротких рядків, використовуючи сортування radix . Виявляється, для коротких рядків це (лінійний час) сортування за радіусом було швидшим, ніж швидке сортування, але для все ще відносно коротких рядків існував переломний момент, оскільки сортування за допомогою радіуса вирішальним чином залежить від довжини рядків, які ви сортуєте.

FYI, швидкий сорт насправді O (n ^ 2), але із середнім випадком O (nlogn)

FYI, існує досить велика різниця між O (n) та O (nlogn). Ось чому він не обмежений O (n) для будь-якої константи.

Для графічної демонстрації див .:

Для ще більшого задоволення в подібному ключі спробуйте побудувати графік часу, зайнятого n операціями, на стандартній структурі даних неперервного набору . Було показано, що асимптотично n  α ( n ), де α ( n ) є оберненою до функції Аккермана (хоча ваш звичайний підручник з алгоритмів, ймовірно, буде відображати лише межу з n log log n або, можливо, n  log *  n ). Для будь-якого числа, яке, швидше за все, ви зустрінете як вхідний розмір, α ( n ) ≤ 5 (і насправді log *  n  ≤ 5), хоча воно і наближається до нескінченності асимптотично.

Я вважаю, що з цього ви можете навчитися, хоча асимптотична складність є дуже корисним інструментом для роздумів про алгоритми, це не зовсім те саме, що практична ефективність.

1. Зазвичай алгоритми O (n * log (n)) мають 2-базисну логарифмічну реалізацію.
2. Для n = 1024, log (1024) = 10, отже n * log (n) = 1024 * 10 = 10240 обчислення, збільшення на порядок.

Отже, O (n * log (n)) подібний до лінійного лише для невеликого обсягу даних.

Порада: не забувайте, що швидка сортування поводиться дуже добре на випадкові дані і що це не алгоритм O (n * log (n)).

Будь-які дані можна нанести на лінію, якщо вісь обрано правильно :-)

У Вікіпедії сказано, що Big-O - це найгірший випадок (тобто f (x) - O (N) означає, що f (x) "обмежена зверху" знаком N) https://en.wikipedia.org/wiki/Big_O_notation

Ось гарний набір графіків, що відображають відмінності між різними загальними функціями: http://science.slc.edu/~jmarshall/courses/2002/spring/cs50/BigO/

Похідна log (x) дорівнює 1 / x. Ось так швидко збільшується журнал (x) із збільшенням x. Він не є лінійним, хоча може виглядати як пряма, тому що так повільно згинається. Думаючи про O (log (n)), я думаю про це як O (N ^ 0 +), тобто найменша потужність N, яка не є константою, оскільки будь-яка позитивна постійна потужність N з часом її наздожене. Це не на 100% точно, тому професори будуть злитися на вас, якщо ви пояснюєте це так.

Різниця між журналами двох різних баз є постійним множником. Шукайте формулу для перетворення журналів між двома базами: (у розділі "зміна бази" тут: https://en.wikipedia.org/wiki/Logarithm ) Фокус полягає в тому, щоб розглядати k та b як константи.

На практиці, як правило, в будь-яких даних, які ви складаєте, виникає деяка гикавка. Будуть розбіжності в речах поза вашою програмою (щось, що міняється на процесорі перед вашою програмою, пропуски кешу тощо). Щоб отримати надійні дані, потрібно багато прогонів. Константи є найбільшим ворогом спроби застосувати позначення Big O до фактичного часу виконання. Алгоритм O (N) з високою константою може бути повільнішим, ніж алгоритм O (N ^ 2) для досить малого N.

log (N) - це (дуже) приблизно кількість цифр у N. Отже, здебільшого між log (n) та log (n + 1) є невелика різниця

Спробуйте побудувати фактичну лінійну лінію поверх неї, і ви побачите невелике збільшення. Зверніть увагу, що значення Y на 50,0000 менше, ніж значення 1/2 Y на 100000.

Воно є, але воно невелике. Ось чому O (nlog (n)) так хороший!