Итерация (программирование)

Итерация в программировании — в широком смысле — организация обработки данных, при которой действия повторяются многократно, не приводя при этом к вызовам самих себя (в отличие от рекурсии). В узком смысле — один шаг итерационного, циклического процесса.

Когда какое-то действие необходимо повторить большое количество раз, в программировании используются циклы. Например, нужно вывести 200 раз на экран текст «Hello, World!». Вместо двухсоткратного повторения одной и той же команды вывода текста часто создается цикл, который повторяется 200 раз и 200 раз выполняет то, что написано в теле цикла.

Источник: Википедия

Упоминания в литературе

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

Е. В. Николаева, Фракталы городской культуры, 2014

Анализ топологии процесса может проводиться в несколько итераций. В результате первоначальный построенный процесс может кардинально измениться. Например, функции, которые раньше выполнялись последовательно друг за другом, стали выполняться параллельно. Цель данного анализа – добиться максимально понятного течения процесса, отражающего при этом либо реальное положение вещей, либо оптимальное с учетом доступности ресурсов.

Е. И. Всяких, Практика и проблематика моделирования бизнес-процессов

Ракурс, который нам дает теория исследований операции, позволяет увидеть и особую роль механизмов бифуркации в развитии материн. Используя язык этой теории, мы могли бы сказать, что бифуркационные механизмы в отличие от механизмов адаптационного типа осуществляют нелокальную оптимизацию. То, что начинает происходить в природе, когда вступает в действие бифуркационный механизм, можно уподобить ситуации, в которой вычислитель, работая с диалоговой системой оптимизации, время от времени при решении сложной задачи отступает от использования локальных алгоритмов типа наискорейшего пуска. Так он поступает всякий раз, когда используемый алгоритм «зацикливается», т. е. когда последующие итерации с помощью этого алгоритма перестают совершенствовать систему, т. е. приближать нас к точке минимума. В этом случае опытный вычислитель, как правило, переходит на метод Монте-Карло или какой-нибудь другой метод нелокального спуска.

Н. Н. Моисеев, Алгоритмы развития, 1987

В биологии простые формы оказываются во многих случаях более адаптивными, чем сложные, да и в культуре сложность организации как отдельных образований, так и целых социально-исторических систем вовсе не даёт гарантий их выживания и успешного ответа на разного рода вызовы., Трансцендентность вектора усложнения обусловлена, думаю, тем, что сложность структуры пропорциональна скоростям протекающих в ней процессов. Ведь чем выше уровень сложности, тем больше скорости внутренних взаимодействий[59]. А ускорение процессов – показатель сжатия времени, на глобальном уровне стремящегося к своему снятию. В этом смысле, каждая локальная система живёт в своём темпомире, внутренне ускоряющемся по ходу эволюционных итераций. Так, вектор усложнения устремляется к возврату (на новом, разумеется, уровне) в состояние не-длительности. Даже если сжатие времени и не достигает (никогда не достигнет?) метафизической точки снятия, а просто стремится к бесконечности, то и этого достаточно, чтобы служить глобальным трендом эволюционного усложнения форм и систем. Стремление доводить всё до логического конца – в данном случае до финализма квазигегелевского толка – въевшаяся в подсознание привычка, выработанная рационалистическим логицизмом. Однако сама действительность никаких «логических концов», как правило, не приемлет. Так, результатом «критического» уплотнения времени может стать растворение каузальности в когерентности, преодоление необратимости времени и т. п.

Андрей Пелипенко, Избранные работы по теории культуры, 2014

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

Константин Добрев, ТАРО Иерофанта. Архитектура человека по системе ТАРО, 2016

В части IV мы переключаем внимание на вопросы, связанные с составлением календарных графиков для проекта. Глава 13 открывается обзором этапов составления календарных графиков для сравнительно простого, выполняемого одной командой проекта. В следующей главе (14) рассматривается вопрос планирования итераций. Главы 15 и 16 посвящены выбору длины итераций для проекта и оценке первоначального темпа продвижения команды. В главе 17 детально разбирается составление календарных графиков для проекта с высоким уровнем неопределенности или с высокой чувствительностью к некорректности графика. Раздел завершается главой 18, в которой описываются дополнительные этапы при оценке и планировании проекта, осуществляемого несколькими командами.

Майк Кон, Agile: оценка и планирование проектов, 2006

При этом легкие методологии также отличаются друг от друга – Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология «Adaptive Software Development» разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках). Scrum характерен активным воздействием внешних лиц по отношению к рабочей группе, при этом у заказчика сохраняется максимальный приоритет. Заказчик продукта сам решает, как оформить бэклог продукта, выбирает требования для следующей итерации. При этом несоблюдение базовых принципов, заложенных в Scrum, таких как самонаправляемые команды, обязательная расстановка приоритетов или еженедельные обновления, может привести к срыву проекта.

С. М. Авдошин, Информатизация бизнеса. Управление рисками, 2011