Applied Combinatorics

Innovation via Attribute Mixing

This is an experimental repo which uses lists of physical attributes and recombines them to form new objects. These objects are then reviewed for comprehensibility and viability.

Example:

Let's identify some methods of getting from here to there:

• Car
• Airplane
• Train
• Bicycle
• Walking with your legs
• Wheelchair
• Scooter
• Spaceship
• Teleportation or beaming technology

To build object 'car' you must select a power source. Power sources include:

• Gas/Internal Combustion Engine
• Lithium Ion Batteries
• Hydrogen Combustion Engine
• Human pedalling
• Modular Nuclear Reactor
• Coal/steam locomotion
• the Sun via Solar Sail
• Cannonfire Recoil
• Pushed by a friend

Putting together lists 1 and 2 we can create 81 mostly novel forms of transportation, such as trains powered by solar sails or walking powered by tiny cannon recoil. Obviously some of these concepts are not as viable as others. While being pushed by a friend might work for those in a wheelchair, it is too slow for those in a car. Speed is therefore a target metric. Let's list some target metrics:

• Speed
• Cost efficiency
• Availability
• Safety
• Range (by fuel)
• Range (by platform degredation or maintenance)

Using these metrics this experiment intends to sift vaguely reasonable concepts from nonsense. Its shortlist may include concepts that sound bizarre but may be technically plausible. Bicycles, motorcycles, and e-bikes all had their turn. Why not hydrogen-bikes?

Setup

Docker (recommended)

docker compose up web

Then open http://localhost:5000.

Seed the database with the transport example:

docker compose run cli seed transport

Local development

pip install -e ".[dev,web]"
python -m physcom init
python -m physcom seed transport
python -m physcom_web

Then open http://localhost:5000.

Run tests:

python -m pytest tests/ -q

LLM integration (optional)

By default the pipeline uses stub estimation. To enable Gemini:

pip install -e ".[gemini]"
export LLM_PROVIDER=gemini
export GEMINI_API_KEY=your_key_here
# export GEMINI_MODEL=gemini-2.0-flash  # optional, this is the default
physcom run urban_commuting --passes 1,2,3,4

Copy .env.example to .env and fill in your key for persistent configuration.

---

a few notes: the thin atmosphere and the sun are obvious dependencies to the solar sail power source. Dependencies would include things such as scale of force (nuclear reactor vs pedalling obviously has an important force differential) and geographic requirements (walking requires ground and gravity). The project should include on every entity a list of dependencies. The viability tester will need to pull in all of these dependencies to ensure they do not contradict.

Additionally, metrics are expected to be extremely close to full points or none at all. The speed of a person pushing a car is effectively zero in its domain whereas a rocket powered car would easily reach the limits of speed in the domain. The resulting multiplication between metrics to get the viability score will be heavily logarithmic. This is expected and is intended to be a filter to eliminate technically plausible but completely pointless in practice concepts. Metric weights are therefore dependent on domain, which will also need to be defined.

First pass viability is physics such as force output, possibly generalized by LLM, last passes can include LLM and human review of social factors.

Attributes themselves are real (quality proven) and are thusly not garbage in the 'garbage in garbage out' risk - that risk is measured in how much nonsense the dimensional explosion generates that makes it past heuristic filters.