Представление объекта в программировании. - страница 17

Новый комментарий
 
transcendreamer #:

72 падежа, 24 новых падежа особого назначения, нелинейная система письма, матричная грамматика, морфосинтаксис, бустрофедон, еще и фонетика специальная — то что нужно для самых крутых трейдерских сект (чтобы чекисты и масоны Грааль не смогли украть).

Да, надо обязательно перевести на ифкуиль выражение "пересечение двух скользящих средних")

 

Ввиду того, что тематика этого топика в большой степени философская и не укладывается не только в границы алготрейдинга, но и (в некоторых местах) программирования в целом, я принял решение завершить написание серии частей концепции одной финальной теорией "алгоритма усложнения", изложив в общих чертах его понимание и по своему ответить на вопрос - может ли такой алгоритм существовать в принципе? 

Как намечалось, рассматривать "механизм усложнения" будем на примере простой прямоугольной метки на пиксельном экране, рисуемой вызовом одной графической функции состоящей из двух вложенных циклов (по высоте и ширине) и использующей 5 основных параметров - x, y, width, height, color. 

Рисующую функцию будем называть "конструктором", а ее параметрический набор - Объектом. Нужно отметить, что в обывательском восприятии Объектом принято считать выделенное цветом и собранное в геометрическую форму пиксельное "подмножество" находящееся внутри общего пиксельного множества экрана, но для программиста, - Объект не только внешняя, воспринимаемая на глаз форма, но и сам создающий механизм. Метка, как мы знаем, "строится" в процессе двух циклов рисующей функцией, а значит, функция со своими параметрами тоже "Метка".   Не цветной прямоугольник, а алгоритм с параметрами который ее рисует.  Этот момент сложно осознать, поскольку человек привык к зрительному восприятию оболочки объекта и рассматривает код который за ним стоит как нечто надуманное и вторичное, однако - это сам Объект и есть, ведь в случае каких либо изменений реализации исходной функции или значений ее параметров неизбежно следует внешнее изменение оболочки.  

Мне проще отделить параметрический набор функции от ее внутренней реализации и рассматривать его как основной Объект, хотя конечно это не верно, ведь внутренняя реализация функции-конструктора и ее параметрический набор неразрывно взаимосвязаны. Однако, внутренняя реализация меняется значительно реже и эти изменения фундаментальнее, чем скажем, изменения значений параметрического набора, с которыми легко работать и экспериментировать. Если меняется метод реализации функции-конструктора, то возникает новый параметрический набор, а это влечет изменения всех "прото-блоков" построенный на базе прежнего параметрического набора функции-конструктора. Т.е. если мы сначала собрали альтернативное состояние Метки из 5-ти параметров: x, y, width, height, color вписав в них иные значения и далее, "включаем" его в момент какого то события, то неожиданное изменение метода реализации функции-конструктора, суживающее количество параметров, скажем до 3-ёх, переиначит структуру первичного параметрического набора (от которого возможно уже созданы другие состояния, события, процессы), и прежняя конструкция альтернативного состояния Метки "рухнет" став бесполезной для нового варианта функции-конструктора. Здесь мы упираемся в первое основное препятствие реализации алгоритма усложнения:   Метод реализации функции-конструктора устанавливает границы потенциала усложнения Объекта. Преодоление этих границ без участия человека по некому алгоритму и есть автоматизированное усложнение.

Рассмотрим экспериментальное "прямолинейное" усложнение Метки без изменения исходного метода реализации ее функции-конструктора и не вдаваясь в смысл усложнения - будем менять только значения ее параметрического набора и "отпочковывать" на его основе новые состояния и посмотрим к чему придем:

  • Выбираем набор параметров для нового Состояния из исходного набора параметров функции-конструктора, придумываем для них новые значения и записываем в выделенный блок памяти.
  • Получая в наличие всего одно дополнительное состояние Метки мы автоматически сталкиваемся с необходимостью построения Событийной Модели, ведь если у Метки есть хотя бы ОДНО, кроме исходного, состояние, она должна в какой то момент на него переключаться, а следовательно, требуется описать некое событие связанное с внешней средой или другим объектом, при котором Метка примет альтернативное состояние. Т.е. Одно ново-добавленное состояние логически влечет необходимость в описании как минимум одного события для переключения на альтернативное состояние и (опционально) описание второго события для переключения обратно на исходное или какое то другое состояние. 
  • Отсюда простой тезис: Прибавление каждого нового состояния Объекту влечет добавление как минимум одного, а лучше двух новых событий, описание которых должно помещаться в условия Событийной Модели, которая, как мы знаем, вроде "коммуникационный механизм" Объекта и Среды и своей логикой описывает их взаимодействие. Априори, только наличие СМ может переключать Объект между состояниями. Вывод: + 1 Состояние Объекта = +2 События Объекта или окружения + 2 условия СМ.
  • Добавление Состояний Объекту влечет добавление Событий смены этих состояний и возникает необходимость упорядочивания новых Событий в приоритетном порядке и лучше всего для этого подходит структура иерархии. Одновременно с появлением новых Событий и Состояний растет дерево условий. Поведение Объекта обогащается разнообразием реакций на внешние взаимодействия с "вовлеченными" в его жизнь вещами и надо сказать, что чем дальше идет усложнение, тем шире внешний контакт. Получается, мы не можем рассмотреть усложнение Метки в отрыве от ее Среды и нам необходимо наличие окружения взаимодействия, иначе новые состояния лягут в памяти "мертвым грузом" и единственным возможным событием их смены станет внутренний таймер.
  • Мы выяснили, что возникновение новых состояний Объекта без событий их смены, неразрывно связующих их с объектами окружающей Среды не имеет смысла, также как добавление событий вне Событийной Модели связующей их с состояними и процессами Объекта не имеет смысла.  В процессе усложнения Объекта необходимо добавлять все сразу - и Состояния, и События, и условия Событийной Модели (одновременно организуя ее в иерархическом порядке) и устанавливать свзязи Событие->Состояние или... Событие->Процесс и т.д.
  • Добавление Процесса Объекта, ничем принципиально не отличается от добавления Состояния и разница только в объеме выделяемой памяти. Новый процесс, как и состояние, требует определения для себя базовых событий, как например: start-события, switch-события, stop-события...


