Описываем модель. Накладываем желаемые ограничения, подмножество желаемых состояний. Играемся с уравнениями, применяем разные теоремы чтобы получить функцию управления системой.
Я заметил, что программы по-сути тоже динамические системы. Также как и в классических динамических системах там есть состояние, есть время, есть ввод и вывод.
Просто они существуют не в векторном пространстве вещественных числе R^n, а в векторном пространстве нулей и единиц: https://en.wikipedia.org/wiki/Vector_logic
Хочу описывать программы как уравнения, исследовать их сходимость к определённому подмножеству состояний.
Как ни искал, чёт не могу найти чтобы кто-то это уже делал, хотя идея вроде бы лежит на поверхности.
Кто-нибудь занимался чем-то похожим? Накидайте ссылок или ключевых слов по которым можно что-то похожее найти
Тебе нужно копать примерно в сторону реконструкции фазового состояния, state space reconstruction.
Возможно, для рандомной программы подобное вообще бессмысленно, так как не то, что сколько-нибудь устойчивого аттрактора, но и какого-нибудь репеллента не получится. Но если нечем заняться, попробуй, готового софта для этого не то чтобы очень много, но он есть. tisean какой-нибудь итп.
>Возможно, для рандомной программы подобное вообще бессмысленно
Не, для рандомной программы даже не буду пытаться.
Вообще план такой:
1) Научиться писать программы с помощью преобразований над state space vector.
2) Написать парочку известных программ и алгоритмов, поисследовать их state space. Поискать аттракторы. Первая на очереди у меня Philosophers Dining Problem и различные решения для неё. А потом хочу так же реализовать Raft Consensus Algorithm.
3) Сделать простенький язык программирования, который в основании полагался на это представления программ.
Брать программы на существующих языках, и пытаться исследовать их state space -- это полный пиздец. Врядли чем-то кончится.
>это не математика
ТЫ ОХУЕЛ? С каких это пор теория управления это не математика
Есть такая тема, "Minsky machine"
https://en.m.wikipedia.org/wiki/Counter_machine
По-сути, это небольшие наборы ассемблерных инструкций, с помощью любого из которых возможно представить любую программу на ассемблере (кроме обращений к памяти итд, но нужные для этого инструкции можно добавить):
> set 1: { INC (r), DEC (r), JZ (r, z) }, (Minsky (1961, 1967), Lambek (1961))
> set 2: { CLR (r), INC (r), JE (rj, rk, z) }, (Ershov (1958), Peter (1958) as interpreted by Shepherdson–Sturgis (1964); Minsky (1967); Schönhage (1980))
> set 3: { INC (r), CPY (rj, rk), JE (rj, rk, z) }, (Elgot–Robinson (1964), Minsky (1967))
Имея state space представление для таких наборов (например, INC, DEC, JNZ, MOV + SETF, CLRF не обязательно), можно уже строить программу с использованием только их state space. Всё это чисто в теории, конечно.
> не математика
> съебывайте в /pr/
>>117748
> это не математика
>Хочу описывать программы как уравнения
Как ты себе это представляешь?
>Как ты себе это представляешь?
x0 -- векторное представление начального состояния программы
P -- матрица представляющая программу
x_n = P^n * x0
x_n -- состояние программы на n-ном шаге.
В идеале будет сходиться к какому-то состоянию, либо гонять по циклу каких-то состояний.
мимо погромист крашу кнопки за 300к
Ты какой то определенный алгоритм можешь так представить (какую нибудь числодробилку), как наносек выше написал, программа это слишком общее.