Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Graph Computation Note #101

Merged
merged 1 commit into from
Oct 19, 2023
Merged

Graph Computation Note #101

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion ActionStrategy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ The staked effect of this data structure is one that is capable of mapping the i
As the original pursuit of this data structure was to utilize the data parameter to formalize a transformation of said data over a period of steps. To map the exact transformation of data through an application, versus a series of factories. This chain like pattern of design is represented as a separate concept within this framework. As the framework is designed to be wholly responsible for itself. As the main issue would be the change of data that the chained behavior may be dependent upon. To allow for that data to transformation across any number of nodes on a graph, we introduced the spatial ownership design pattern. Where the final destination for such could be the original axium, the client's screen, or even the database of some server. This is a formalization of a greater than the sums approach to programming by way of composition, decomposition, and recomposition of sets of concepts, contained within some axium that interacts with other axiums.

### How STRX allows ActionStrategies to be a Data Oriented Format for Graph Computation.
Since STRX uses semaphores over strings types to formalize its own inner workings. The main functionality of strings throughout this system are for readability and being able to isolate some additional functionality at run time. Due to this approach, the net run time of a "Axium" is just a series of entities(actions/state/concept), arrays (staged plans), trees(action strategy), and graphs(staged plans + punted/sequence strategies). That can be made numerically pure with a compilation process to set the semaphores ahead of time. Therefore this system is functionally just a graph programming framework that uses strings for user comprehension, and such can be stripped.
Since STRX uses semaphores over strings types to formalize its own inner workings. The main functionality of strings throughout this system are for readability and being able to isolate some additional functionality at run time. Due to this approach, the net run time of a "Axium" is just a series of entities(action/state/concept), arrays (staged plan), trees(action strategy), and graphs(staged plans + punted/sequence strategies). That can be made numerically pure with a compilation process to set the semaphores ahead of time. Therefore this system is functionally just a graph programming framework that uses strings for user comprehension, and such can be stripped.

The only blocker in the scope of this current implementation, is that we find faulty actions, plans, and the concluding strategies via a type comparison. This can be further extrapolated away, but would save that work for a low level programming language. As the choice of Typescript in this project was due to familiarity and as the fastest path towards creating a MVP. This is mainly as a note for later as graph computation hits parity.

Expand Down