Заключение:

Безусловно, для раскрытия этой темы потребовалось бы написать не одну книгу и одного поста явно не хватит, но уже сейчас очевидно что если определить цель усложнения некой программе, чтобы та создавала модели Объекта с различными Состояниями, Событиями, реакциями на окружение, даже не меняя реализацию функции-конструктора и опираясь на неизменный параметрический набор, возможно, через n-ое количество проб и ошибок, она могла бы создать метку выполняющую какую то простую задачу, но такая программа должна "уметь" строить "прото-блоки" - состояния, события, процессы, условия и их иерархии, должна их связывать между собой и подбирать значения параметров с помощью генетической оптимизации. Я настроен оптимистично, хотя и представляю сложность подобной задачи. 

 
Привет всем есть советник надо дороботки есть кто хорошо шарит шас тестирую в день около 100$ на паре eurusd и usdchf
 
Ruslan #:
Привет всем есть советник надо дороботки есть кто хорошо шарит шас тестирую в день около 100$ на паре eurusd и usdchf

сольёт..

объекты в нём неверно представлены :-)

PS/ гарантированно сольёт, вне зависимости от объектов

 
привет ребята помогите пожалуиста исправить эту ошибу ;expressions are not allowed on a global scope          strategy("DailyCandleCross", shorttitle="DCC", overlay=true, calc_on_order_fills= true, calc_on_every_tick=true, default_qty_type=strategy.percent_of_equity, default_qty_value=75, pyramiding=0)
 
Хочу разоблачить собственные и чужие (если их появлению невольно поспособствовал) иллюзии относительно т.н. "алгоритма усложнения" и вернуть увлекшихся читателей в суровую реальность, где само мироздание отрицает любые формы и вариации "Грааля" и показать, что мои рассуждения - порождение воспаленного любовью к философии ума, что бессонными ночами изобретает "вечный двигатель" или "машину времени" мучаясь верой в собственную гениальность. 
Алгоритм усложнения не может быть реализован, или точнее сказать, может быть реализована его "глупая" версия, где некая программа в случайном порядке штампует параметрические состояния, события, процессы и условия некого обьекта, далее, в таком же рандоме компанует их между собой и... стирает и начинает снова. Это странное действие может длиться бесконечно и совершенно непонятно какова его цель? Что в итоге? Случайный результат? И помните проблему с функцией-конструктором? Как менять ее реализацию? Совершенно непонятно... Проблема в том, что малейшее изменение метода реализации полностью уничтожает "легитимность" структур всех прото-блоков, делая их негодными для использования измененной функцией. В общем, эта задача на годы, при условии что ее будет решать НИИ или АН и не факт, что в итоге что то получится. 
Атмосфера этого форума пропитана граальным вдохновением и навевает соответствующие настроения ума, отчего последний порождает удивительные, наукообразные притчуды, которые, к сожалению, никогда и ни к чему практическому не приводят, хотя... здорово заряжают всех энергетикой. :)
Не судите строго, я просто был в "философском ударе".)))
 
Блин, опять обострение? Только всё затихло
 
Реter Konow #:
Хочу разоблачить собственные и чужие (если их появлению невольно поспособствовал) иллюзии относительно т.н. "алгоритма усложнения" и вернуть увлекшихся читателей в суровую реальность, где само мироздание отрицает любые формы и вариации "Грааля" и показать, что мои рассуждения - порождение воспаленного любовью к философии ума, что бессонными ночами изобретает "вечный двигатель" или "машину времени" мучаясь верой в собственную гениальность. 
Алгоритм усложнения не может быть реализован, или точнее сказать, может быть реализована его "глупая" версия, где некая программа в случайном порядке штампует параметрические состояния, события, процессы и условия некого обьекта, далее, в таком же рандоме компанует их между собой и... стирает и начинает снова. Это странное действие может длиться бесконечно и совершенно непонятно какова его цель? Что в итоге? Случайный результат? И помните проблему с функцией-конструктором? Как менять ее реализацию? Совершенно непонятно... Проблема в том, что малейшее изменение метода реализации полностью уничтожает "легитимность" структур всех прото-блоков, делая их негодными для использования измененной функцией. В общем, эта задача на годы, при условии что ее будет решать НИИ или АН и не факт, что в итоге что то получится. 
Атмосфера этого форума пропитана граальным вдохновением и навевает соответствующие настроения ума, отчего последний порождает удивительные, наукообразные притчуды, которые, к сожалению, никогда и ни к чему практическому не приводят, хотя... здорово заряжают всех энергетикой. :)
Не судите строго, я просто был в "философском ударе".)))

Если вдруг окажетесь в познавательном настроении ума, то почитайте про генетическое программирование (спойлер: без Бэкуса-Наура обойтись не получится).

1...1011121314151617
Новый комментарий
Причина обращения: