I’d like to propose a concept I’m calling the NKTg Law—a speculative model for capturing the dynamics of varying inertia that could inspire new ways to model motion in functional systems (and beyond).
Concept Brief
Traditionally, inertia is treated as constant. The NKTg Law challenges this assumption by introducing a time-sensitive framework:
NKTg₁ = x × p, where:
xxx is position
p=m⋅vp = m \cdot vp=m⋅v (momentum)
NKTg₂ = dmdt\frac{dm}{dt}dtdm × p, where dmdt\frac{dm}{dt}dtdm is the rate of change of mass.
Interpreting the signs of these quantities:
NKTg₁ > 0: tendency to move away from equilibrium.
NKTg₁ < 0: tendency to return towards equilibrium.
NKTg₂ > 0: mass variation supports movement.
NKTg₂ < 0: mass variation resists motion.
The unit—let’s call it NKTm—represents a unit of “varying inertia.”
Why It Matters
Breaking from constant-mass models: Earth and robotic systems could benefit from modeling inertia as a dynamic property (e.g., fuel consumption in rockets, variable payloads in drones).
Raise new challenges in functional modeling: How would we simulate or reason about systems in Haskell under time-varying inertia?
Extensibility to reactive or FRP-like systems: Systems that continuously respond to changing mass could be elegantly expressed using Haskell’s FRP libraries.
Questions for Discussion
Could monads or lenses help us model and manipulate NKTg components in a clean, functional way?
What existing Haskell libraries—like ions, reflex, or hmatrix—might be repurposed to simulate or reason about these dynamics?
Are there analogous formalisms in physics, robotics, or control theory that inform or challenge this model?
How might this concept extend toward practical simulations, e.g., Haskell-based orbital dynamics or real-time control systems?
I’d love to hear your thoughts on the following:
Theoretical soundness: Are there flaws or interesting parallels in physics or mathematics?
Modeling in Haskell: Any suggestions for types, abstractions, or libraries?
Potential applications: Academic simulations, robotics, or real-world physics engines?
While it is certainly fun to model physical systems in a functional language such as Haskell, my feeling about your questions is that you should ask on a dedicated physics forum first, especially the questions number 3 and 4. Once the physicists agree on how it should be modeled mathematically, one can approach the problem of implementation, which is often straightforward in FP.
That said, there are a number of physicists around in this forum. If you search for existing “Physics” threads you will learn some of their names.
First, what you propose it is not a Framework for coding, but a physical Model.
Sure, what is could be written as “formulae” could be implemented by the computer languages, such as Haskell.
Unfortunately, your NKTg₂ is a differential equation. And quick, precise and effective solving differential equations and find integrals is not a strong part of Haskell.
Yes, Haskell is highly math language. But it focuses on Abstract Algebra and Math Logic: Type Theory (including Lambda-calculus) and Category theory.
Maybe what you need - it is math languages, which focuses on Computational Math, such as Solving Equations including Differential Equations, Linear Equations, Integration, Extrapolation, …
Thank you for the warm welcome and for pointing me in the right direction. That makes sense — I’ll look into asking on a physics-focused forum first, especially regarding questions 3 and 4, to make sure the mathematical foundation is clear.
Once the modeling side is agreed upon, I’ll return to explore how to implement it in Haskell. I’ll also check out the existing “Physics” threads here to see what others have shared.
Thank you for your thoughtful feedback and clarification. You are right — the NKTg law is indeed a physical model rather than a programming framework. My intention in using Haskell was not to suggest it as the primary tool for solving differential equations, but rather as a way to experiment with modeling the underlying relations once the mathematical form is established.
I agree that NKTg₂, being a differential equation, is better suited to computational math environments that are specialized for solving equations, integration, and related tasks. At this stage, my goal is more about validating the physical model itself and then later exploring different ways it could be implemented or simulated.
Your point about Haskell’s focus on abstract algebra, type theory, and category theory is well taken. Perhaps Haskell might still play a role in structuring or exploring the formal aspects of the model, even if the heavy computational parts are done elsewhere.
Thanks again for highlighting this distinction — it helps me see more clearly how to separate the physics, the mathematics, and the implementation.