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

 

И так, Объект. (Будем банальными и возьмем все ту же Прямоугольную Метку.)

1. Базовые Состовляющие Объекта:

Все мы знаем эти состовляющие и нет смысла строить из этого интригу. Любой, более-менее сложный объект имеет:

  • Параметры - самая базовая группа состовляющих, но отнюдь не простая. На мой взгляд, наиболее доступное объяснение Параметра, - сущность представляющая некое именованное множество или величину в структуре системы или среды. Параметр сжато передает множество через свое число и входит в состав функций-конструкторов воспроизводящей эти структуры. Хотя это и не единственный тип параметра, но остановимся пока на нем.
  • Набор свойств - комплекс параметров объединяющий "объекто-метрические" данные используемые разными функциями - т.е. ключевые величины и составные структурные множества Объекта. Взятая в пример Метка, имеет 5 параметров - х,y, (положение в пространстве), width, height (ширина и высота), color (цвет), т.е. набор ее исходных свойств начинается, но не ограничивается входными параметрами (аргументами) воспроизводящей ее функции.
  • Функцию - конструктор  - набор действий (он же алгоритм) воспроизводящий объект. Функция рисующая Метку использует все вышеперечисленные параметры в процессе своего исполнения. (Замечу, что базовый набор параметров Метки определяется методом реализации функции-конструктора. Если изменить метод рисования Метки (например, рисовать ее одним циклом, а не двумя), то изменится и исходный набор параметров Метки).
  • Форму - трудно отрицать, что все приходящие на ум примеры объектов имеют форму. У Метки форма примитивна проста, но она ее неотъемлимая часть. Однако, существуют объекты не имеющие Формы и потому она не является обязательной состовляющей Объекта. Форма играет важную часть в "жизнедеятельности" и может передавать через себя поток информации - как события, процессы, состояния, тенденции и т.д.
  • Состояния - значимые "точки останова" в бытии Объекта. Говоря кодерским языком - значения параметров объекта к которым он переходит при изменении условий внешней Среды или в процессе независимого исполнения внутренней программы. Присутствуют у любых, даже минимально сложных систем. Этот атрибут превращает простую Метку в систему и требует от нас формализовать логику переходов набором дополнительных условий. При этом, набор параметров Метки попрежнему может оставаться примитивно прост, но добавление Состояний увеличивает количество возможных значений параметров, заставляя выделять под них дополнительную память, а Метка меняет статус примитивно простого объекта на функциональную систему, поскольку помимо своего конструктора она обрела дополнительную функцию смены состоянийСостояния присущи более сложным объектам из которых состоят различные системы.
  • События - атрибут Объекта еще более высокого уровня сложности. Обладая лишь состояниями, Объект (Метка) может напоминать незамысловатый часовой механизм, меняющий значения параметров своей функции-конструктора в заданной последовательности и вся ее "жизнедеятельность" ограничивается одной цепочкой предустановленных состояний, однако добавление Событий разрывает эту цепочку и внедряет новые последовательности переходов, окончательно интегрируя в Метку (объект) более сложную систему поведения или взаимодействия с окружающей объектной Средой. Однако об этом позже, а сейчас перейдем к определению События и его программной реализации.  

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

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

         Процессы объединяют Состояния и События Объекта в последовательности, которые можно представить как "цепочки" или "серии" значений выбранного набора параметров Объекта упорядоченных в определенном направлении. Наилучшей аналогией будет числовой ряд, где значения в ячейках обуславливаются Процессом, который может быть либо случайным, либо спланированным. Однако, сам Процесс состоит из множества таких числовых рядов, где каждый приписан какому либо параметру. Создать Процесс не сложно - нужно всего лишь взять исходный набор параметров (например функции-конструктора) и породить (или получить) серии значений для каждого из них. Также легко разложить Процесс на Состояния, События и Переходы (transitions) между ними. Их можно дробить на части и строить иерархии, связывая части произвольными или предустановленными последовательностями. Важно, что на каждом этапе Процесс можно "разобрать" на состовляющие или собрать его из них. Процессы можно моделировать, оптимизировать и модифицировать. Процессы присутствуют как в составе самих объектов, так и в объектной Среде. В этом случае, Среда выступает как "Мета-Объект".

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

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

В третьей части от философских формулировок перейду к вопросам новой реализации программных Объектов и к коду (хотя это будет не просто).

 
Реter Konow #:

Очень интересные вопросы Вы ставите. 

1. Бесспорно, что наша речь (или любая иная форма изложения мысли) является физически линейной, т.к. разворачивается во времени, однако, Мышление имеет не только физическое, но и логическое измерение ,и с точки зрения своей логики может быть как линейным, так и диалектическим. Ну например, тот факт что я целенаправленно пошел назад к истокам ООП (в то время как человечество в массе линейно уходит дальше), является примером логической нелинейности мышления, а линейность, о которой Вы говорите, лишь общепринятый порядок. Мысль все время нарушает его, ходя "вперед-назад". Просто попробуйте доказать теорему не делая шаги назад и не переосмысливая свои действия сначала.) 

