Compare commits
4 Commits
065cfbb230
...
8534e314e6
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8534e314e6 | ||
|
|
f8c6543f5e | ||
|
|
53c5e3c1ac | ||
|
|
171245850d |
1
.gitignore
vendored
1
.gitignore
vendored
@@ -1 +1,2 @@
|
|||||||
public/
|
public/
|
||||||
|
.DS_Store
|
||||||
|
|||||||
@@ -84,12 +84,41 @@ For example an inserter will perform an intersection, because it can only accept
|
|||||||
But a belt will perform a union, because might have constraints coming from inserters taking from them and downstream belts so the items can take either path.
|
But a belt will perform a union, because might have constraints coming from inserters taking from them and downstream belts so the items can take either path.
|
||||||
Basically the constraints for every edge will be combined using an intersection with the constraints of the node itself, and then all downstream edge constraints will be combined using a union to form the final upstream constraint.
|
Basically the constraints for every edge will be combined using an intersection with the constraints of the node itself, and then all downstream edge constraints will be combined using a union to form the final upstream constraint.
|
||||||
|
|
||||||
JOIN Operator: used to combine multiple "or" constraints, for example for combining downstream constraints.
|
### Notation
|
||||||
This is done by adding all the limits for items together.
|
$c = (l, I, IL) \text{, with}$
|
||||||
|
- $l \in \mathbb{Q} \text{, the total throughput limit}$
|
||||||
|
- $I = \text{A set of items} \text{, the set of items 'used' by the constraint}$
|
||||||
|
- $IL = I \mapsto \mathbb{Q} \text{, the limit for each item}$
|
||||||
|
|
||||||
CHAIN Operator: used to combine multiple "and" constraints.
|
### JOIN Operator $\bigcup$
|
||||||
|
Combines multiple constraints in a logical or kind of fashion.
|
||||||
|
|
||||||
### Representation
|
Given $c_1 = (l_1, I_1, IL_1), c_2 = (l_2, I_2, IL_2)$
|
||||||
|
|
||||||
|
Then $c = \bigcup \\{c_1, c_2\\} = (l, I, IL)$ with
|
||||||
|
- $l = max \\{ l_1, l_2 \\}$
|
||||||
|
- $I = I_1 \cup I_2$
|
||||||
|
- $IL(i) = \begin{cases}
|
||||||
|
IL_1(i) + IL_2(i) & \text{, if } i \in I_1 \land i \in I_2 \\\\
|
||||||
|
IL_1(i) & \text{, if } i \in I_1 \land i \notin I_2 \\\\
|
||||||
|
IL_2(i) & \text{, if } i \notin I_1 \land i \in I_2 \\\\
|
||||||
|
0 & \text{else}
|
||||||
|
\end{cases}$
|
||||||
|
|
||||||
|
### CHAIN Operator $\bigcap$
|
||||||
|
Used to combine multiple constraints in a logical and kind of fashion
|
||||||
|
|
||||||
|
Given $c_1 = (l_1, I_1, IL_1), c_2 = (l_2, I_2, IL_2)$
|
||||||
|
|
||||||
|
Then $c = \bigcap \\{c_1, c_2\\} = (l, I, IL)$ with
|
||||||
|
- $l = min \\{ l_1, l_2 \\}$
|
||||||
|
- $I = I_1 \cap I_2$
|
||||||
|
- $IL(i) = \begin{cases}
|
||||||
|
min \\{IL_1(i), IL_2(i)\\} & \text{, if } i \in I_1 \land i \in I_2 \\\\
|
||||||
|
0 & \text{else}
|
||||||
|
\end{cases}$
|
||||||
|
|
||||||
|
### Graphical Representation
|
||||||
A tree with 3 levels, each doing something different
|
A tree with 3 levels, each doing something different
|
||||||
|
|
||||||
The lowest level, selects by item.
|
The lowest level, selects by item.
|
||||||
|
|||||||
51
content/quickfacts-automata/index.md
Normal file
51
content/quickfacts-automata/index.md
Normal file
@@ -0,0 +1,51 @@
|
|||||||
|
+++
|
||||||
|
title = "Quickfacts - Automata Model"
|
||||||
|
date = 2026-04-02
|
||||||
|
description = "Building an automata based model for factorio"
|
||||||
|
draft = true
|
||||||
|
|
||||||
|
[taxonomies]
|
||||||
|
categories = ["Programming"]
|
||||||
|
tags = ["Factorio", "Rust"]
|
||||||
|
|
||||||
|
[extra]
|
||||||
|
toc = true
|
||||||
|
+++
|
||||||
|
|
||||||
|
Testing
|
||||||
|
|
||||||
|
<!-- more -->
|
||||||
|
|
||||||
|
# Idea
|
||||||
|
Each machine, on its own, can be represented as some kind of automaton.
|
||||||
|
These types of automata, have special input and output transitions.
|
||||||
|
|
||||||
|
Combining two machines into a larger system, means "synchronizing" the two automata, based on their input/output transitions.
|
||||||
|
So if one machine acts as the input for the other, then they synchronize at their respective input/output edges and then continue running independently.
|
||||||
|
|
||||||
|
# Example
|
||||||
|
{% mermaid() %}
|
||||||
|
graph LR
|
||||||
|
S --Output--> S
|
||||||
|
{% end %}
|
||||||
|
{% mermaid() %}
|
||||||
|
graph LR
|
||||||
|
S --Input--> 1
|
||||||
|
1 --'-'--> 1
|
||||||
|
{% end %}
|
||||||
|
|
||||||
|
{% mermaid() %}
|
||||||
|
graph LR
|
||||||
|
S --'-'--> 1
|
||||||
|
{% end %}
|
||||||
|
{% mermaid() %}
|
||||||
|
graph LR
|
||||||
|
S --'-'--> 1
|
||||||
|
{% end %}
|
||||||
|
|
||||||
|
```
|
||||||
|
1: 'Output'----
|
||||||
|
2 'Input'----
|
||||||
|
3: ----'Output'
|
||||||
|
4: ----'Input'
|
||||||
|
```
|
||||||
@@ -1,3 +1,3 @@
|
|||||||
<pre class="mermaid">
|
<pre class="mermaid">
|
||||||
{{ body }}
|
{{ body | safe }}
|
||||||
</pre>
|
</pre>
|
||||||
|
|||||||
Reference in New Issue
Block a user