Рекурсія або петлі під час

Я читав про деякі практики інтерв'ю з розвитку, зокрема про технічні питання та тести, задані на інтерв'ю, і я досить багато разів натрапляв на приказки жанру "Добре, ви вирішили проблему з певного циклу, тепер ви можете це зробити з рекурсія ", або" кожен може вирішити це за допомогою 100 рядків під час циклу, але чи можуть вони це робити в 5-ти рядкових рекурсивних функціях? " тощо.

Моє запитання: чи рекурсія в цілому краща, ніж якщо / поки / для конструкцій?

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

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

Технічно ітеративні петлі краще підходять типовим комп'ютерним системам краще на апаратному рівні: на рівні машинного коду цикл - це лише тест і умовний стрибок, тоді як рекурсія (реалізована наївно) передбачає натискання кадру стека, стрибки, повернення та відскок назад зі стека. OTOH, багато випадків рекурсії (особливо тих, які тривіально еквівалентні ітераційним циклам) можуть бути записані таким чином, щоб уникнути натискання / вискоку стека; це можливо, коли рекурсивний виклик функції - це останнє, що відбувається в тілі функції перед поверненням, і це зазвичай відоме як оптимізація хвостового виклику (або оптимізація хвостової рекурсії ). Рекурсивна функція, оптимізована для хвостового виклику, в основному еквівалентна ітераційній петлі на рівні машинного коду.

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

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

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

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

Це залежить.

• Деякі проблеми дуже піддаються рекурсивним рішенням, наприклад, швидкий вибір
• Деякі мови насправді не підтримують рекурсію, наприклад, ранні FORTRAN
• Деякі мови передбачають рекурсію як основний засіб для циклічного циклу, наприклад, Haskell

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

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

Нарешті, я зазначу, що п'ятирядковий варіант, ймовірно, завжди кращий, ніж 100-рядковий (якщо припустити, що вони є рівнозначними).

Немає загального погодження щодо визначення "кращого", коли мова йде про програмування, але я вважаю, що це означає "легше підтримувати / читати".

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

Отже, від низької виразної сили до високої виразної сили, циклічні конструкції складаються таким чином:

• Рекурсивні функції хвоста, які використовують незмінні дані,
• Рекурсивні функції, що використовують незмінні дані,
• Хоча петлі, які використовують змінні дані,
• Рекурсивні функції хвоста, які використовують зміни даних,
• Рекурсивні функції, що використовують зміни даних,

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

Рекурсія часто менш очевидна. Менш очевидною важче підтримувати.

Якщо ви пишете for(i=0;i<ITER_LIMIT;i++){somefunction(i);}в основному потоці, ви даєте зрозуміти, що ви пишете цикл. Якщо ви пишете, somefunction(ITER_LIMIT);ви не дуже даєте зрозуміти, що буде. Тільки бачачи вміст: цей somefunction(int x)виклик somefunction(x-1)говорить вам, що насправді це цикл із використанням ітерацій. Крім того, ви не можете легко поставити умову втечі з break;десь на півдорозі ітерацій, ви повинні або додати умовний, який буде переданий увесь шлях назад, або викинути виняток. (а винятки знову додають складності ...)

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

Звичайно, якщо це заощадить 98 рядків, це зовсім інша справа.

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

По суті, якщо somefunction(x-1)потрібно викликати всередині себе більше одного разу на рівні, забудьте про повторення.

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

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

• Короткий, елегантний код загалом перевершує довгий, хитромудрий код.
• Однак останній пункт дещо визнається недійсним, якщо база розробників не знайома з рекурсією та не бажає / не може вчитися. Він може навіть стати легким негативом, а не позитивним.
• Рекурсія може бути поганою для ефективності, якщо вам знадобляться глибоко вкладені дзвінки на практиці і ви не можете використовувати хвостову рекурсію (або ваше оточення не може оптимізувати хвостову рекурсію).
• Рекурсія також є поганою у багатьох випадках, якщо ви не можете правильно кешувати проміжні результати. Наприклад, поширений приклад використання рекурсії дерева для обчислення чисел Фібоначчі виявляється жахливо поганим, якщо ви не кешуєте. Якщо ви кешуєте, це просто, швидко, елегантно і взагалі чудово.
• Рекурсія в деяких випадках не застосовується, так само як ітерація в інших, і абсолютно необхідна в інших. Прокладка через довгі ланцюги правил бізнесу зазвичай не допомагає рекурсії. Ітерація через потоки даних може бути корисно виконана з рекурсією. Ітерація над багатовимірними динамічними структурами даних (наприклад, лабіринти, дерева об'єктів ...) майже неможлива без рекурсії, явної чи неявної. Зауважте, що в цих випадках явна рекурсія набагато краще, ніж неявна - ніщо не болючіше, ніж читання коду, коли хтось реалізував власний спеціальний, неповний, баггі-стек всередині мови, щоб уникнути страшного R-слова.

Рекурсія - це повтор виклику до функції, цикл - це повторний стрибок, який потрібно розмістити в пам'яті.

Слід згадати також про переповнення стека - http://en.wikipedia.org/wiki/Stack_overflow

Це дійсно залежить від зручності чи вимоги:

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

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

Використовуйте схему розробки стратегії.

• Рекурсія чиста
• Петлі (мабуть) ефективні

Залежно від вашого навантаження (та / або інших умов), виберіть його.