Чому std :: list :: reverse має складність O (n)?

Чому функція звороту для std::listкласу в стандартній бібліотеці C ++ має лінійне виконання? Я думаю, що для подвійно пов'язаних списків зворотна функція повинна була бути O (1).

Повернення подвійно пов'язаного списку повинно включати перемикання вказівників голови та хвоста.

Гіпотетично reverseмогло бути O (1) . Там (знову гіпотетично) міг бути логічний член списку, який вказує, чи напрямок пов'язаного списку в даний час такий же або протилежний початковому, де цей список створений.

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

Оскільки це, ймовірно, вважалося відносно нечастою операцією, стандарт (який не диктує реалізації, а лише складність), визначав, що складність може бути лінійною. Це дозволяє «наступним» покажчикам завжди однозначно означати той самий напрямок, прискорюючи загальновиробничі операції.

Це може бути O (1), якщо в списку буде зберігатися прапор, який дозволяє міняти значення покажчиків " prev" та " next", які має кожен вузол. Якщо повернення списку буде частою операцією, таке доповнення може бути насправді корисним, і я не знаю жодної причини, чому його застосування було б заборонено чинним стандартом. Однак наявність такого прапора зробить звичайне прокручування списку дорожче (якщо тільки постійним фактором), тому що замість цього

current = current->next;

в operator++ітераторі списку ви отримаєте

if (reversed)
  current = current->prev;
else
  current = current->next;

що ви не вирішили легко додати. Зважаючи на те, що списки, як правило, проходять набагато частіше, ніж вони перевертаються, було б дуже нерозумно, щоб стандарт надавав цю методику. Тому зворотній операції дозволяється мати лінійну складність. Зауважте, однак, що t ∈ O (1) ⇒ t ∈ O ( n ), тому, як було сказано раніше, технічна реалізація вашої "оптимізації" буде дозволена.

Якщо ви родом з Java або подібного фону, вам може бути цікаво, чому ітератор повинен перевіряти прапор кожен раз. Чи не могли б ми замість цього мати два різних ітераторних типи, обидва похідні від загального базового типу, і мати std::list::beginі std::list::rbeginполіморфно повернути відповідний ітератор? Хоча це можливо, це зробить все ще гірше, тому що просування ітератора було б непрямим (важко вбудованим) викликом функції. У Java ви все одно платите за цю ціну регулярно, але знову ж таки, це одна з причин, коли багато людей досягають C ++, коли продуктивність критична.

Як вказував у коментарях Бенджамін Ліндлі , оскільки reverseітераторів не можна визнати недійсними, єдиним підходом, дозволеним стандартом, є збереження вказівника назад до списку всередині ітератора, що викликає подвійний непрямий доступ до пам'яті.

Звичайно, оскільки всі контейнери, які підтримують двонаправлені ітератори, мають поняття rbegin () та rend (), це питання суперечить?

Тривіально створити проксі-сервер, який перевертає ітератори та отримує доступ до контейнера через нього.

Ця робота не є дійсно O (1).

як от:

#include <iostream>
#include <list>
#include <string>
#include <iterator>

template<class Container>
struct reverse_proxy
{
    reverse_proxy(Container& c)
    : _c(c)
    {}

    auto begin() { return std::make_reverse_iterator(std::end(_c)); }
    auto end() { return std::make_reverse_iterator(std::begin(_c)); }

    auto begin() const { return std::make_reverse_iterator(std::end(_c)); }
    auto end() const { return std::make_reverse_iterator(std::begin(_c)); }

    Container& _c;
};

template<class Container>
auto reversed(Container& c)
{
    return reverse_proxy<Container>(c);
}

int main()
{
    using namespace std;
    list<string> l { "the", "cat", "sat", "on", "the", "mat" };

    auto r = reversed(l);
    copy(begin(r), end(r), ostream_iterator<string>(cout, "\n"));

    return 0;
}

очікуваний вихід:

mat
the
on
sat
cat
the

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

Просто мій 2с.

Тому що він повинен пройти кожен вузол ( nусього) та оновити їх дані (дійсно є крок оновлення O(1)). Це робить всю операцію O(n*1) = O(n).

Він також підміняє попередній та наступний вказівники для кожного вузла. Ось чому це потрібно лінійним. Хоча це може бути зроблено в O (1), якщо функція, що використовує цю LL, також приймає інформацію про LL в якості вхідного сигналу, як, наприклад, чи він звертається нормально або зворотно.

Тільки пояснення алгоритму. Уявіть, у вас є масив з елементами, тоді вам потрібно його перевернути. Основна ідея полягає в перегляді кожного елемента, змінюючи елемент на першому положенні на останнє, елемент на другому положенні на передостаннє положення тощо. Коли ви досягнете середини масиву, ви зміните всі елементи, таким чином, в (n / 2) ітераціях, що вважається O (n).

Це O (n) просто тому, що йому потрібно скопіювати список у зворотному порядку. Кожна окрема операція з пунктом - O (1), але їх у всьому списку є n.

Звичайно, існують деякі операції постійного часу, що займаються налаштуванням місця для нового списку, а потім зміною покажчиків тощо. Позначення O не враховує окремих констант, коли ви включаєте n-коефіцієнт першого порядку.