51 lines
3.0 KiB
Markdown
51 lines
3.0 KiB
Markdown
# Replace "speed" metric with power density scoring
|
|
|
|
## The problem
|
|
|
|
After standardizing the database to SI base units, the stub estimator's speed formula was exposed as fundamentally broken:
|
|
|
|
```python
|
|
raw["speed"] = min(power_density * 0.14, 3e8) # m/s
|
|
```
|
|
|
|
An Electric Motor (2000 W/kg) on a Light Personal Vehicle produced 280 m/s (1008 km/h). The old formula had the same issue (1000 km/h) — it was just less visible in km/h with the `|si` filter masking the absurdity.
|
|
|
|
The root cause: **top speed cannot be derived from power density alone**. Speed depends on drag, rolling resistance, medium, vehicle geometry, and a dozen other factors the stub doesn't know. A linear power-to-speed model can never work across domains spanning e-bikes to spaceships.
|
|
|
|
## Candidate replacement: thrust-to-weight ratio (N/kg)
|
|
|
|
N/kg is dimensionally m/s² — a well-understood physical quantity. The actuator already declares `power_density` (W/kg), so the data exists. But three concerns emerged:
|
|
|
|
1. **Redundant with Pass 1** — The constraint system already checks actuator `power_density` against platform `power_density_required`. Combos that reach scoring have already passed this gate, so scoring on the same axis re-evaluates something the pipeline already filtered.
|
|
|
|
2. **Actuator-dominated** — Only the actuator declares `power_density`. Every combo sharing the same actuator scores identically, so the metric doesn't capture entity interplay.
|
|
|
|
3. **Higher isn't always better** — A Rocket Nozzle (10,000 W/kg) on a Light Personal Vehicle has extreme thrust-to-weight, but that's not desirable for urban commuting. The current scorer only does monotonic normalization (higher is better, or lower is better), not "closer to optimal band."
|
|
|
|
## The insight: `power_density_required` is a scoring concern, not a constraint
|
|
|
|
Examining what `power_density_required` actually represents on platforms:
|
|
|
|
- Road Vehicle: "I need >= 5 W/kg"
|
|
- Fixed-Wing Aircraft: "I need >= 100 W/kg"
|
|
- Spaceship: "I need >= 300 W/kg"
|
|
|
|
These thresholds are arbitrary performance gradients — a car with 4 W/kg still moves, just poorly. There's no hard physics cliff. Compare with genuinely binary constraints:
|
|
|
|
- **medium mutex** — a boat physically cannot operate in space
|
|
- **energy_form requires/provides** — an electric motor cannot burn gasoline
|
|
- **mass range** — a nuclear reactor won't fit on a bicycle frame
|
|
|
|
Power density fit is "how well does it work," not "can it work at all." That's scoring territory.
|
|
|
|
The one edge case — aircraft needing thrust-to-weight > 1 to leave the ground — is already implicitly handled by atmosphere/medium constraints and energy density minimums.
|
|
|
|
## Decision
|
|
|
|
Remove `power_density_required` from platform entity constraints and introduce it as a domain-level scoring metric instead. This:
|
|
|
|
- Removes ~15 arbitrary constraint thresholds from seed data
|
|
- Lets more combos through to scoring for nuanced evaluation
|
|
- Creates a metric that varies by combo (actuator provides vs. platform context)
|
|
- Replaces the broken "speed" heuristic with something directly computable from entity data
|