Согласен, что человек может за счет интуиции и эрудиции перепрыгивать с одной логической ветки на другую, не как формальные системы доказательств ATP SPASS/HOL/NuPRL/etc, но даже такие прыжки "вперед-назад" являются линейными и (теоретически) алгоритмизируемы, например если представить что можно делать псевдорандомные предположения в каких-то рамках и снова их доказывать формально.

Можно вспомнить принцип де Брейна: система строится из 2 частей - компактного формального логического ядра-верификатора - делает то что делают все ATP, а рядом с ним сколько угодно большое нечто способное цеплять экзогенные данные (интуиция, шаманские песни, посты с форума mql5...)

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

Возможно, нужен не только недетерминированный потенциально-бесконечный автомат, но и автомат способный выполнять одновременно множество асинхронных операций.

А в качестве прикола можно вспомнить проект MathGen для генерации случайных математических текстов: https://thatsmathematics.com/mathgen/


2. Согласен с теорией ограниченности человеческой способности понимать и воспринимать Мир. Не так сложно найти свои пределы. Например, человек не может охватывать и обрабатывать большие множества, не может предсказывать динамичный хаос с высокой энтропией и так далее... Но, насколько ему это нужно? Человек создает технологии, которые успешно расширяют его возможности "охватывать экзистенцию своими универсалиями". Кант, вроде, ничего не сказал про это.) 

Нет предела совершенствованию, но математика может ударить с неожиданной стороны, к примеру вот Вы создаете модель мета-объектов, и в какой-то момент допустим (лет этак через 50 упорного труда, хехе) потребовалось сделать self-verifying automata, а тут выскакивает Гёдель и говорит: - а вот фигушки! - в любой формальной аксиоматической системе с предикатами выше второго уровня [если я не ошибаюсь] всегда найдутся формально верные, но не-доказуемые и не-опровергаемые утверждения, и что делать? - снова на завод идти?

Интересно, что некоторые проекты в криптовалютной сфере утверждают что они добились полноты по Тьюрингу, и даже тут может быть они лукавят, чисто такой маркетинговый ход, платформа Эфир в частности заявлена как Тьюринг-полная, а Биткойн например наоборот заведомо by design неполный по Тьюрингу, но на самом деле проверял ли это кто-либо, вот в чём вопрос, и до каких пределов это справедливо...


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

Добавлю, что концепция строилась максимально ориентированно на программирование, ведь конечная цель - создание нового ИИ-движка, так что все объяснения и примеры будут кодерские.

Гиперобъекты я использовал вслед за Тимоти Мортоном, в его трактовке, это такие объекты, которые столь массово распределены во времени и пространстве и которые выходят за пределы конкретной локализации, и тут интересно отметить, что это та сфера, где математика и технические науки начинают соприкасаться с искусством, мифом и магией... конфиденты прекрасно знают например о понятии гипер-сигилы в запретных ритуалах хаос-магии, это способ комплексного влияния на реальность, хотя то что публикуют на эту тему обычно окутано плотной завесой самого чёрного мракобесия и зловещего сатанизма, но если отбросить это, то останется принцип комплексного воздействия в том числе информационного воздействия на объект/субъект который способен эту информацию воспринять, что-то подобное как в гибридной войне в современной геополитике или децентрализованных протестов, а мета-объектом наверное можно считать обобщение гипер-объекта до уровня нелокального внетемпорального но всё же идентифицируемого процесса, практически что-то типа архетипа.

 
Как я вчера и говорил будет мусолить эту тему опять, начал в 19-м , сейчас опять засвербило
 
Реter Konow #:

И так, Объект.

Записывайте сразу в форме Бэкуса-Наура. Можно будет проверить на непротиворечивость и изоморфность уже существующим вариантам.

 

Это всё очень важно для трейдинга!

Долой засилье контекстно-зависимых формальных грамматик!

 
Aleksey Nikolayev #:

Записывайте сразу в форме Бэкуса-Наура. Можно будет проверить на непротиворечивость и изоморфность уже существующим вариантам.

Покажите пример, пожалуйста. 

 
transcendreamer #:

Это всё очень важно для трейдинга!

Долой засилье контекстно-зависимых формальных грамматик!

Думаю, цены можно представить как контекстно-зависимую стохастическую грамматику) Волновикам могло бы подойти)

 
Aleksey Nikolayev #:

Думаю, цены можно представить как контекстно-зависимую стохастическую грамматику) Волновикам могло бы подойти)

Эм... наверное тогда последовательности волн с вероятностными правилами типа: если была такая-то наблюдаемая последовательность термов/сигнатур WXYZ, то далее возможно АВС, АСВ, ВАС, ВСА, САВ, СВА с некоторыми вероятностями, вектор которых укажет на Грааль в вероятностном пространстве. 😁

 
Aleksey Nikolayev #:

Думаю, цены можно представить как контекстно-зависимую стохастическую грамматику) Волновикам могло бы подойти)

Но вообще это же в основе марковская модель, что заведомо не учитывает зависимость от рыночной предыстории?

 
Реter Konow #:

Покажите пример, пожалуйста. 

Целые числа и список из целых чисел через запятую (список может быть пустым)

<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

<integer> ::= <digit>|<integer><digit>

<list> ::= <""> | <integer> <","> <list>

Причина обращения: