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

E>Это всё не так. И ООП тут не по делу. По делу иметь, например, просто массив вершин, а фигура будет зваться многоугольник

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

И куда эти три группы методов обрабатывающие разные фигуры запихнуть ?

Здравствуйте, Ночной Смотрящий, Вы писали:

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

PC_>>А на счет твоих задач, так сколько вы готовы заплатить за такой обьем работы ?

НС>А сколько ты хочешь? Интересует не часовой рейт, а общая сумма.

Решили с майтоном скинуться ?

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

M>Ну... я его уже написал. Рекурсией. Он работает. И кстати, это был не C# а С++ и поэтому эмиттер кода
какой эмиттер кода, у меня без эмиттера

M>бета-версии. Еще лучше — промышленное применение. Вспомни Джерика. Это был адский

Какое промышленное применение может быть у молодого языка,
даже Ф Шарп от Майкрософт и Немерле которому почти 10 лет и то на них никто не пишет в
промышленности. Майтон, это утопия задаваться целью внедрить чтото в промышленности, в особенности язык

M>Его решение было внедрено и работало! Что-бы там ни говорили завистники. И тебе

У Джерика это одно из тысяч кустарных NoSql решений, не уникальное, простой модуль по работе с массивом, который напарен на какомто
предприятии. И что это за показатель, Ораклу паковать чемоданы уже можно или еще подождать ?

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

PC_>>Следовательно если я изменю условия так,
PC_>>"Перебрать все пароли от a-z с длиной 5 символов,
PC_>>причем дважды одна и таже буква не может встречаться в пароле"

KV>

KV>def p(l, n)
KV>{
KV>    l.Fold([], (e, a) => if (n==1) [e]::a else p(l.Filter(x => x != e), n-1).Fold(a, (s, b) => (e::s)::b))
KV>}
KV>

ленивый

let rec p xs = function 
    | 0 -> seq [seq []]
    | n -> seq { for x in xs do
                     for r in p (Seq.filter ((<>)x) xs) (n-1) -> 
                         Seq.append [x] r }

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

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

S>>Писать генератор размещений без повторов. При его написании могут быть использованы эти функции. Но одними только ими вряд ли обойдется.
E>Ну покажи, как ты себе это представляешь? Типа просто цикл, которые клонирует переборщик и фильтрует его?

E>Ну там что-то вроде

E>переборщик перебратьРазмещенияБезПовторов( переборщик X, int count )
E>{
       if count == 0 остановить перебор
       для каджого x из X
           для каждого результата r перебратьРазмещенияБезПовторов(X без x, count-1)
               вернуть x склеенный с r
E>}

E>C+(D!=C?D)+(E!=C && E!=D?E)
рекурсии нет, заменить ее нечем — стеков нет. Передачи необходимых параметров переборщику — нет. удаления из массива нет, копий переменных внутри блока выражений делать нельзя.
Вобщем это решение не записать в РС. Как построить другое — Основная проблема — надо сказать переборщику — по каким буквам не ходить дальше.

Тут были тезисы ТС-а о том что его решение 5и случайных букв из алфавита настолько гибкое, что оно дескать трансформируется за нефиг делать в решение размещений без повторов и нифига не ломается от такой смены условий.
Уверен, что от него я не дождусь решения этой задачи на РС. Может твои идеи послушаю... На всякий случай еще раз уточню (не для тебя), что решения перебора всех вариантов с последующей фильтрацией не интересуют. Гибкость так гибкость.
Решение Владимира получает n!/(n-k)! ответов.
Моё в ответе ему — столько же, но оно может строить не все варианты, а только с интересующими номерами (для paging-а )
Решение задачи полного перебора имеет n! ответов. Их фильтрация займет n! времени.
Т.е. при n=30 и k=10, разница в количестве вариантов гигантская, т.е. последующая фильтрация не катит ну никак в сравнении с предоставленными Владимиром и мной решениями.

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

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

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

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

!x='a'..'f'
i<3?a+='+x'+i;
    b+=',x'+i
^(b + '\~?s,=' + a)
s

S>Уверен, что от него я не дождусь решения этой задачи на РС. Может твои идеи послушаю... На всякий случай еще раз уточню (не для тебя), что решения перебора всех вариантов с последующей фильтрацией не интересуют. Гибкость так гибкость.

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

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

S>Решение задачи полного перебора имеет n! ответов. Их фильтрация займет n! времени.

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

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

Так что все пучком. Ситуация вполне типичная для разных языков.
И по-моему мы договорились что за быстродействие транслятора будем бороться в последнюю очередь

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

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

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

E>>C+(D!=C?D)+(E!=C && E!=D?E)
S>нет, так не выразить. Уверен на 99.8%.

Почему?

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

S>таблица умножения 1..10. Посчитать сумму элементов выше диагонали квадратов.



(I*(I>J?J))\*

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

PC_>да, пардон. Сверху задача и без квадратных решается
Либо я не понял, что они делают, либо они никогда не нужны

Здравствуйте, 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 сек. Уже проблема, но я знаю, что подкрутить что бы пропуск занимал ничтожное время.

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

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

E>>>C+(D!=C?D)+(E!=C && E!=D?E)
S>>нет, так не выразить. Уверен на 99.8%.

E>Почему?
Не вижу нужных конструкций для решения, о котором говорил я.
А что вижу — 3 счетчика C,D,E, с которыми что-то делается в 3-ном цикле. Это не решение вообще в принципе. Ни то о котором говорил я, ни какое либо другое.

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

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

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

