Чи є проблеми, які стають легшими, оскільки вони збільшуються в розмірах?

62

Це може бути смішним питанням, але чи можлива проблема, яка насправді стає простішою, оскільки вхід збільшується в розмірах? Я сумніваюся, що будь-які практичні проблеми подібні, але, можливо, ми можемо вигадати вироджену проблему, яка має цю властивість. Наприклад, можливо, воно починає «вирішувати себе», коли воно стає більшим, або поводиться якось іншим химерним чином.

algorithms asymptotics

— dsaxton
джерело

7

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

— амон

1

@amon Час роботи не масштабується як . Потрібно час просто для того, щоб прочитати хешів, які вам дали як вхідні дані!

1 / n

$1/n$

n

$n$

n

$n$

— Девід Річербі

3

Ви маєте на увазі простіше в абсолютних чи відносних показниках? Які заходи витрат ви дозволяєте? Вам потрібні суворо зменшуються витрати або недостатньо (з певного моменту) збільшення?

— Рафаель

2

@DavidRicherby У цьому прикладі правомірно ігнорувати витрати на зчитування вводу до тих пір, поки я не буду робити жодної заяви про абсолютну вартість. Натомість швидкість збільшується лінійно із входом. Тому n • T (1)> T (n) навіть при розгляді вартості читання введення. Тобто для цієї проблеми простіше вирішити великий вхід одразу, а не розділити вхід, навіть якщо проблема не ділиться. Я не кажу, що T (n)> T (n + 1) для всіх n.

— Амон

4

Для всіх, хто хоче опублікувати ще одну відповідь форми: "Деяка проблема, коли вхід - це питання плюс великий натяк на відповідь": Це не працює. Найскладнішими введеннями довжини є ті, де ви використовуєте всі бітів, щоб задати питання і не давати жодних підказок. Те, що легко вирішувати короткі запитання з великою кількістю підказок, не означає, що найгірший час роботи є хорошим.

n

$n$

n

$n$

— Девід Річербі

39

Ні, це неможливо: принаймні, не в асимптотичному сенсі, де вам потрібна проблема, щоб продовжувати ставати суворо простіше, назавжди, як . $n \to \infty$

Нехай - найкращий можливий час для вирішення такої задачі, де - розмір вводу. Зауважте, що час запуску - це кількість кількості інструкцій, виконаних алгоритмом, тому це повинно бути невід'ємним цілим числом. Іншими словами, для всіх . Тепер, якщо ми розглянемо функцію , ми бачимо, що немає такої функції, яка суворо монотонно зменшується. (Яким би не був , він повинен бути кінцевим, скажімо, ; але, оскільки монотонно суворо зменшується, і $T(n)$ $n$ $T(n) \in \mathbb{N}$ $n$ $T: \mathbb{N} \to \mathbb{N}$ $T(0)$ $T(0)=c$ $T$ $T(c) \le 0$ $T(c+1) \le -1$ , що неможливо.) З подібних причин немає функції, яка асимптотично суворо зменшується: ми можемо аналогічно довести, що функція часу де існує не існує такої, що для всіх , монотонно суворо зменшується (будь-яка така функція повинна з часом стати негативною). $T(n)$ $n_0$ $n \ge n_0$ $T(n)$

Отже, така проблема не може існувати з тієї простої причини, що час роботи повинен бути невід'ємними цілими числами.

Зауважте, що ця відповідь охоплює лише детерміновані алгоритми (тобто, найгірший час виконання). Це не виключає можливості рандомізованих алгоритмів, очікуваний час роботи яких суворо монотонно скорочується назавжди. Я не знаю, чи можливо такий алгоритм існувати. Я дякую Бені Чернявській-Паскіну за це спостереження .

— DW
джерело

9

Це приємний доказ, але я не згоден з цим припущенням. Замість того, щоб просити строго монотонно зменшується час виконання, питання може бути більш обґрунтованим вимагати функції, де існує a, b з a <b, так що T (a)> T (b), тобто його не суворо монотонно зменшується. Тоді, звичайно, можна знайти відповідні цілі функції. Але чому цілі числа? У мене склалося враження, що час запуску позначає час, а не кількість інструкцій (за винятком, звичайно, машин Тьюрінга), і що вираз T може використовувати не цілі операції, такі як log () або не цілі показники.

— амон

2

@amon "час роботи позначав час, а не кількість інструкцій" Абсолютно ні. Час роботи - це завжди кількість інструкцій. Будь-що інше було б неможливо міркувати, оскільки це залежатиме від незрівнянно багатьох деталей реалізації.

— Девід Річербі

3

Як неясне питання, я не бачу, як вона виключає функцію витрат, скажімо, . Тепер але для "малих" , тому проблема "стає легшою", відносно кажучи. (Звичайно, абсолютні витрати зростають асимптотично).

T (n) = n^{2} \cdot (1 + ϵ)^{- n} + n

$T(n) = n^2 \cdot (1+\epsilon)^{-n} + n$

T (n) \sim n

$T(n) \sim n$

T (n) \approx n^{2}

$T(n) \approx n^2$

n

$n$

— Рафаель

2

@Raphael, не стає проблемою легше: збільшується, коли стає більше, тому проблема стає важче, коли стає більше, як тільки стає достатньо великим. У першому реченні я відповів, що жодна проблема не може продовжувати простіше назавжди. Звичайно, проблема може полегшитись на деякий час ( може зменшуватися для , скажімо), але це не може продовжуватись легше назавжди.

T (n) \sim n

$T(n) \sim n$

T (n)

$T(n)$

n

$n$

n

$n$

n

$n$

T (n)

$T(n)$

n \leq c

$n \le c$

— DW

1

Навіть з цілими часами, для рандомізованого алгоритму очікуваний час (або будь-який інший показник розподілу) може бути дробовим і може поступово наближатися до деякої константи зверху. [Це не означає, що такі проблеми насправді існують, лише те, що аргумент "немає такої функції існує" недостатній.]

T

$T$

— Бені Чернявський-Паскін

25

Хоча це не зовсім відповідь на ваше запитання, алгоритм пошуку рядків Boyer-Moore наближається. Як говорить Роберт Мур на своїй веб-сторінці про алгоритм,

Наш алгоритм має властивість, що, грубо кажучи, чим довший шаблон, тим швидше йде алгоритм.

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

— Рік Декер
джерело

10

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

— Кевін

4

@Kevin У заяві випливає, що пошук шаблону довжини у тексті довжиною швидше, ніж пошук шаблону довжини . Дивлячись на такі входи з фіксованим відношенням (тобто пари рядків), я думаю, що Рік дав відповідну відповідь на питання (якщо не в класичному, асимптотичному сенсі).

\sqrt{n}

$\sqrt{n}$

n

$n$

\log n

$\log n$

— Рафаель

10

Зрозуміло, що з точки зору чистого математичного, чисто CS алгоритму це неможливо. Але насправді є декілька реальних прикладів, коли масштабування вашого проекту полегшує, багато з яких не є інтуїтивно зрозумілими для кінцевих споживачів.

Вказівки : чим довше ваші вказівки, тим часом вони можуть бути простішими. Наприклад, якщо я хочу, щоб Карти Google давали мені вказівки проїхати на захід 3000 миль, я міг би доїхати до Західного узбережжя - і отримаю інструкції з проїзду за межею. Але якби я хотів пройти 6000 миль на захід, я б закінчив значно простіші інструкції: сісти на літак з Нью-Йорка до Хоккайдо. Надання мені маршруту, який включає трафік, дороги, погоду тощо, досить складно алгоритмічно, але сказати мені сісти в літак і шукати рейси в базі даних порівняно значно простіше. ASCII графік складності проти відстані:

           |     /
           |    /
Difficulty |   /                  ____-------
           |  /           ____----
           | /    ____----
            ---------------------------------
                       Distance

Візуалізація : скажіть, що я хочу візуалізації одного обличчя та візуалізації 1000 облич; це для рекламного щита, тому обидва кінцеві зображення повинні бути 10000px на 5000px. Реалізувати одне обличчя реально було б важко - при роздільній здатності декількох тисяч пікселів поперек потрібно використовувати дійсно потужні машини - але для натовпу в 1000 облич кожному обличчю потрібно всього десять пікселів, і їх можна легко клонувати! Я, мабуть, міг би відтворити 1000 облич на своєму ноутбуці, але для надання реалістичного обличчя 10000 пікселів поперек знадобиться дуже багато часу та потужні машини. Графік складності ASCII порівняно з наданими об’єктами, показує, як складність надання n об’єктів зображенню заданого розміру швидко відпадає, але потім повертається повільно:

           | -    
           |- -                     _________
