aidotse / aidotse/behovskartan

Code scenario constraints (generator, api, frontend)

Offen
#90 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Jupyter Notebook
Sterne
0
Forks
0
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

You're correct that constraints are essential for **limiting invalid or irrelevant scenario combinations**, and you’ll want a single, expressive format that works for:

* your **transform pipeline** (filter what gets computed), and
* your **API** (filter what can be queried or selected).

Here’s how to design this robustly:

---

## ✅ 1. **Constraint format**

A list of **constraint rules** (think: "forbid any row that matches this condition").

Represent constraints as **structured objects** like this:

```yaml
constraints:
- if: { population: "high" }
then:
- transport_electrification: "<=2"
- flexibility: ">=1"

- if: { industry_transition: "0" }
then:
- new_industry: "0"
- new_datacenters: "0"
```

Each rule means:
🗣️ *“If these conditions are met, then the other parameters must satisfy these sub-conditions too.”*

This allows:

* Expressive control (`=`, `<`, `>`, etc.),
* Composable logic,
* Easy evaluation in both Python and JS.

You could also support global disallowed combinations:

```yaml
disallow:
- { population: "high", flexibility: "0" }
- { industry_transition: "0", new_industry: "3" }
```

---

## ✅ 2. **Internal evaluation (pipeline)**

Convert constraints into **boolean masks** over the cartesian product of parameter values.

E.g., in Python:

```python
def violates_constraints(row, constraints):
for rule in constraints:
if all(row[k] == v for k, v in rule['if'].items()):
for cond in rule['then']:
for k, expr in cond.items():
if not eval(f"{row[k]} {expr}"): # safe_eval version preferred
return True
return False
```

Use this to **filter out** invalid combinations early.

---

## ✅ 3. **Frontend/API use**

Same format can be:

* Parsed client-side to **disable combinations** in a UI (e.g. dropdowns),
* Enforced in an API validator.

Optional: compile to a JSON Schema or SQL WHERE clause for efficiency.

---

## 🧠 Alternative formats

If YAML feels verbose, you can also use a **concise DSL**:

```yaml
constraint_rules:
- "if population = high then transport_electrification <= 2"
- "if industry_transition = 0 then new_industry = 0 and new_datacenters = 0"
```

This is easy to parse and even display in UI.

---

## ⚠️ Notes

* You need to define **how to compare** values (e.g. strings vs numbers).
* You may want to allow wildcard matches (`any`, `!=`, etc.).
* Keep constraints **independent from implementation logic** — don’t encode them directly in transform functions.

---

Would you like a Python validator to test these constraints against a full scenario grid?

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.