Циклы рекурсии или пока

Я читал о некоторых практиках интервью для разработчиков, в частности о технических вопросах и тестах, которые задавались на собеседованиях, и я несколько раз спотыкался о высказываниях жанра: «Хорошо, вы решили проблему с помощью цикла while, теперь вы можете сделать это с помощью рекурсия ", или" каждый может решить это с помощью цикла из 100 строк, но может ли он сделать это с помощью рекурсивной функции из 5 строк? " и т.п.

Мой вопрос, является ли рекурсия вообще лучше, чем если / while / for конструкции?

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

Рекурсия по сути не лучше и не хуже циклов - у каждого есть свои преимущества и недостатки, и они даже зависят от языка программирования (и реализации).

Технически, итеративные циклы лучше подходят для типичных компьютерных систем на аппаратном уровне: на уровне машинного кода цикл - это просто тест и условный переход, тогда как рекурсия (реализованная наивно) включает в себя перемещение кадра стека, переход, возврат и возврат назад. из стека. OTOH, многие случаи рекурсии (особенно те, которые тривиально эквивалентны итеративным циклам) могут быть записаны так, чтобы можно было избежать push / pop стека; это возможно, когда рекурсивный вызов функции - это последнее, что происходит в теле функции перед возвратом, и это обычно называют оптимизацией хвостового вызова (или оптимизацией хвостовой рекурсии ). Правильно оптимизированная рекурсивная функция с хвостовым вызовом в основном эквивалентна итеративному циклу на уровне машинного кода.

Другое соображение заключается в том, что итеративные циклы требуют деструктивных обновлений состояния, что делает их несовместимыми с чистой (без побочных эффектов) семантикой языка. Это причина того, что чистые языки, такие как Haskell, вообще не имеют циклических конструкций, а во многих других языках функционального программирования их либо нет, либо они избегают их в максимально возможной степени.

Однако причина, по которой эти вопросы так часто встречаются в интервью, заключается в том, что для того, чтобы ответить на них, вам необходимо глубокое понимание многих жизненно важных концепций программирования - переменных, вызовов функций, области видимости и, конечно, циклов и рекурсии - и у вас есть привнести умственную гибкость в таблицу, которая позволяет подойти к проблеме с двух радикально разных точек зрения и перемещаться между различными проявлениями одной и той же концепции.

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

Если во время интервью вы получите такой вопрос, это хороший знак: это означает, что потенциальный работодатель ищет людей, которые могут программировать, а не людей, которые запомнили руководство по инструменту программирования.

По-разному.

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

Стоит также отметить, что поддержка хвостовой рекурсии делает хвостовые рекурсивные и итеративные циклы эквивалентными, то есть рекурсия не всегда должна тратить стек.

Кроме того, рекурсивный алгоритм всегда может быть реализован итеративно с использованием явного стека .

Наконец, я хотел бы отметить, что решение из пяти строк, вероятно, всегда лучше, чем решение из 100 строк (при условии, что они на самом деле эквивалентны).

Не существует общепризнанного определения «лучше», когда речь идет о программировании, но я буду понимать, что оно означает «легче поддерживать / читать».

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

Итак, от низкой выразительной мощности до высокой выразительной, циклические конструкции складываются следующим образом:

• Хвост рекурсивные функции, которые используют неизменные данные,
• Рекурсивные функции, которые используют неизменные данные,
• В то время как циклы, которые используют изменяемые данные,
• Хвост рекурсивных функций, которые используют изменяемые данные,
• Рекурсивные функции, которые используют изменяемые данные,

В идеале вы должны использовать наименее выразительные конструкции, какие только можете. Конечно, если ваш язык не поддерживает оптимизацию хвостовых вызовов, то это также может повлиять на ваш выбор конструкции цикла.

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

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

По сути, если это очевидный выбор между итерацией и рекурсией, сделайте интуитивно понятное дело. Если итерация делает работу легко, сохранение двух строк редко стоит головной боли, которую она может создать в долгосрочной перспективе.

Конечно, если это сэкономит вам 98 строк, это совсем другое дело.

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

По сути, если somefunction(x-1)нужно вызывать изнутри себя более одного раза на уровень, забудьте итерации.

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

Как обычно, это вообще не подлежит объяснению, потому что существуют дополнительные факторы, которые на практике широко неравны между случаями и не равны друг другу в рамках варианта использования. Вот некоторые из нагрузок.

• Короткий, элегантный код в целом превосходит длинный, сложный код.
• Однако последний пункт несколько недействителен, если ваша база разработчиков не знакома с рекурсией и не желает / не может учиться. Это может даже стать небольшим отрицательным, а не положительным.
• Рекурсия может отрицательно сказаться на эффективности, если на практике вам потребуются глубоко вложенные вызовы, и вы не можете использовать хвостовую рекурсию (или ваша среда не может оптимизировать хвостовую рекурсию).
• Рекурсия также плоха во многих случаях, если вы не можете правильно кэшировать промежуточные результаты. Например, общий пример использования рекурсии дерева для вычисления чисел Фибоначчи работает ужасно плохо, если вы не кешируете. Если вы делаете кеш, это просто, быстро, элегантно и в целом замечательно.
• Рекурсия неприменима в некоторых случаях, так же хороша, как итерация в других, и абсолютно необходима в других. Пробираться по длинным цепочкам бизнес-правил обычно не помогает рекурсия. Итерация по потокам данных может быть полезна с помощью рекурсии. Итерирование по многомерным динамическим структурам данных (например, лабиринты, деревья объектов ...) практически невозможно без рекурсии, явной или неявной. Обратите внимание, что в этих случаях явная рекурсия намного лучше, чем неявная - нет ничего более болезненного, чем чтение кода, где кто-то реализовал свой собственный, неполный, неполный, глючный стек в языке, просто чтобы избежать страшного R-слова.

Рекурсия - это повторение вызова функции, цикл - это повторение перехода в память.

Следует также упомянуть о переполнении стека - http://en.wikipedia.org/wiki/Stack_overflow

Это действительно зависит от удобства или требования:

Если вы берете язык программирования Python , он поддерживает рекурсию, но по умолчанию существует ограничение на глубину рекурсии (1000). Если он превысит лимит, мы получим ошибку или исключение. Это ограничение можно изменить, но если мы сделаем это, у нас могут возникнуть ненормальные ситуации в языке.

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

Используйте шаблон дизайна стратегии.

• Рекурсия чистая
• Петли (возможно) эффективны

В зависимости от вашей нагрузки (и / или других условий) выберите один.