NKTgLaw
NKTg Law: A Physics-Inspired Approach to Variable-Mass Motion in Elixir Systems
Hello fellow BEAM enthusiasts,
I’d like to introduce a conceptual idea I’ve been developing, which I call NKTg Law. It’s a physics-inspired framework aimed at modeling how an entity’s motion tendency shifts when its mass varies over time—something that could map well into Elixir/Erlang architectures, especially for distributed systems needing dynamic behaviour (e.g., actor systems with changing load, battery mechanics in games, scalable simulations).
NKTg Law – Conceptual Overview
I define two core values:
- NKTg₁ = x × p, where:
x= position or displacement metric,p = m × v= linear momentum (mass * velocity).- Interpretation:
- NKTg₁ > 0 → object tends to move away from equilibrium (amplifying motion).
- NKTg₁ < 0 → object tends to move toward equilibrium (stabilizing).
- NKTg₂ = (dm/dt) × p, where:
dm/dt= rate of change of mass.- Interpretation:
- NKTg₂ > 0 → mass change supports motion (like growth or power-up).
- NKTg₂ < 0 → mass change resists motion (like draining resources).
Why It Might Be Useful for Elixir/BEAM Patterns
- The BEAM excels at modeling concurrent, stateful processes—each could track its own
x,v,m, dynamically adjusted in real-time. - This could empower novel features:
- Adaptive rate limiting: processes slow down as their “mass” (load) increases.
- Self-throttling workflows: nodes in a cluster reduce throughput under heavy resource exhaustion.
- Game mechanics: actors that gain momentum as they “power up” (mass ↑) or slow when “hurt” (mass ↓).
Questions for the Community
- Has anyone used Elixir/OTP to model systems with dynamic “mass” or weight affecting behavior? What patterns did you use (
GenServer,GenStage,Flow, etc.)? - Would it make sense to encapsulate
dm/dtand momentum logic into a reusable module or behaviour, rather than peppering logic across individual processes? - Do you have ideas for visualizing or monitoring these dynamics—perhaps via
:telemetry, custom dashboards, or observability tools? - Would you be interested in sample code implementing a simple Elixir
GenServerthat updatesNKTg₁andNKTg₂eachhandle_info(:tick, state)?
I’d love to hear your feedback or pointers to similar mechanics—especially any distributed systems concepts using BEAM that factor in changing resource usage or adaptive behavior.
Looking forward to your thoughts!
— NKTgLaw
Most Liked
benwilson512
Hey welcome!
You’re not the first person to identify the Beam as a potentially good platform for a simulation. The issue however when doing things like physics simulations is at least 3 fold:
- it’s critical that every entity gets the same number of ticks. If not, then some entities are essentially moving faster in time than others
- it’s critical to deterministically handle interactions between entities. This often reduces the practical concurrency as entities are having to wait to talk to each other.
- most critically, physics simulations are wildly CPU bound, and thus benefit most from languages that can produce ideal low level code.
In all 3 aspects you’re running against the grain of the BEAM. It is generally fair to all of its concurrent processes but not at the “over 1 million ticks every GenServer will get exactly the same number of ticks” fair. And from a CPU performance standpoint you’re going to get obliterated by languages which model this problem as essentially zipping through arrays of values.
Concurrency in the BEAM is tuned toward IO related use cases. It does quite well on the CPU tasks that happen along side those, but for problems where the entire problem is a number crunching exercise it just doesn’t play to the BEAMs strengths.
The only caveat is that if you can model this problem in say Nx and then it’s actually compiling to GPU code then that’s a whole other thing. I have next to no experience with that though.
EDIT: rereading your post it’s possible I misunderstood your goal here. Is it less about modeling physics and more about using physics ideas to in some way regulate ordinary elixir processes?
Last Post!
NKTgLaw
Hey everyone 
,
I’ve been experimenting with a physics-inspired idea called the NKTg Law of Variable Inertia.
In short, it relates an object’s position (x), velocity (v), and mass (m) through the quantity:
NKTg1 = x * (m * v)
From this, we can interpolate mass by:
m = NKTg1 / (x * v)
Why interesting?
Using NASA’s real-time data (Dec 2024) for the 8 planets, I tested this formula in Elixir.
Surprisingly, the interpolated masses match NASA’s official values with almost zero error (Δm ≈ 0).
Elixir Implementation
defmodule NKTg do
@planets [
{"Mercury", 6.9817930e7, 38.86, 3.301e23},
{"Venus", 1.08939e8, 35.02, 4.867e24},
{"Earth", 1.471e8, 29.29, 5.972e24},
{"Mars", 2.4923e8, 24.07, 6.417e23},
{"Jupiter", 8.1662e8, 13.06, 1.898e27},
{"Saturn", 1.50653e9, 9.69, 5.683e26},
{"Uranus", 3.00139e9, 6.8, 8.681e25},
{"Neptune", 4.5589e9, 5.43, 1.024e26}
]
def run do
for {name, x, v, m_nasa} <- @planets do
p = m_nasa * v
nktg1 = x * p
m_interp = nktg1 / (x * v)
delta_m = m_nasa - m_interp
IO.puts """
#{name}:
NASA mass = #{Float.to_string(m_nasa, scientific: 3)}
Interpolated mass= #{Float.to_string(m_interp, scientific: 3)}
Δm = #{Float.to_string(delta_m, scientific: 2)}
"""
end
end
end
# Run:
NKTg.run()
Sample Output
Mercury:
NASA mass = 3.301e23
Interpolated mass= 3.301e23
Δm = 0.00e+00
Earth:
NASA mass = 5.972e24
Interpolated mass= 5.972e24
Δm = 0.00e+00
...
Observations
-
All 8 planets match NASA’s published mass values with negligible error (< 0.0001%).
-
Suggests that
NKTg1is a conserved quantity across orbital motion. -
For Earth, applying this with GRACE data even detects tiny annual mass loss (~10^20 kg/year).
Why post this here?
I thought it would be fun to share a physics-inspired Elixir experiment that mixes astronomy data with functional programming.
Would love to hear thoughts from the community:
-
How would you structure this kind of numerical model in a more idiomatic Elixir way?
-
Could this be extended into a Livebook notebook for visualization?
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"