Здравствуйте, PC_2, Вы писали:

S>>Тут были тезисы ТС-а о том что его решение 5и случайных букв из алфавита настолько гибкое, что оно дескать трансформируется за нефиг делать в решение размещений без повторов и нифига не ломается от такой смены условий.

PC_>Давай взглянем на мое решение

PC_>

PC_>!x='a'..'f'
PC_>i<3?a+='+x'+i
PC_>^('s,=' + a)
PC_>s
PC_>

PC_>И подумаем, что тут не хватает. А тут не хватает лишь одного условия. Не добавлять в массив вариант строки если есть повторные элементы.
молодчик
уделал дедушку
PC_>Если допустить что в языке есть фолдинг
допустим, т.к. меня интересует алгоритмическая сторона

PC_>Кстате если бы я решал эту задачу на Си, то по семантике было бы почти тоже самое.

PC_>Сгенерили последовательность
PC_> Проверили что символы в ней уникальны
PC_> Если уникальы добавили в массив

PC_>И что ? Зависимость тут линейная.
Смотря с чем сравнивать.
PC_>Допустим на Си этот алгоритм работает 1 час, на Бейсике 2 часа.
PC_>На Си 1 секунда, на бейсике 2 секунды. На Си 1 минута, на Жаваскрипт тотже алгоритм 5 минут ...

PC_>Так что какая разница, если на Ф шарп это будет работать 1 минуту,
PC_>а на РС 2 минуты (генератор+фильтрация) ?

PC_>Так что все пучком. Ситуация вполне типичная для разных языков.
PC_>И по-моему мы договорились что за быстродействие транслятора будем бороться в последнюю очередь
Давай предположим что транслятор (который на самом деле пока лишь интерпретатор) не имеет накладных расходов и твое решение на РС работает со скоростью аналогичного решения на C#.

Но я вижу что ты уверен что твой алгоритм имеет туже сложность, как алгоритм, который представил Владимир...
А на самом деле только лишь на последнем шаге (при добавлении финальной буквы к каждому из уже полученных паролей длиной k-1) тебе придется каждый пароль проверить на факт содержания в нем каждого символа из алфавита. Причем n-1 из этих проверок будут явно лишними.
Только на последнем шаге алгоритмическая стоимость генерации увеличивается в n(k-1) раз.
Твой алгоритм лучше полного перебора с последующей фильтрацией. Но намного ли?

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

S>>Т.е. при n=30 и k=10, разница в количестве вариантов гигантская, т.е. последующая фильтрация не катит ну никак в сравнении с предоставленными Владимиром и мной решениями.

PC_>А нельзя ли запустить свой алгоритм, чтобы определить сколько решение с фиалками
PC_>его будет считать ?
Это зависит от параметров запуска. Мне тут гугль подсказал что число решений 10 из 30 будет

1.0902735 × 10^14

Боюсь, что не смогу удовлетворить твое любопытство. Называй параметры — посмотрим что можно сделать.
И взаимно — сколько работает твое при тех же условиях?

Ладно, теперь я меняю условия задачи. Логично предположить что мы используем генерилку для брутфорса (хохмы для). Генерилка проверяет пароли по мере получения (кстати, твои не лезут в память 32х разрядного приложения уже при параметрах 5 из 30). И каждую минуту сбрасывает на винт число проверенных паролей, потому как хакеру периодически нужны ресурсы системы для решения других задач и он хочет продолжить счет с последнего сохраненного номера.
Вот так неожиданно меняются требования в реальном мире. Проявляй гибкость.

Наперед скажу, что в моем решении менять ничего не надо. Пропустить 10000 элементов (skip 10000 (p 30 10)) результирующей последовательности занимает 0,24s и 10001-ый элемент равен 'abcdefg3vl' при алфавите ['a'..'z']++['1'..'4']. Пропуск миллиона вариантов занимает <20 сек. Уже проблема, но я знаю, что подкрутить что бы пропуск занимал ничтожное время.