S>>таблица умножения 1..10. Посчитать сумму элементов выше диагонали квадратов.

E>(I*(I>J?J))\*
Вижу, версия для light транслятора с диапазоном счетчика 1..10 и колв-ом сложений равному 100. Кстати, сумма элементов а не произведение.

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

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

E>>Почему?
S>Не вижу нужных конструкций для решения, о котором говорил я.

Способ записать рекурсию в РС уже есть. Но записать генератор размещений на нем — неслабый вызов. Гордиться таким решением можно будет не меньше чем килобайтными шахматами.

Так что если есть желание доказать возможность записи рекурсивных размещений на РС, лучше начать хотя бы с рекурсивного факториала.
О пути записи рекурсии пока умолчу.
Путь хорош для решения головоломки, но при существовании языков с явной рекурсией о практическом проргаммировании таким способом можно не мечтать.

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


E>>>>C+(D!=C?D)+(E!=C && E!=D?E)
S>>>нет, так не выразить. Уверен на 99.8%.

E>>Почему?
S>Напомни, плиз, весь код

Ну это уже весь код
Это описан переборщик по кубу без повторов.

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

Это спор о реализации транслятора, а не о языке.
Ты никогда не можешь точно знать как работает РС, потому как он довольно таки декларативен.
Вот например в декларативном SQL func1(1) + func(2) это тоже ниразу не вызов двух функций, как мог бы подумать тот же сишник.
По семантике, да, вызываются две функции, результаты складываются. А реально оптимизатор может разобрать в ноль эти функции сделать из них одну и еще и переписать
там все полностью.

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

Вообщето скип, это почти тот же фильтр результата.
Сам знаешь что нормальная реализация начинает сразу с середины перебор,
а не чтото там скипит.

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

E>>Это всё не так. И ООП тут не по делу. По делу иметь, например, просто массив вершин, а фигура будет зваться многоугольник

PC_>Что значит массив вершин, это какое-то фортрановское решение.
Ну так на фортране просто кучу счёта написали. Не случайно это было...

PC_>Есть группа формул которые применимы к многоугольникам.
PC_>Есть группа упрощенных формул для прямоугольников.
PC_>Есть группа еще более упрощенных формул для квадратов.

Можно, как-то, поконкретнее, о чём бишь тут речь? Что за формулы?

PC_>И куда эти три группы методов обрабатывающие разные фигуры запихнуть ?
Ну как бы тебе сказать, чтобы без бану...


Пример приведи задачи, о которой идёт речь. Я вполне допускаю задачу, для которой квадрат, например, будет наследником прямоугольника. но это экзотика...

E>Пример приведи задачи, о которой идёт речь. Я вполне допускаю задачу, для которой квадрат, например, будет наследником прямоугольника. но это экзотика...

Задача простая.
Взять классическую иерархию фигур и представить в виде ООП
Ято с тобой согласен, что на счет фигур лучше обойтись массивами фигур,
но только из-за того что на таком примитивном примере недостатки ООП довольно хорошо просматриваются

В книжках например бывают рисуют такое.
[img=http://www.intuit.ru/department/se/oopbases/14/14_2.gif]

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


E>>Ну там что-то вроде

E>>переборщик перебратьРазмещенияБезПовторов( переборщик X, int count )
E>>{
S>       if count == 0 остановить перебор
S>       для каджого x из X
S>           для каждого результата r перебратьРазмещенияБезПовторов(X без x, count-1)
S>               вернуть x склеенный с r
E>>}

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

E>>C+(D!=C?D)+(E!=C && E!=D?E)
S>Вобщем это решение не записать в РС. Как построить другое — Основная проблема — надо сказать переборщику — по каким буквам не ходить дальше.

Прости, это вот выражение C+(D!=C?D)+(E!=C && E!=D?E) описывает тройки без повторов.
Вопрос в том, как снабдить это выражение параметром "скока букв генерим"...

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

Почему, ты считаешь, что филььрация последующая?

Выражение C+(D!=C?D)+(E!=C && E!=D?E) описывает всего лишь МНОЖЕСТВО перебираемых состояний...
Множество оно описывает верно.
Вопрос в том, можно ли его эффективно интерпретировать? Очевидно, что да, можно. Так и в чём таки проблема?

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

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

В идеологии RS было бы логично уметь оперировать понятием "позиция переборщика". И для переборщиков, с заданной последовательностью было бы удобно отрезки выделять и на димк можно было бы позицию записать, и НИЧЕГО не пропускать вообще...

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

E>В идеологии RS было бы логично уметь оперировать понятием "позиция переборщика". И для переборщиков, с заданной последовательностью было бы удобно отрезки выделять и на димк можно было бы позицию записать, и НИЧЕГО не пропускать вообще...

Здесь опять же проблемы послойности и аспектности.
Есть некоторые базовое решение — генератор.
И уже над ним есть аспект.
Аспекты которые мы разобрали — символы не повторяются, длина символов ограничена для части диапазона, отрезать часть диапазона.

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

Если развить аспектную парадигму то будет "картина маслом".
На все три тех видоизменения программы будет просто.

"генератор"
"аспект — символы не повторяются"

"генератор"
"аспект — длина символов ограничена для части диапазона"

"генератор"
"отрезать часть диапазона"

Просто нужно продумать синт. конструкции для аспектов и приблизительно разобраться как они должни лечь
в код интерпретатора.