Комментарии 35
Вы бы хоть предметную область ваших графов описали..
А то граф - это толи картинка, толи муж графини.. Операции возможны и там и там..
Предположу: граф-процессы? сети Петри? Конечные автоматы?
Поздравляю, вы изобрели конечные автоматы
Можете дать ссылку где всЁ могло быть переменной, включая F?
Ссылку не дам, так как не совсем до конца понимаю, о чем идет речь (что есть F в вашей терминологии?) :) Однако конечные автоматы описываются конечным набором параметров - таких как функция перехода, множество допустимых состояний и т. д., и при определённом желании можно все их сделать переменными. Или например управлять одним конечным автоматом из другого.
F:X->Y ... о смысле F, где это F может быть переменной со своими значениями. Да, конечно автоматы. .... Были ли похожие реализации? Скорее всего да. ... В обобщенном виде не встречал. Ссылок вот Вы тоже не видели. ... Что дает? То, что избавившись от конкретики (того же телефонного автомата) можно работать с этой тройкой ... и выяснять что из них что: что F, что X, что Y (не зная заранее)
Например
F | P U V
H | U U V
Вот смотря в код - у вас по факту два бесконечных автомата, состояние первого описывается выражением time1 % 3, второго - time2 % 2, соответственно когда первый автомат находится в третьем состоянии - он дает команду второму перейти в следующее состояние.
Все верно. Просто демонстрация для наглядности. ... Но автомат нижний не меняет состояния верхнего. С в нем остается С. Но при желании его можно трактовать и как смену R, W. (о монете можно сказать: монета, монета в состоянии решка, в состоянии орел) И то, и то верно... Такая логика применима к всему, включая F, E (в этой демонстрации). ... Соль не в этих конкретностях. Основное же - все есть переменная, сам подход (появляются иные возможности)
Вот допустим в своих шарпах я объявлю интерфейс провайдера значений, который возвращает произвольное значение (упрощенно, для наглядности):
interface IValueProvider<TValue>
{
TValue Get();
}
Затем определим пару реализаций:
class First : IValueProvider<FirstState>
{
private FirstState _state = default;
public enum FirstState { A, B, C }
public void MoveNext()
{
_state = _state switch
{
FirstState.A => FirstState.B,
FirstState.B => FirstState.C,
FirstState.C => FirstState.A,
}
}
public FirstState Get()
{
return _state;
}
}
class Second : IValueProvider<SecondState>
{
private readonly IValueProvider<First.FirstState> _sourceStateProvider;
private SecondState _state = default;
public enum SecondState { R, W }
public Second(IValueProvider<First.FirstState> sourceStateProvider)
{
_sourceStateProvider = sourceStateProvider;
}
public void MoveNext()
{
var sourceState = _sourceStateProvider.Get();
if (sourceState != First.FirstState.C)
{
return;
}
_state = _state switch
{
SecondState.R => SecondState.W,
SecondState.W => SecondState.R,
}
}
public SecondState Get()
{
return _state;
}
}
Конечно придётся руками вызывать MoveNext для обоих классов, это легко обойти путем введения интерфейса по типу IValueChangedProvider. Используем наши классы:
var first = new First();
var second = new Second(first);
for (var i = 0; i < 1000; i++)
{
first.MoveNext();
second.MoveNext();
Console.WriteLine("#{0} Step. First value - {1}, second value - {2}", i, first.Get(), second.Get());
}
Вот если бы что-то такое было в статье, а не какой-то код рисующий два объекта, перемещающихся по строго заданной траектории, было бы гораздо проще. И согласитесь, графы тут совершенно ни при чем - можно нарисовать какие-то графы для этого кода, но нет никакой необходимости в графах, чтобы реализовать то, о чем вы говорите.
Не согласен. Вы мыслите как программист. ... Но в этой (очень короткой и наглядной) я больше о логике. .... Представьте мир, в котором вы видите только поток данных (см. здесь рис.3). Как в в таком мире узреть объекты, которые ... и влияют друг на друга, и могут являться частями друг друга? Повторюсь, данная статья в картинках (детская, можно сказать), но я хотел в ней показать саму парадигму, иначе взглянуть на происходящее, а именно: 1) что все есть переменная 2)что базовые вещи: быть, не-быть 3) и что фазовое пространство представимо именно графом.
Тут на самом деле неважно, как выполняется реализация. Это можно было сделать по ФП-шному, в процедурном стиле или ещё как-то - по крайней мере, это наглядный и доступный пример, взглянув на который сразу понятно, что происходит. ООП в данной ситуации - абстракция над потоками данных (как ни крути, а если хочется с этими потоками работать - какую-никакую абстракцию делать придётся). Собственно недопонимание у меня потому что:
все есть переменная
Это утверждение никак не связано с графами, как две произвольные прямые в пространстве - иногда они параллельные, иногда пересекаются, а иногда - скрещиваются.
базовые вещи: быть, не-быть
Наверное мне не достаёт контекста, вообще не понимаю о чем речь, и главное - при чем тут графы в первую очередь
фазовое пространство представимо именно графом
У меня к сожалению очень скудные знания на тему фазовых пространств, вы постулируете это утверждение и допустим я согласен. Что нам это дает, и как это связано с первоначальной мыслью о том, что все - переменная?
Единичный переход: F:X->Y
Из Х следует Y, при действии F (вершина-состояние, стрелка-действие, вершина-следующая )
И строим граф любой сложности. Причем это может делать сам алгоритм
P>S. причем F,Х,Y сами могут быть графами, если взглянуть внутрь них
1) Y=F(X) простейший ориентированный граф: 2 вершины (Х, Y) и ориентированное ребро (F). 2) Каждое из них, в свою очередь, может быть тоже Y=F(X).
фазовое пространство Теперь представьте, что каждая точка его - это другое фазовое пространство, как и фазовое пространство - любая стрелка (очень маленькая на рис), и траектории которых получаются из (очень маленьких стрелок)
ЗЫ. Обычно такие вещи описываются диф. уравнениями. Если рассматривать только 0,1 ... а именно о них идет речь, все эти совокупности изменения (представляющей точки) описаны таблицами в состояниях (вырожденный случай количественных отношения в пределах лишь 0,1)
Да я понимаю, учился в университете на технической специальности, и всё это у нас было (правда давненько уже). Непонятно чего мы хотим добиться - ну можем сделать абстракцию над значением, позволяющую добавлять логику любой сложности так, чтобы снаружи это выглядело как просто значение - это классная мысль, но не новость, в ООП называется инкапсуляция такой подход. Можем воспользоваться формальной логикой для описания предметной области - эта идея тоже в целом не нова. Ну можем описать фазовое пространство графами, чего мы можем добиться теперь?
Спрошу в ответ: можете дать ссылку, где было бы показано ... как из потока данных понять ... что считать объектами и как эти объекты влияют друг на друга? ... Только не приводите конкретные примеры (лампа, стол, ...), нужно именно абстрактное решение
Справедливости ради у вас не абстрактное решение - а отрисовка двух объектов, которые двигаются по строго заданным траекториям. Вы хотите сказать, что граф сам себя построит и проанализирует любые потоки данных?) В любом случае придётся создавать абстракцию для таких задач. А как вы говорите, это больше на нейросети похоже
Ну все равно у вас по сути там набор конечных автоматов, которые кто-то должен описать и соединить между собой прежде всего и наполнить данными, анализ всего этого это отдельная тема. Этап формирования таблиц и связей между ними как мне кажется упущен, там сразу постулируется - вот у нас есть такие-то таблицы)
как соединяются в этой статье и в этой
Исходные данные представлены на рис.1 и собраны в 3 таблицы: таблица 10, таблица 20, таблица 30. Верхняя строка каждой таблицы отображает одно из возможных текущих состояний, левый столбец таблицы ее возможное действие.
Если собрать все переходы, то получим таблицу Замогилья.
Выходит все же кто-то должен собирать таблицу переходов, этого к сожалению не увидел.
Так и я о том же, у вас на рис. 1 уже данные собраны в таблицы, с состояниями, действиями и возможными переходами
Понятно, спасибо, всегда интересно поговорить с умным человеком, вы уж меня извините за дотошность, очень хотелось понять что происходит. Написали комментариев уже ещё на парочку таких статей :) Предлагаю добавить в статью ссылки на другие ваши статьи, чтобы была возможность понять, к чему это всё.
Лучше покажите конкретный пример, как вы делаете то, что описываете, при помощи этого аппарата, как этот аппарат понимает, что считать объектами, и как они влияют друг на друга? Только не приводите конкретные примеры, как в статье (лампа, стол, ...)
На графах: операция раскрытия переменной, конечные состояния