Існує досить сильна підтримка мета для складання запитань із написання викликів на основну тему, за умови, що ці питання є конкретними та відповідальними. Однак у нас ще немає таких питань, тому я подумав, що перевіряю води. Це питання, ймовірно, входить на добру суб'єктивну, погану суб'єктивну територію, але я думаю, що це, мабуть, те, що потрібно писати на виклики, що складатимуться. Щоб вони все ще створювали якісний контент, будь ласка, не публікуйте у відповідях диких умоглядних ідей. Поясніть, чому вони уникають проблем, зазначених нижче, або в ідеалі вказують на існуючі проблеми, які успішно використовували запропоновану методику в минулому.
Для певних проблем з оптимізацією вільним параметром у встановленні завдання є розмір проблеми, яку необхідно оптимізувати. Під "оптимізаційним викликом" я не маю на увазі такі речі, як наш жанр найшвидшого коду , де відповіді, як правило, вимагають бути точними / оптимальними, а виклик оцінюється або за фіксованим розміром проблеми, або за найбільшим розміром проблеми, який можна вирішити. за фіксовану кількість часу. Я маю на увазі конкретні виклики, коли субоптимальні рішення основної проблеми дозволені та навіть ймовірні, а мета - зробити якнайкраще.
Для певності розгляньте проблеми, пов'язані із зайнятими бобрами , хоча в принципі це стосується і інших типів викликів без відомих оптимальних рішень (я просто використовую тут зайнятих бобрів, оскільки вони посилюють проблеми, про які йдеться нижче). Скажіть, я хотів зробити виклик щодо пошуку найзайнятішого бобра Брейнфука. Вільний параметр у проблемах із зайнятими бобрами - це розмір коду. Я не можу встановити виклик, не посилаючись на розмір коду. Певним чином, кожне значення параметра розміру проблеми Nзадає окрему (дедалі складнішу) задачу. Моє головне питання - як я можу змусити таку складну роботу не стикатися з проблемами балансування.
Очевидним рішенням є виправити N: "Знайдіть програму Brainfuck, що закінчується, з Nбайтами вихідного коду, який друкує якомога більше символів / працює на якомога більше кліків." Це має великі проблеми з балансуванням: якщо я вибираю розмір занадто малий, хтось може швидко знайти йогонайпотужніший бобр і виклик закінчений. Якщо я виберу розмір занадто великий, оптимальне рішення надрукує астрономічну кількість символів перед тим, як закінчувати, а це означає, що, ймовірно, буде тривіально знайти такі програми, і виклик стане рутиною / вправою у терпінні - це також залишає територію, де зайнятих бобрів можна знайти програмно, і натомість людям потрібно буде офіційно доводити свої результати, які багато людей можуть не вважати дуже цікавими. Звичайно, ця проблема є більш вираженою у проблемах, пов’язаних із бобрами, ніж інші типи, через зростання оптимальних рішень, але вона все ж стосується інших проблем.
Наступний варіант може залишити без Nобмежень і зробити його частиною підрахунку за допомогою якоїсь функції. Навіть для «нормальних» проблем отримати баланс комбінованих балів правильно неймовірно складно, але у випадку зайнятих бобрів це фактично принципово неможливо, через те, що оптимальні рішення ростуть швидше, Nніж будь-яка обчислювальна функція. Це означає, що я завжди можу перемогти найкращу існуючу відповідь, перейшовши на достатньо великий, Nде я можу легко знайти програму, яка працює так довго, що я можу отримати кращу оцінку без особливих зусиль.
Я також розглядав питання про встановлення фіксованого стану Nта надання можливості людям також подавати бобри на більші розміри, Nякі будуть використовуватися як послідовні вимикачі. У цьому є аналогічна проблема в тому, що хтось може просто «знайти так само хорошого зайнятого бобра» для a N, тим самим створивши краватку, а потім просто подати майже все на наступне, Nде знайти велику оцінку простіше (навіть якщо знайти оптимальна оцінка стає важче). Як у цих випадках ви поводилися б із кількома людьми, використовуючи одне й те саме рішення? Забороняти це було б також дивно, якщо це оптимально.
Можливо, можна вдаритися по середній частині, зробивши освіченою здогадкою розумне, Nа потім попросивши зайнятих бобрів усіх розмірів у межах (скажімо, 5 байт) N, щоб у обох напрямках було трохи свободи (і тоді ви комбінуєте ~ 10 балів в єдину за тією чи іншою технікою). Це не дуже задовільно, тому що мої початкові здогадки Nвсе ще можуть бути далеко поза діапазоном, що викликає цікаві виклики.
TL; DR: у випадках, коли завдання полягає в (неоптимальному вирішенні та) оптимізації проблеми, розмір якої мінливий, як я включити розмір у виклик? В ідеалі я хотів би, щоб люди могли працювати з значенням, Nяке знаходиться біля верхнього кінця діапазону простежуваних розмірів. Але на всякий випадок, коли виявиться, що для цього можливі оптимальні рішення N, було б чудово, якби рішення для трохи більших розмірів Nпочали зважувати, таким чином, щоб виклик міг продовжуватися з більш цікавим розміром проблеми.