Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
72 падежа, 24 новых падежа особого назначения, нелинейная система письма, матричная грамматика, морфосинтаксис, бустрофедон, еще и фонетика специальная — то что нужно для самых крутых трейдерских сект (чтобы чекисты и масоны Грааль не смогли украть).
Да, надо обязательно перевести на ифкуиль выражение "пересечение двух скользящих средних")
Ввиду того, что тематика этого топика в большой степени философская и не укладывается не только в границы алготрейдинга, но и (в некоторых местах) программирования в целом, я принял решение завершить написание серии частей концепции одной финальной теорией "алгоритма усложнения", изложив в общих чертах его понимание и по своему ответить на вопрос - может ли такой алгоритм существовать в принципе?
Как намечалось, рассматривать "механизм усложнения" будем на примере простой прямоугольной метки на пиксельном экране, рисуемой вызовом одной графической функции состоящей из двух вложенных циклов (по высоте и ширине) и использующей 5 основных параметров - x, y, width, height, color.
Рисующую функцию будем называть "конструктором", а ее параметрический набор - Объектом. Нужно отметить, что в обывательском восприятии Объектом принято считать выделенное цветом и собранное в геометрическую форму пиксельное "подмножество" находящееся внутри общего пиксельного множества экрана, но для программиста, - Объект не только внешняя, воспринимаемая на глаз форма, но и сам создающий механизм. Метка, как мы знаем, "строится" в процессе двух циклов рисующей функцией, а значит, функция со своими параметрами тоже "Метка". Не цветной прямоугольник, а алгоритм с параметрами который ее рисует. Этот момент сложно осознать, поскольку человек привык к зрительному восприятию оболочки объекта и рассматривает код который за ним стоит как нечто надуманное и вторичное, однако - это сам Объект и есть, ведь в случае каких либо изменений реализации исходной функции или значений ее параметров неизбежно следует внешнее изменение оболочки.
Мне проще отделить параметрический набор функции от ее внутренней реализации и рассматривать его как основной Объект, хотя конечно это не верно, ведь внутренняя реализация функции-конструктора и ее параметрический набор неразрывно взаимосвязаны. Однако, внутренняя реализация меняется значительно реже и эти изменения фундаментальнее, чем скажем, изменения значений параметрического набора, с которыми легко работать и экспериментировать. Если меняется метод реализации функции-конструктора, то возникает новый параметрический набор, а это влечет изменения всех "прото-блоков" построенный на базе прежнего параметрического набора функции-конструктора. Т.е. если мы сначала собрали альтернативное состояние Метки из 5-ти параметров: x, y, width, height, color вписав в них иные значения и далее, "включаем" его в момент какого то события, то неожиданное изменение метода реализации функции-конструктора, суживающее количество параметров, скажем до 3-ёх, переиначит структуру первичного параметрического набора (от которого возможно уже созданы другие состояния, события, процессы), и прежняя конструкция альтернативного состояния Метки "рухнет" став бесполезной для нового варианта функции-конструктора. Здесь мы упираемся в первое основное препятствие реализации алгоритма усложнения: Метод реализации функции-конструктора устанавливает границы потенциала усложнения Объекта. Преодоление этих границ без участия человека по некому алгоритму и есть автоматизированное усложнение.
Рассмотрим экспериментальное "прямолинейное" усложнение Метки без изменения исходного метода реализации ее функции-конструктора и не вдаваясь в смысл усложнения - будем менять только значения ее параметрического набора и "отпочковывать" на его основе новые состояния и посмотрим к чему придем:
Заключение:
Безусловно, для раскрытия этой темы потребовалось бы написать не одну книгу и одного поста явно не хватит, но уже сейчас очевидно что если определить цель усложнения некой программе, чтобы та создавала модели Объекта с различными Состояниями, Событиями, реакциями на окружение, даже не меняя реализацию функции-конструктора и опираясь на неизменный параметрический набор, возможно, через n-ое количество проб и ошибок, она могла бы создать метку выполняющую какую то простую задачу, но такая программа должна "уметь" строить "прото-блоки" - состояния, события, процессы, условия и их иерархии, должна их связывать между собой и подбирать значения параметров с помощью генетической оптимизации. Я настроен оптимистично, хотя и представляю сложность подобной задачи.
Привет всем есть советник надо дороботки есть кто хорошо шарит шас тестирую в день около 100$ на паре eurusd и usdchf
сольёт..
объекты в нём неверно представлены :-)
PS/ гарантированно сольёт, вне зависимости от объектов
Хочу разоблачить собственные и чужие (если их появлению невольно поспособствовал) иллюзии относительно т.н. "алгоритма усложнения" и вернуть увлекшихся читателей в суровую реальность, где само мироздание отрицает любые формы и вариации "Грааля" и показать, что мои рассуждения - порождение воспаленного любовью к философии ума, что бессонными ночами изобретает "вечный двигатель" или "машину времени" мучаясь верой в собственную гениальность.
Если вдруг окажетесь в познавательном настроении ума, то почитайте про генетическое программирование (спойлер: без Бэкуса-Наура обойтись не получится).