Т.к. порядок их поступления мне был не важен, то был выбран "Рекурсивный алгоритм".
Смысл его прост: http://kolyanlab.alfamoon.com/algoritmy ... restanovok
Никогда не любил рекурсии, по этому всегда стараюсь их избегать. По крайней мере, еще не встретилось ни одной задачи, где без нее нельзя было бы обойтись. Никто не станет спорить, что это достаточно мощный механизм, но слабо контролируемый, так что можно легко потерять над ним контроль и локализовать ошибку.Идея перебора проста. Начинаем с последнего элемента, ставим на его место все возможные варианты, и для каждого обмена запускаем тот же алгоритм, но сделаем вид, что теперь реально последнего элемента вообще не существует и последним будет считаться предпоследний и т.д. В итоге наших махинаций рано или поздно последним будет считаться первый элемент, его ни с чем переставлять уже не надо, это будет база рекурсии, и мы получили один из вариантов перестановки. Чтобы нагляднее понять, как это все работает, посмотрите на следующую схему работы для 4-х элементного набора. Все, что стоит справа от | не видно для нашего алгоритма, то есть первый, стоящий слева от | элемент - последний элемент в представлении текущей итерации рекурсии. Зеленый прямоугольник означает то, что мы нашли одну из перестановок.
Я по старинке, реализовал "Рекурсивный алгоритм" без рекурсии: Но что, то есть магическое в слове "рекурсия" и я решил попробовать .
Почти все примеры на просторах Internet сводятся к демонстрации возможностей рекурсии при вычислении факториала числа, но удалось найти несколько примеров: http://www.ni.com/white-paper/9387/en
И неплохую презенташку от JKI Blog: Немного покумекав переделал программу, реализовав в ней именно рекурсию в чистом виде: ------------------------------------------------------------------------
Но я был бы не я, если бы не попробовал сравнить два варианта программ, выполняющих одну функцию . Сравнение выполнялось с помощью программы: И вот что получилось: Получается, что рекурсия дает выигрыш только в самом начале, а там он особо и не нужно. А вот при больших количествах комбинаций, рекурсисия проигрывает и чем дальше, тем больше .
Спрашивается, зачем запускать неконтролируемый процесс, который подобен водородной бомбе, если он не имеет явных преимуществ?
Может в других языках программирования с этим дело обстоит лучшим образом, но видимо не в LabVIEW. Хотя и появилась эта возможность не так давно.
p.s. Тестирование выполнялось на NoteBook, под управлением Linux. Версия LabVIEW 2010.