Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
E>>>>>C+(D!=C?D)+(E!=C && E!=D?E) S>>>>нет, так не выразить. Уверен на 99.8%.
E>>>Почему? S>>Напомни, плиз, весь код
E>Ну это уже весь код E>Это описан переборщик по кубу без повторов.
Т.е. тройной цикл. Это лишь решение частной задачи. Если обобщить, то сложность решения увеличивается в O(N) раз на каждую дополнительную букву. O(C^N), грустно.
Здравствуйте, samius, Вы писали:
S>Не вижу нужных конструкций для решения, о котором говорил я. S>А что вижу — 3 счетчика C,D,E, с которыми что-то делается в 3-ном цикле. Это не решение вообще в принципе. Ни то о котором говорил я, ни какое либо другое.
Почему только в третьем?
Почему нельзя делать отсечения во внещних циклах?
Очевидно же, что интерпретатор с МИНИМАЛЬНОЙ оптимизацией будет выбирать в каком порядке итерировать, чобы быстрее получилось. И можно выбрать ту ось, по которой возможны отсечения раньше той, по которой не возможны...
S>Если ты считаешь что так решение записать можно, то логично что ты будешь это доказывать, чем я опровергать.
Что значит "можно"? Это уже запись нужного множества.
S>Тем более, что я слабо представляю смысл написанного.
В смысле?
Смотри, растолкую по кусочкам. Что именно из этого ты не понимаешь?
C -- переборщик букв.
(C!=D?D) -- связанный с C переборщик, который перебирает для какой-то позиции С все буквы, кроме той, которая выбрана в С
(E!=C && E!=D ?E) -- связанный с С и D переборщик, который для каждой позиции С и D перебирает все буквы, кроме тех, котрые выбраны С и D...
C+(C!=D?D)+(E!=C && E!=D ?E) -- переборщик конкатенаций этих троек букв...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
S>Вижу, версия для light транслятора с диапазоном счетчика 1..10 и колв-ом сложений равному 100. Кстати, сумма элементов а не произведение.
Ну это опечатка. Ты же понял?
Суть претензий, правда, я не понял.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, samius, Вы писали:
S>О пути записи рекурсии пока умолчу.
Это функция eval
Такую рекурсию в LISP принято называть сложной. Только там это удобнее делать, так как там сама базовая структура данных -- список, может интерпретироваться, как список лексем некой LISP-функции...
И это не головоломки, а вполне разработанная тема в программировании. Просто сейчас это снова не модно
Сейчас функциональщину можно писать в несколько ином ключе.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, PC_2, Вы писали:
E>>Пример приведи задачи, о которой идёт речь. Я вполне допускаю задачу, для которой квадрат, например, будет наследником прямоугольника. но это экзотика...
PC_>Задача простая. PC_>Взять классическую иерархию фигур и представить в виде ООП PC_>Ято с тобой согласен, что на счет фигур лучше обойтись массивами фигур, PC_>но только из-за того что на таком примитивном примере недостатки ООП довольно хорошо просматриваются
PC_>В книжках например бывают рисуют такое. PC_>[img=http://www.intuit.ru/department/se/oopbases/14/14_2.gif]
Это плохая книжка. Уже наличие классов "3-угольник" и "4-угольник" безмерно доставляет...
Интересно они на 127-угольнике остановились или нет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, PC_2, Вы писали:
S>>Только на последнем шаге алгоритмическая стоимость генерации увеличивается в n(k-1) раз. S>>Твой алгоритм лучше полного перебора с последующей фильтрацией. Но намного ли?
PC_>Это спор о реализации транслятора, а не о языке. PC_>Ты никогда не можешь точно знать как работает РС, потому как он довольно таки декларативен.
Нет оснований предполагать что транслятор (особенно твой) вставит эвристики и понизит сложность задачи.
PC_>Вот например в декларативном SQL func1(1) + func(2) это тоже ниразу не вызов двух функций, как мог бы подумать тот же сишник. PC_>По семантике, да, вызываются две функции, результаты складываются. А реально оптимизатор может разобрать в ноль эти функции сделать из них одну и еще и переписать PC_>там все полностью.
Ты прикидываешься или на самом деле не знаешь как оценивается сложность алгоритмов?
S>>Ладно, теперь я меняю условия задачи. Логично предположить что мы используем генерилку для брутфорса (хохмы для). Генерилка проверяет пароли по мере получения (кстати, твои не лезут в память 32х разрядного приложения уже при параметрах 5 из 30). И каждую минуту сбрасывает на винт число проверенных паролей, потому как хакеру периодически нужны ресурсы системы для решения других задач и он хочет продолжить счет с последнего сохраненного номера. S>>Наперед скажу, что в моем решении менять ничего не надо. Пропустить 10000 элементов (skip 10000 (p 30 10)) результирующей последовательности занимает 0,24s и 10001-ый элемент равен 'abcdefg3vl' при алфавите ['a'..'z']++['1'..'4']. Пропуск миллиона вариантов занимает <20 сек. Уже проблема, но я знаю, что подкрутить что бы пропуск занимал ничтожное время.
PC_>Вообщето скип, это почти тот же фильтр результата.
Ты даже не понял, что результаты по скипу не вычисляются? Ты походу слил, но сам еще не понял это.
PC_>Сам знаешь что нормальная реализация начинает сразу с середины перебор, PC_>а не чтото там скипит.
Твой подход умеет вообще скипать вычисления?
Сразу с середины это вряд ли, но уменьшить стоимость скипа до логарифма — реально.
Не надеюсь что ты покажешь, как это делается на РС.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
S>>А что вижу — 3 счетчика C,D,E, с которыми что-то делается в 3-ном цикле. Это не решение вообще в принципе. Ни то о котором говорил я, ни какое либо другое. E>Почему только в третьем? E>Почему нельзя делать отсечения во внещних циклах?
Я думал что ты записал решение общего случая, а оказалось что 3 из n. Да, может и во внешних. Но продолжишь ли ты его по индукции до k из n?
E>Очевидно же, что интерпретатор с МИНИМАЛЬНОЙ оптимизацией будет выбирать в каком порядке итерировать, чобы быстрее получилось. И можно выбрать ту ось, по которой возможны отсечения раньше той, по которой не возможны...
Пока нет оснований полагать что будет такая оптимизация. Если и будет, чего она будет стоить?
S>>Если ты считаешь что так решение записать можно, то логично что ты будешь это доказывать, чем я опровергать. E>Что значит "можно"? Это уже запись нужного множества.
А обобщенно для k?
E>C -- переборщик букв. E>(C!=D?D) -- связанный с C переборщик, который перебирает для какой-то позиции С все буквы, кроме той, которая выбрана в С
N^2
E>(E!=C && E!=D ?E) -- связанный с С и D переборщик, который для каждой позиции С и D перебирает все буквы, кроме тех, котрые выбраны С и D...
N^3
E>C+(C!=D?D)+(E!=C && E!=D ?E) -- переборщик конкатенаций этих троек букв...
Круто. Запишешь для четверок и пятерок?
Здравствуйте, samius, Вы писали:
E>>Это описан переборщик по кубу без повторов. S>Т.е. тройной цикл.
перебор размещения троек, хотя бы из четырёх -- это всегда тройной цикл, так в итерируется трёхмерное многообразие трёхмерное... S>Это лишь решение частной задачи. Если обобщить, то сложность решения увеличивается в O(N) раз на каждую дополнительную букву. O(C^N), грустно.
Это не правда. Ты можешь отсекать перебор по каждой из осей, а не в самом низу...
Сложность будет O(число размещений)...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, 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>э-э-э, "вернуть" внутри "для каждого" концептуально ен ясны для меня...
Это же переборщик. Но он перебирает не числа а решения.
E>Прости, это вот выражение C+(D!=C?D)+(E!=C && E!=D?E) описывает тройки без повторов.
ок, соглашусь E>Вопрос в том, как снабдить это выражение параметром "скока букв генерим"...
И только после ответа на этот вопрос можно будет говорить о решении.
S>>Т.е. при n=30 и k=10, разница в количестве вариантов гигантская, т.е. последующая фильтрация не катит ну никак в сравнении с предоставленными Владимиром и мной решениями.
E>Почему, ты считаешь, что филььрация последующая?
Да, теперь вижу что не последующая. Но разница в кол-ве вычислений все равно гигантская.
E>Выражение C+(D!=C?D)+(E!=C && E!=D?E) описывает всего лишь МНОЖЕСТВО перебираемых состояний... E>Множество оно описывает верно. E>Вопрос в том, можно ли его эффективно интерпретировать? Очевидно, что да, можно. Так и в чём таки проблема?
Можно ли записать это решение для любого числа буков?
Здравствуйте, PC_2, Вы писали:
PC_>Взять классическую иерархию фигур и представить в виде ООП
1) Выделенного не существует. Фигуры не образуют иерархии. Разве что бывают там представители многоугольников если.
2) ООП подразумевает какую-то задачу, которую мы хотим решить. Без задачи нет смысла строить иерархию...
PC_>Я-то с тобой согласен, что на счет фигур лучше обойтись массивами фигур,
Только не фигур, а вершин.
PC_>но только из-за того что на таком примитивном примере недостатки ООП довольно хорошо просматриваются
У ООП есть недостатки. Один из них -- это то, что хотя ООП пытается приблизить понятия программы к понятиям предметной области, но в реале люди нифига не думают истинно-ООП-шным способом. Так что приблизить не получается. Получаются уродские иерархии.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
E>В идеологии RS было бы логично уметь оперировать понятием "позиция переборщика". И для переборщиков, с заданной последовательностью было бы удобно отрезки выделять и на димк можно было бы позицию записать, и НИЧЕГО не пропускать вообще...
Позиция такого переборщика — это срез по всем счетчикам, сколько бы их не было, со всеми состояниями массивов. Ты говоришь о 'хибернейте' интерпретатора, видимо.
Здравствуйте, samius, Вы писали:
PC_>>Вообщето скип, это почти тот же фильтр результата. S>Ты даже не понял, что результаты по скипу не вычисляются? Ты походу слил, но сам еще не понял это.
Скипать результаты не проблема в РС.
Но ты как единственный любитель преждевременных оптимизаций тут должен был уже понять,
что программе на Си, например, было бы абсолютно по барабану начинать свои счетчики
с 10 со 100 тыс или с 1 миллиарда. Чего не скажешь о твоем "прогрессивном" решении
со скипом, которые по твоей алгоритмической сложности эквивалент РС.
Что не скажешь о твоем решении.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Здравствуйте, samius, Вы писали:
S>Я думал что ты записал решение общего случая, а оказалось что 3 из n. Да, может и во внешних. Но продолжишь ли ты его по индукции до k из n?
Ну тут есть вопрос, как это сделать понятно и удобно для интерпретации.
E>>C+(C!=D?D)+(E!=C && E!=D ?E) -- переборщик конкатенаций этих троек букв... S>Круто. Запишешь для четверок и пятерок?
А в чём проблема:
Вот для чётвёрок, например:
C+(C!=D?D)+(E!=C && E!=D ?E)+(F!=C && F!=D && F!= E ?F)
Струтктура выражения, как раз легко обощается на сколько хочешь букв.
Проблема тут совсем другого рода. Как удобно и понятно выражать факт связанности каких-о переборщиков в разных частях выражения. Ну типа, что вот это-вот -- это текущая позиция вон-того-вот переборщика из той части...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, samius, Вы писали:
E>>>Это описан переборщик по кубу без повторов. S>>Т.е. тройной цикл.
E>перебор размещения троек, хотя бы из четырёх -- это всегда тройной цикл, так в итерируется трёхмерное многообразие трёхмерное... S>>Это лишь решение частной задачи. Если обобщить, то сложность решения увеличивается в O(N) раз на каждую дополнительную букву. O(C^N), грустно.
E>Это не правда. Ты можешь отсекать перебор по каждой из осей, а не в самом низу...
Это правда для той записи что ты показывал. Каждое отсечение — это if, который нужно вычислить. В твоей записи отсечения небесплатны.
E>Сложность будет O(число размещений)...
А в моей как раз так и отсекается.
Здравствуйте, Erop, Вы писали:
AV>>Не, то что это можно будет сделать я вполне верю. То что будет сделано — не верю. Может быть какой-нибудь один частынй случай. Но не более.
E>Казалось бы, для всех простых случаев всё просто, для комбинаций где-то просто, а где не просто, там полиморфизм. А где совсем не, там массивы.
Если ты не заметил, то я не подвергаю сомнению то, что это можно сделать. А вот в то, что в RS появится нечто отличное от пары частных случаев, я не верю
Здравствуйте, Erop, Вы писали:
AV>>Тогда ты скорее всего получишь язык для решения одного-двух типов языков.
E>Ну цель стоит ясная. Написать легко и просто шахматы, потом шашки, потом каллах и т. д...
Ух-ты, а в топике пару раз проскакивало про то, что это язык общего назначения.
Здравствуйте, alpha21264, Вы писали:
A>Бывает бывает. A>Например индусы искали пересечение двух отрезков. A>был switch на 8*8=64 ориентации. A>В двух местах они ошиблись.
Не, с тем, что бывают клинические случаи я не спорю.
Здравствуйте, Erop, Вы писали:
AV>>Тебе интересно обсудить именно RS или все таки тензоры и иже с ними? Если второе, то гораздо более продуктивно будет это делать в отдельном топике. И при этом сначала стоит обратить внимание на уже существующие наработки. Те, которые ТС с самого начала назвал говнокодом. E>А я вот не знаю ничего такого же выразительного.
Всякие там J и компания повыразительнее будут.
AV>>Вот только ценность может меняться в связи с особенностями изложения. E>Ценность мыслей нет. Доступность -- да.
Абстрактная ценность — да. Реальная? Вряд ли.
AV>>Да, оно больше деструктивное. Это так ужасно? А насчет "извращения", то как иначе назвать то, что предложил ТС? В теории быть может все это и красиво. Но то, что есть на практике иначе я назвать не могу. E>Что именно тебе кажется неприменимым?
Здравствуйте, PC_2, Вы писали:
PC_>>>Я предлагаю вместо головастости взять ряд архитектурных задач на себя, проект Опен Сорц.
AV>>Видишь ли в чем проблема. Может я бы и взялся. Но для этого мне надо понять зачем мне это нужно. Пока что я не вижу никакой ценности данного языка. Даже позволю себе несколько более жесткое заявление. Считаю именно эту работу (а не весь Open Source) бессмысленной тратой времени. И еще вижу кучу достаточно плотно расположенных граблей.
PC_>тогда просто не мешай другим. PC_>Потому что в этом языке ты самая главная грабля и на тебя больше времени уходит PC_>чем на кодинг
Действительно? Вот уж не думал, что смогу быть главной проблемой
Здравствуйте, PC_2, Вы писали:
AV>>Это образец понятности? А то я, например, ничего не понял. Что значит "SR", что значит "a"?
PC_>это вообще стеб над перлом был. PC_>Потому что глупо было както несколько страниц сравнивать вызов библиотечной функции в перле PC_>и не вызов а сам алгоритм сортировки в РС, пришлось обломать перл в его же стиле
Сомневаюсь, что ты кого-то там обломал. Потому что, похоже, ты единственный здесь, кому важно 5 или 8 символов надо ввести. Да и это все ты показываешь на маленьких кусочках кода. А совсем не факт, что эта же картина будет наблюдаться на больших объемах
