#header-inner {background-position: right !important; width: 100% !important;}


Token Game.

i am not sure what exactly 'Token Game' is in the context of the Petri Nets, but in a context of 'Ola AH' Programming Language & Modelling it is a 4GL software construction method that involves:

- designing software models; With use of Stitie Space & Mindful Imaging/Editor functionality, computer memory is arranged in 3D, then using keyboard & mouse an objects graph can be created,
- filling software models with code & the initial data, again with use of Stitie Space, Mindful Imaging, keyboard & mouse,
- using token producers, token consumers & token objects; idea is that objects communicate with other objects via tokens they produce and/or consume. objects can be token producers and/or consumers at the same time; tokens are not directly given from producers to consumers, instead these are put on 'shelves' placed between producers and consumers - that way consumers can wait for a complete set of tokens before consumption,
- designing the data flow (tokens can contain 'identifier', 'type', 'properties' & 'payload' data, can be in different places at different times),
- 'token shelves' manage tokens contained, can generate 'inventory events', can respond to requests for tokens consumption with tokens selection criteria that can use 'token identifiers', 'token types' & 'token properties'; 'result/output shelves' for one or a group of objects can be also 'entry/input shelves' for one or group of the same or different objects,
- checking & managing properties of the model graph with tokens, such as deadlocks possibility, bottleneck relief management; detection, management & handling of graphs' cycles, etc,
- model/tokens application management at the runtime,
- conditionality & events,
- use of Event Bus - not only, but also for token production & consumption; either using or not using an Event Bus is idiomatic practice in this methodology,
- probably more.

An Example of a Token-Game report processing software design.

Income processing is replicated for efficiency into three subsystems.

Income processing subsystems wait for a complete set of tokens before consumption.
These are notified of 'inventory events', when shelf's state changes.

Probably Tuple Space(s) also called: 'Linda' might be used to represent conditions, a presence of a condition tuple or a lack of condition tuple might inform us about a condition holding or not. Events occuring might model cause(s) happening. A cause-event occurance might make condition(s) to appear or disappear from a Tuple Space(s), or just trigger a code to start happening.

Let's think that for a certain code parts to start, there's need:
- Cause(s) occurance(s), in a proper moment(s) in time,
- Condition(s) holding in a proper moment(s) in time.

for some non-strict ideas inspired by Abstracted Petri Nets, see: Decision Filters.

'Token Game' has uses in abstracted neural network modelling, where payload data can be passed between abstracted neuron layers in an object-oriented form. Abstracted Neuron here are objects that consider payload, not only input signals, weight & bias. These can fire and produce payload to next layers, hidden or output.

Abstracted Neuron Objects can learn as well - either from a batch file, or by clicking on a Mindful Imaging Visualization. Payload Routes, as well as Payload Content can be provided during program's runtime as well.

Abstracted Neuron Objects' code & state can be inserted into the Stitie Space's 'machine' during the runtime, to be interpreted there - either via network or from the Editor. A live system can be modelled as with Smalltalk programming language.

see also, if You wish or need, ... : 'Talking Objects' Solutions, Object Relationships Modelling & Analysis, Neural Networks, Stitie Space & Stitie Machine 'Sunsail', Stitie Machine 1.2 'Satellite', Causes & Conditions, Agile Transformation of Information State, Conditional Software Tiering.

(probably unfinished a post, probably will be edited in the future).

No comments:

Post a Comment