NKTg Law: A Physics-Inspired Approach to Variable-Mass Motion in Elixir Systems

Chat / Discussions
,
1

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

  1. Has anyone used Elixir/OTP to model systems with dynamic “mass” or weight affecting behavior? What patterns did you use (GenServer, GenStage, Flow, etc.)?
  2. Would it make sense to encapsulate dm/dt and momentum logic into a reusable module or behaviour, rather than peppering logic across individual processes?
  3. Do you have ideas for visualizing or monitoring these dynamics—perhaps via :telemetry, custom dashboards, or observability tools?
  4. Would you be interested in sample code implementing a simple Elixir GenServer that updates NKTg₁ and NKTg₂ each handle_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

1 Like
2

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:

  1. 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
  2. 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.
  3. 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?

2 Likes
3

I see your point about the BEAM not being ideal for raw number-crunching physics simulations, especially when fairness in ticks and CPU-bound performance are critical. That makes sense if the goal is to replicate a high-fidelity physical world.

But the intention behind the NKTg law is slightly different. It is not about simulating physics per se, but about using a physics-inspired principle (variable inertia under force) as a metaphor and a mechanism for regulating process dynamics in Elixir systems.

In NKTg, inertia is not fixed: processes can “gain or lose effective mass” depending on their interactions, which makes them accelerate or decelerate relative to the applied force. Translated to BEAM, this means we’re not demanding strict synchronization of millions of ticks, but rather a proportional adjustment of scheduling and concurrency load based on this varying inertia idea.

So instead of fighting the BEAM’s grain, the law tries to align with it:

  • Concurrency fairness becomes “mass distribution” — some processes naturally move slower/faster, and that is modeled intentionally.

  • Determinism is not enforced globally, but replaced by relative predictability of how processes evolve under varying loads.

  • CPU-bound heaviness is reframed: the law doesn’t assume continuous crunching, but rather adapts inertia as a regulating factor for real-world Elixir workloads.

In short, the NKTg law is not asking the BEAM to be a physics simulator. It is offering a physics-inspired abstraction to reason about process behavior, variability, and scaling. From that perspective, the BEAM’s strengths in fairness and concurrency are actually a good fit.

4

Hey everyone :waving_hand:,

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 NKTg1 is 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?