Difficulty |   --      ______-------            
           |     ------      
           |       
            ---------------------------------
                        Objects

Контроль обладнання : багато речей із обладнанням набагато простіше. "Перемістити мотор X 1 ступінь" важко і / або неможливо, і вам доведеться мати справу з усіма видами справ, з якими вам не доведеться мати справу для "переміщення мотора X 322 градуси".

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

— Оуен Верстег
джерело

У прикладі "вказівки", будь ласка, вкажіть, що саме є обчислювальною проблемою та що таке екземпляр. Мені зовсім не зрозуміло, що ваш приклад на відстані 6 кілометрів - це більший екземпляр або просто приклад легкої частини чогось (наприклад, якщо я даю вам великий графік, пов'язаний з графіком плюс одна ізольована вершина, взагалі просять найкоротші шляхи) "складний", але просити найкоротший шлях від ізольованої вершини до будь-якого місця є тривіальним). Знову ж таки, для вашого прикладу візуалізації, яка власне обчислювальна проблема? Який екземпляр, щодо якого ви вимірюєте складність?

— Девід Річербі

Приклад візуалізації, схоже, не є однією і тією ж проблемою: перший - візуалізація одного зображення; другий - рендеринг багатьох невеликих зображень, а потім вклеювання декількох копій цих зображень у якусь область.

— Девід Річербі

Я думаю, що wrt для пересування параметрів буде назвою двох міст, а n - число символів для їх кодування.

— Еморі

3

Є випадки. Це випадки, коли критерії успіху є функцією даних, а не намагаються знайти єдину відповідь. Наприклад, статистичні процеси, результати яких формулюються з довірчими інтервалами, можуть стати простішими.

Один конкретний випадок, про який я думаю, - це проблеми, які мають перехід від дискретної поведінки до постійної поведінки, як потоки рідини. Вирішення невеликої проблеми в межах ступеня помилки може включати моделювання всіх дискретних взаємодій, що може вимагати створення суперкомп'ютера. Безперервне поведінка часто дозволяє спростити, не даючи результатів за межами пов'язаної помилки.

— Корт Аммон
джерело

2

Питання цікаве та КОРИСНЕ, адже наша філософія в галузі інформатики полягає у вирішенні завдань, чим більше ми читаємо, тим складніше. Але насправді МОСТ проблем, які подаються типово (важко), можна легко представити «легким» способом; навіть знаючи реакцію DW (що помиляється, вважаючи, що легке не означає швидше, означає «менш повільний»; тому вам не доведеться знаходити негативні часи, вам потрібно знайти асимптотичний час).

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

Приклад: Який автомобіль між Лондоном і Парижем є найдовшим уникнути відвідування французького та британського містечок та не відвідувати іншу країну? Подумайте, вам доведеться їхати в Бірмінгем перед Ешфордом, Орлеан перед Версалем, Ла-Рошель перед Лімож та ін.

Зрозуміло, що ця проблема з довгими записами буде легшою, ніж з короткою.

Приклад використання: Уявіть собі ігрову гру, якою керує машина, і ІА комп’ютера повинна визначити, чи потрібно йому більше досліджувати в грі, щоб знайти більше підказок чи ще, якщо зараз настав час зробити висновок про те, що найкраще прийняти рішення .

— Хуан Мануель Дато
джерело

2

Ваш приклад не працює. Екземпляри великі, оскільки вони мають стільки натяків, що підказки визначають лінійний порядок вершин графа насправді прості. Однак великі випадки, оскільки вони дають великий графік з майже ніякими підказками, такі ж важкі, як і звичайна проблема гамільтонівського шляху. Таким чином, найгірший час роботи будь-якого алгоритму, який вирішує цю проблему, буде принаймні таким же поганим, як і найгірший час виконання найкращого алгоритму для Гамільтонового шляху, який, здається, не є надто простим.

— Девід Річербі

@David, ваша відповідь абсолютно невірна: 1. Запис не є графіком: великий графік є ПАРАМЕТРОМ. Тож гамільтонова проблема перетворюється на постійну (дуже велику, але постійну). 2. Запис є вирішенням проблеми, тому: якщо більше, ви пропонуєте комбінаторний вибух натяків. Запис однієї підказки дає допомогу, два натякає на подвійний, три підказки будуть близькими до 4-х подвійних ..., тому що ви усуваєте можливі рішення. Отже, це не був гамільтоніаном, це рішення із специфічного графіка, а проблема - ЩО робити з частинами рішень.

— Хуан Мануель Дато

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

— Том ван дер Занден

@Том я погоджуюся, що ваш розгляд щодо складності буде постійним, але проблема полягає в тому, як ми приймаємо нові підказки: якщо з нашою філософією обчислення довгого запису не кращою, ніж короткий запис, ми повинні змінити свою філософію - тому що це факт: довгі записи передбачають простіші проблеми. Тож ми не можемо працювати так ... Я рекомендував би свою книгу, але у мене немає репутації ...

— Juan Manuel Dato

n \log n

$n\log n$

1

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

Немає вводу-> Брутальна сила розбивається над усіма символами та словом будь-якої довжини
Довжина пароля -> Брут примусити всі символи в слові такої довжини
Містяться символи -> Зменшує список символів для перевірки
...
Містяться символи, включаючи кілька випадків і довжину -> Тільки обчислюють перестановки
Усі символи в правильному порядку -> в основному вирішили самі

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

Отже, все зводиться до того, скільки абстрагування ви дозволяєте.

— RunOrVeith
джерело

2

b

$b$

0

Власне кажучи, у мене виникає проблема, яка зменшується в міру збільшення даних. Одна з моїх заявок записує атрибути певного продукту, скажімо, сир. Атрибути, наприклад, CheeseType, бренд, країна, область, MilkType тощо. Щомісяця або близько того, я отримую список нових сирів, які надійшли на ринок за цей час, разом з їх атрибутами. Тепер ці атрибути вводяться вручну групою людей. Деякі роблять помилки або просто не знають значення для всіх атрибутів.

Коли ви здійснюєте пошук у моїй базі даних, я намагаюся передбачити зі статистичних даних, який буде смак сиру, виходячи з цих ознак. Що трапляється, це те, що для кожного атрибуту я закінчую діапазон значень; деякі дійсні, деякі недійсні. Усунення або виправлення цих недійсних можливе лише за наявності у мене достатньої кількості даних. Йдеться про різницю між реальними значеннями та шумом, не усуваючи рідкісних, але дійсних значень.

Як ви можете уявити, при низькій гучності шум надто важливий, щоб правильно виправити речі. Якщо у вас є 5 екземплярів Чеддара, 1 Брі, 1 Брі та 1 Кедера, як я можу сказати, що правильно, а що друкарське помилки? З більшою гучністю друкарські помилки зберігаються дуже низько, але рідкісні значення набувають декількох вирішальних кроків, завдяки чому вони рятуються від шуму (підкріпленого досвідом). У цьому випадку я міг би уявити, наприклад, 50000 Cheddar, 3000 Brie, 5 Bri, 15 Cedar.

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

— Крис
джерело

1

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

— Девід Річербі

Це проблема в реальному житті (у мене вона була вже двічі), яку неможливо вирішити з низькою кількістю даних. Це може, і навіть стає простіше розрізнити добрі значення від неправильних, оскільки обсяг стає більшим. Заслуговує на відповідь на запитання "Чи є якісь проблеми, які стають легшими, оскільки вони збільшуються в розмірах?" Не має значення, скільки видів сирів вийде, зрештою, при достатньому обсязі вони матимуть більше "хітів", ніж друкарські помилки. Це cs .stackexchange, а не математика, тому проблеми різні, і їх вирішення іноді просто полягає у більшій впевненості в результатах.

— chris

Чи це також не є передумовою номерів телешоу ? Або принаймні деякі епізоди - я знаю, я спеціально пригадую одну сцену, де хлопець з математики зазначає, що алгоритм, який він використовує для вирішення проблеми, стає більш ефективним при збільшенні набору даних.

— Ден Хендерсон

2

"Стає більш ефективним"! = "Стає легше".

— Девід Річербі

-1

Розглянемо NP-повну проблему 3-SAT. Якщо ви продовжуєте нарощувати проблему, надаючи входи форми x_i = true / false, ви або в кінцевому підсумку конвертуєте окремі диз'юнкції у двозмінні пропозиції, створюючи тим самим 2-SAT проблему, яка, безумовно, P, або ви просто в кінцевому підсумку отримуєте правдива / хибна відповідь.

У випадку, коли є надмірність вхідних даних x_i = true / false (той самий вхід надається багато разів, або суперечливі входи), ви можете легко сортувати входи і або ігнорувати надлишкові значення, або повідомити про помилку, якщо значення суперечать.

У будь-якому випадку, я думаю, що це являє собою "реалістичну" проблему, яку стає легше вирішити, коли кількість входів зростає. «Простіший» аспект полягає в перетворенні задачі, що завершує NP, в проблему P. Ви все ще можете грати в систему, надаючи смішні вводи, такі, що просто сортування зайняло б більше часу, ніж груба змушена проблема.

Тепер справді класним сценарієм було б, якщо ми готові прийняти T (0) (використовуючи позначення DW у відповіді вище), може бути нескінченним. Наприклад, T (0) може бути еквівалентним вирішенню задачі Тьюрінга на зупинку. Якщо ми могли б розробити таку проблему, що додавання більшої кількості входів перетворює її на вирішувану проблему, ми натрапили на золото. Зауважте, що недостатньо перетворити її на вирішувану проблему асимптотично - адже це так само погано, як і груба примушування проблеми.

— v vv cvvcv
джерело

1

Ці конкретні входи стають простішими. Однак, якщо врахувати всі можливі входи, 3SAT взагалі стає значно складніше, оскільки ви додаєте більше пропозицій: жорсткі входи - це ті, які не мають цих підказок. Якщо ви забороняєте загальні введення, вам потрібно вказати, які саме матеріали ви дозволяєте.

— Девід Річербі

По-перше: ми згодні з тим, що додавання більшої кількості вхідних даних може збільшити час роботи. Я кажу по суті те саме, що вище. По-друге, я чітко кажу, що ми приймаємо існуючий 3-SAT і додаємо лише входи форми x_i = true / false. Я думаю, що це досить зрозуміло, і мені не потрібно робити ніяких уточнень. Думаю, ти відчуваєш неприємності, щоб сформувати найбільш неправильне тлумачення того, що я написав. Будь ласка, не турбуйте себе.

— v vv cvvcv

1

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

— Девід Річербі

Чи можете ви чітко висловити своє розуміння "моєї претензії"? Як тільки ви спробуєте зробити це точно, я впевнений, що ви перестанете витрачати трафик на Інтернет.

— v vv cvvcv

Я комп'ютер, а не читач розуму. Зробити вашу претензію точною - це ваша робота, а не моя.

— Девід Річербі

-1

Питання задає питання: "чи можлива проблема, яка насправді стає простішою в міру збільшення розміру вхідних даних?" Що робити, якщо входи - це ресурси, які використовуються алгоритмом для роботи над завданням. Загальновідомо, що чим більше ресурсів, тим краще. Нижче наводиться приклад, в якому більше працівників є, тим краще.

$n$
$t$ $p$

$n$

3) Вихід:
Результат - це шлях між завданнями, які повинні виконувати працівники. Кожен шлях пов'язаний з кількістю працівників, які його проходять. Наприклад:

$n1$
$n2$
$n3$
$n4$
$n5$

4) Можливе рішення:
Одне можливе рішення - спочатку обчислити найкоротший шлях до найближчих вузлів від A. Це буде шлях вперед. Потім рекурсивно обчислюйте шлях вперед для кожного відвіданого завдання. Результат - дерево. Наприклад:

          А
      До н
    DE

$n$ $n1$ $n2$ $n2 \neq 0$

$n=\infty$ $n = 1$

$n$

— ємеліт
джерело

6

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

— DW

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

— yemelitc

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

— Девід Річербі

Я згоден. Здається, у нас все було досить критично, на відміну від того, що спокусило нас оригінальне запитання! Але, сподіваємось, ви зрозумієте моє уявлення про "вклад як ресурс": незалежно від того, наскільки велика робота, чим більше людей, тим краще. І все-таки в асимптотичному сенсі ви точно маєте рацію, я повинен просто звинувачувати це в негативних цілих числах.

— yemelitc