Здравствуйте, Erop, Вы писали:
E>Это всё не так. И ООП тут не по делу. По делу иметь, например, просто массив вершин, а фигура будет зваться многоугольник
Что значит массив вершин, это какое-то фортрановское решение.
Есть группа формул которые применимы к многоугольникам.
Есть группа упрощенных формул для прямоугольников.
Есть группа еще более упрощенных формул для квадратов.
И куда эти три группы методов обрабатывающие разные фигуры запихнуть ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, PC_2, Вы писали:
PC_>>А на счет твоих задач, так сколько вы готовы заплатить за такой обьем работы ?
НС>А сколько ты хочешь? Интересует не часовой рейт, а общая сумма.
Решили с майтоном скинуться ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, mayton, Вы писали:
M>Ну... я его уже написал. Рекурсией. Он работает. И кстати, это был не C# а С++ и поэтому эмиттер кода
какой эмиттер кода, у меня без эмиттера
M>бета-версии. Еще лучше — промышленное применение. Вспомни Джерика. Это был адский
Какое промышленное применение может быть у молодого языка,
даже Ф Шарп от Майкрософт и Немерле которому почти 10 лет и то на них никто не пишет в
промышленности. Майтон, это утопия задаваться целью внедрить чтото в промышленности, в особенности язык
M>Его решение было внедрено и работало! Что-бы там ни говорили завистники. И тебе
У Джерика это одно из тысяч кустарных NoSql решений, не уникальное, простой модуль по работе с массивом, который напарен на какомто
предприятии. И что это за показатель, Ораклу паковать чемоданы уже можно или еще подождать ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, 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, разница в количестве вариантов гигантская, т.е. последующая фильтрация не катит ну никак в сравнении с предоставленными Владимиром и мной решениями.
А нельзя ли запустить свой алгоритм, чтобы определить сколько решение с фиалками
его будет считать ?
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, 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>Не вижу нужных конструкций для решения, о котором говорил я.
Способ записать рекурсию в РС уже есть. Но записать генератор размещений на нем — неслабый вызов. Гордиться таким решением можно будет не меньше чем килобайтными шахматами.
Так что если есть желание доказать возможность записи рекурсивных размещений на РС, лучше начать хотя бы с рекурсивного факториала.
О пути записи рекурсии пока умолчу.
Путь хорош для решения головоломки, но при существовании языков с явной рекурсией о практическом проргаммировании таким способом можно не мечтать.
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 сек. Уже проблема, но я знаю, что подкрутить что бы пропуск занимал ничтожное время.
Вообщето скип, это почти тот же фильтр результата.
Сам знаешь что нормальная реализация начинает сразу с середины перебор,
а не чтото там скипит.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, PC_2, Вы писали:
E>>Это всё не так. И ООП тут не по делу. По делу иметь, например, просто массив вершин, а фигура будет зваться многоугольник
PC_>Что значит массив вершин, это какое-то фортрановское решение.
Ну так на фортране просто кучу счёта написали. Не случайно это было...
PC_>Есть группа формул которые применимы к многоугольникам. PC_>Есть группа упрощенных формул для прямоугольников. PC_>Есть группа еще более упрощенных формул для квадратов.
Можно, как-то, поконкретнее, о чём бишь тут речь? Что за формулы?
PC_>И куда эти три группы методов обрабатывающие разные фигуры запихнуть ?
Ну как бы тебе сказать, чтобы без бану...
Пример приведи задачи, о которой идёт речь. Я вполне допускаю задачу, для которой квадрат, например, будет наследником прямоугольника. но это экзотика...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
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 было бы логично уметь оперировать понятием "позиция переборщика". И для переборщиков, с заданной последовательностью было бы удобно отрезки выделять и на димк можно было бы позицию записать, и НИЧЕГО не пропускать вообще...
Здесь опять же проблемы послойности и аспектности.
Есть некоторые базовое решение — генератор.
И уже над ним есть аспект.
Аспекты которые мы разобрали — символы не повторяются, длина символов ограничена для части диапазона, отрезать часть диапазона.
Так вот, мержь разных слоев ломает всю структуру и заставляет ломать мозг программисту.
Код плохо расширяемый и плохо поддерживаемый, длинный и главное что плох для понимания.
Если развить аспектную парадигму то будет "картина маслом".
На все три тех видоизменения программы будет просто.
"генератор"
"аспект — символы не повторяются"
"генератор"
"аспект — длина символов ограничена для части диапазона"
"генератор"
"отрезать часть диапазона"
Просто нужно продумать синт. конструкции для аспектов и приблизительно разобраться как они должни лечь
в код интерпретатора.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН