stochastic particle notes, esquared simplification, updated waves

Author: rcoreilly

content/complex-kg.md

@@ -51,7 +51,7 @@ $$
 
 This is directly computable for each cubic cell $i$ in the system.
 
-It becomes very clear when explicitly written out in this manner that charge represents a coupling of the two otherwise independent variables in the complex number, and this suggests why a single scalar number cannot represent a conserved charge value. The fact that these variables are coupled here, but not in the actual wave equations that drive their updating, seems magical.
+It becomes clear when explicitly written out in this manner that charge represents a coupling of the two otherwise independently-updated variables in the complex number, and this suggests why a single scalar number cannot represent a conserved charge value.
 
 {id="sim_cc" title="Complex charge" collapsed="true"}
 ```Goal
@@ -82,16 +82,15 @@ func valUpdate() {
     bphaseStr = fmt.Sprintf("b phase: %4.0f", bphase)
     massStr = fmt.Sprintf("mass: %4.1f", mass)
     hbarStr = fmt.Sprintf("hbar: %4.1f", hbar)
-    bi := ai * float64(math32.Cos(math32.DegToRad(float32(bphase))))
-    bvi := math.Sqrt(mcOverHSq) * ai * float64(math32.Cos(math32.DegToRad(float32(bphase+90))))
+    bi := ai * float64(math32.Cos(math32.DegToRad(float32(-bphase))))
+    bvi := math.Sqrt(mcOverHSq) * ai * float64(math32.Sin(math32.DegToRad(float32(-bphase))))
     ##
     mf := array(mcOverHSq)
     cf := array(heOver2mCSq)
     ap := array(ai)
     bp := array(bi)
     av := array(0.0)
     bv := array(bvi)
-    mxv := array(0.0)
     ##
     for t := range 100 {
         ##
@@ -106,8 +105,6 @@ func valUpdate() {
         
         bv -= mf * bp
         bp += bv
-        
-        mxv = max(mxv, av)
         ##
     }
     msgStr = fmt.Sprintf("<b>Charge: %7.3g </b>", chg.Float(99))
@@ -175,9 +172,9 @@ addSlider(&massStr, &mass, 0.1, 1.0)
 addSlider(&hbarStr, &hbar, 0.1, 1.0)
 ```
 
-[[#sim_cc]] demonstrates how this works, in terms of two simple harmonic oscillator variables _a_ and _b_, which are set to be a specific phase apart from each other. Regardless of the phase relationship, the computed charge value remains constant across the cycles of oscillation. However, critically, the value of the charge is directly a function of this phase relationship, with a maximum of 0.5 when the _b_ value is +90 degrees in relation to the _a_ value, and a minimum of -0.5 for -90 degrees, and zero for 0 or 180 degrees. These relationships are fairly obvious once you appreciate the relationship between velocity and position for each of the variables, and how they enter into the charge equation.
+[[#sim_cc]] demonstrates how this works, in terms of two simple [[harmonic oscillator]] variables _a_ and _b_, which are set to be a specific phase apart from each other (+90 degrees shifts _b_ to the _left_ (earlier) relative to _a_, while -90 shifts to the right, due to the trigonometric convention of 0 degrees being at 1,0 and proceeding counter-clockwise from there). Regardless of the phase relationship, the computed charge value remains constant across the cycles of oscillation. However, critically, the value of the charge is directly a function of this phase relationship, with a maximum of 0.5 when the _b_ value is +90 degrees in relation to the _a_ value, and a minimum of -0.5 for -90 degrees, and zero for 0 or 180 degrees. These relationships are fairly obvious once you appreciate the relationship between velocity and position for each of the variables (which are 90 degrees out of phase with each other, always), and how they enter into the charge equation.
 
-Because the separate real-valued wave functions are independently updated, it thus becomes important that these two wave states are initialized with a specific phase relationship, which will then determine the charge value represented.
+Critically, complex numbers are _always_ 90 degrees out of phase with each other by the very nature of the complex plane. Thus, even though the separate real-valued wave functions are independently updated, it is critical that these two wave states are _initialized_ with the 90 degree phase relationship appropriate for complex numbers, which will then determine the sign of the charge value represented.
 
 Perhaps the most important feature of this charge equation is that it can be either positive or negative, as a function of the phase relationship. This is not true of the corresponding expression for Schrödinger's equation, which is "definitely positive", or, in mathematical terminology, "positive definite". This is one of the major reasons why standard quantum physics has strongly embraced Schrödinger's equation, and not KG: KG does not fit with the standard probabilistic framework, where the wave describes a probability, and a probability is always positive.
 

content/harmonic-oscillator.md

@@ -0,0 +1,147 @@
++++
+bibfile = "mechphys.json"
++++
+
+The **simple harmonic oscillator** (SHO) captures the core oscillatory behavior of [[waves]], without any spatial dimensions to bother with. It can be seen as the 0-dimensional version of a wave, where the force that drives the oscillation comes not from neighbors, but from the position (height) of the wave itself. As such, it provides a potentially interesting role in the mechanics of [[stochastic particles]] because it can be entirely localized to one discrete grid cell within the [[cellular automaton]] framework. Thus, a particle in this view can be considered to be a simple harmonic oscillator that periodically jumps between cells.
+
+The basic equations from [[waves]] for the SHO are:
+
+{id="eq_force" title="restoring force"}
+$$
+f = -c^2 y^t
+$$
+
+where $c$ is the basic rate update constant, analogous to the speed of light in waves, which determines the effective strength of the restoring force, and thus the oscillation rate. The _t_ suffix indicates the time step (only for variables that require integration over time). Everything else from this point onward is the same, in the basic Newtonian physics framework of acceleration, velocity, and position:
+
+{id="eq_a" title="acceleration"}
+$$
+a = \frac{f}{m}
+$$
+
+{id="eq_" title="new velocity"}
+$$
+v^{t+1} = v^t + a
+$$
+
+{id="eq_" title="new state"}
+$$
+y^{t+1} = y^t + v^{t+1}
+$$
+
+{id="sim_sho" title="Simple harmonic oscillator" collapsed="true"}
+```Goal
+ip := 1.0
+c := 0.2
+mass := 0.5
+csq := c * c
+
+var massStr, cStr, msgStr string
+
+##
+totalTime := 100
+sp := zeros(totalTime)
+sv := zeros(totalTime)
+pE := zeros(totalTime)
+kE := zeros(totalTime)
+tE := zeros(totalTime)
+##
+
+func valUpdate() {
+    massStr = fmt.Sprintf("mass: %4.1f", mass)
+    cStr = fmt.Sprintf("c: %4.1f", c)
+    csq = c * c
+    ##
+    mf := array(mass)
+    cf := array(csq)
+    p := array(ip)
+    pp := array(ip)
+    pv := array(0.0)
+    mv := array(0.0)
+    v := array(0.0)
+    pot := array(0.0)
+    kin := array(0,0)
+    ##
+    for t := range 100 {
+        ##
+        pv = 1.0 * v 
+        pp = 1.0 * p
+        v = pv - (cf * pp) / mf
+        p = pp + v
+        
+        mv = 0.5 * (v + pv) // midway
+        pot = 0.5 * pp * pp
+        kin = (mv * mv * mf) / (2.0 * cf)
+        
+        sp[t] = p
+        sv[t] = v
+        pE[t] = pot
+        kE[t] = kin
+        tE[t] = pot + kin
+        ##
+    }
+    msgStr = fmt.Sprintf("<b>Total E: %7.3g </b>", tE.Float(99))
+}
+
+valUpdate()
+
+plotStyler := func(s *plot.Style) {
+    s.Plot.XAxis.Label = "Time"
+    s.Plot.XAxis.Range.SetMax(100).SetMin(0)
+}
+plot.SetStyler(sp, plotStyler) 
+
+fig1, pw := lab.NewPlotWidget(b)
+pl := plots.NewLine(fig1, sp)
+vl := plots.NewLine(fig1, sv)
+pEl := plots.NewLine(fig1, pE)
+kEl := plots.NewLine(fig1, kE)
+tEl := plots.NewLine(fig1, tE)
+fig1.Legend.Add("p", pl)
+fig1.Legend.Add("v", vl)
+fig1.Legend.Add("pE", pEl)
+fig1.Legend.Add("kE", kEl)
+fig1.Legend.Add("tE", tEl)
+
+msgTx := core.NewText(b)
+msgTx.Styler(func(s *styles.Style) {
+    s.Min.X.Ch(80) // clean rendering with variable width content
+})
+core.Bind(&msgStr, msgTx)
+
+func updt() {
+    valUpdate()
+    pl.SetData(sp)
+    vl.SetData(sv)
+    pEl.SetData(pE)
+    kEl.SetData(kE)
+    tEl.SetData(tE)
+    msgTx.UpdateRender()
+    pw.NeedsRender()
+}
+
+func addSlider(label *string, val *float64, mnVal, mxVal float32) {
+    tx := core.NewText(b)
+    tx.Styler(func(s *styles.Style) {
+        s.Min.X.Ch(40)  // clean rendering with variable width content
+    })
+    core.Bind(label, tx)
+	sld := core.NewSlider(b).SetMin(mnVal).SetMax(mxVal).SetEnforceStep(true)
+    if mxVal > 10 {
+        sld.SetStep(10)
+    } else {
+        sld.SetStep(0.1)
+    }
+	sld.SendChangeOnInput()
+	sld.OnChange(func(e events.Event) {
+		updt()
+		tx.UpdateRender()
+	})
+	core.Bind(val, sld)
+}
+
+addSlider(&massStr, &mass, 0.1, 1.0)
+addSlider(&cStr, &c, 0.1, 1.0)
+```
+
+The equivalent of the wavelength for the SHO is the _period_, in time, for the cycle to repeat.
+

content/special-relativity.md

@@ -167,6 +167,7 @@ $$
 
 These two variables can be related in the relativistic energy-momentum equation:
 
+{id="eq_esq-p" title="relativistic energy-momentum"}
 $$
 E^2 = \vec{p}^2 c^2 + (m_0 c^2)^2
 $$
@@ -193,9 +194,51 @@ $$
 E \approx \frac{1}{2}m_0 \vec{v}^2 + m_0 c^2
 $$
 
-Interestingly, the [[Klein-Gordon]] equation can be derived directly from this equation!
+Interestingly, the [[Klein-Gordon]] equation can be derived directly from the full $E^2$ equation!
 
-Finally, we note that the warping of space and time that produces gravitational effects according to general relativity enters into our model in a very different way, as described later. Thus, in our model, special and general relativity result from two very different mechanisms.
+## Simplification of the energy factor
+
+The relativistic energy factor as normally expressed in [[#eq_esq-p]] actually just contains 3 essential variables, when you apply the Lorentz factor to the momentum expression. Thus, it can be simplified considerably to combine all these factors together, which reveals a rather interesting expression:
+
+{id="eq_esq-simp" title="simplified relativistic energy-momentum"}
+$$
+E^2 = \frac{c^6 m_0^2}{c^2 - v^2}
+$$
+
+The $c^6$ in the numerator is particularly striking, in that one rarely sees such a large power in a fundamental equation such as this. If the "basic" power for a squared equation such as this is $c^2$, then it seems that there are 3 such elements coming together in this energy expression. Does that perhaps have something to do with the 3 spatial dimensions? Interestingly, in [[stochastic particles]], we create a system of 3 simple [[harmonic oscillators]] to encode the momentum of a discrete particle, one for each spatial dimension, so perhaps this is in fact represented in the total energy of the particle.
+
+The denominator is also another way of understanding the Lorentz factor, where as the velocity $v$ increases toward $c$, this denominator gets smaller, and thus the $E^2$ factor grows toward infinity.
+
+### Algebraic steps
+
+For concreteness, here are the steps taken to arrive at this simplification:
+
+$$
+E^2 = \frac{c^2 m_0^2 v^2}{1 - \frac{v^2}{c^2}} + (c^4 m_0^2)
+$$
+
+$$
+E^2 = \frac{c^2 m_0^2 v^2}{\frac{c^2 - v^2}{c^2}} + (c^4 m_0^2)
+$$
+
+$$
+E^2 = \frac{c^4 m_0^2 v^2}{c^2 - v^2} + (c^4 m_0^2)
+$$
+
+$$
+E^2 = \frac{c^4 m_0^2 v^2}{c^2 - v^2} + \frac{(c^4 m_0^2)(c^2 - v^2)}{c^2 - v^2}
+$$
+
+$$
+E^2 = \frac{c^4 m_0^2 (v^2 + c^2 - v^2)}{c^2 - v^2}
+$$
+
+$$
+E^2 = \frac{c^6 m_0^2}{c^2 - v^2}
+$$
+
+
+<!--- Finally, we note that the warping of space and time that produces gravitational effects according to general relativity enters into our model in a very different way, as described later. Thus, in our model, special and general relativity result from two very different mechanisms. actually maybe not! -->
 
 ## Relativistic momentum and velocity
 

content/stochastic-particles.md

@@ -96,6 +96,8 @@ It is essential that these probability computations are all propagated in terms
 
 The basic behavior of a stochastic particle independent of any waves is described by [[@^Sciarretta18]] (in the 1D case; [[@Sciarretta21]] extends to the 3D case with spin). In this non-relativistic model, the particle has an associated real-valued 3-component normalized (range -1..1) momentum vector $\vec{\nu}$ that drives a _stable_ trajectory over time, despite the stochastic nature of each movement step. Any forces accumulate in this momentum vector, and it propagates with the particle. The motion of the particle is defined per dimension $\mu$ (per the [[four-vector]] notation), in reference to an energy-like factor:
 
+todo: figure out if e should in fact be across all dims -- seems like it should. just run an empirical sim.
+
 $$
 e_{\mu} = \frac{1 + \nu_{\mu}^2}{2} 
 $$
@@ -120,15 +122,25 @@ It would be useful to derive a relativistic version of these individual motion e
 
 Key points: 
 
-* key point about simple harmonic oscillator (SHO): the height position _itself_ provides the acceleration force pulling back -- this is even simpler than a wave! So there is a 4 vector of SHO that represent the momentum of the particle, and are coupled to the wave variables! The time-like one is the "heartbeat" of the particle, representing the rest mass, while the 3 spatial ones represent the direction.
+* key point about simple [[harmonic oscillator]] (SHO): the height position _itself_ provides the acceleration force pulling back -- this is even simpler than a wave! So there is a 4 vector of SHO that represent the momentum of the particle, and are coupled to the wave variables! The time-like one is the "heartbeat" of the particle, representing the rest mass, while the 3 spatial ones represent the velocity direction.
+
+* each velocity axis (X,Y,Z) has a phase relative to the central time-like beat, and this phase represents the -1..+1 velocity value. This phase relationship is now demonstrated in [[complex KG]]. The extreme nutrino-level particle would have the extreme case. There would have to be some kind of coordination across the 3 pairs, so the total norm could not exceed 1.
+
+* the resting state is all four oscillating in sync with 0 phase, and then forces act by boosting or lagging an axis wave relative to the central one. this could be pretty natural. the amount of boost needs to be dependent on existing phase to capture relativistic effects.
+
+* the wave oscillation frequency is determined by the relativistic E^2 energy which goes up as momentum increases. This captures the key momentum / frequency relationship with QM. Never quite gets to CSq with massive particles.
+
+* probability of jumping is then proportional to these values. can just implement that. it might emerge more naturally from some kind of phase offset dynamic, but that can be a later stage.
+
+* coupling to surrounding wave is directly via drive from the central time-like oscillator, which provides the driving input to the field in its neighborhood.
 
-* How does it represent both positive and negative directions? In phase relationship with the center? maybe they all just oscillate the same and it is ONLY the phase relationship? An acceleration kick just bumps the phase? doesn't capture the conservation dynamics among the SHOs.
+* An acceleration kick just bumps the phase? doesn't capture the conservation dynamics among the SHOs.
 
 Weyl wave couples spin with direction as a helical thing.
 
 There is a literature on coupling of a stochastic particle with a "heat bath", somewhat like the [[zero-point]] field, and trying to understand the aggregate behavior of such a system. [[@^DunkelHanggi05a]], [[@DunkelHanggi05]] provide a relatively accessible treatment, building on foundational work ([[@Dudley65]], [[@Dudley73]], [[@GuerraRuggiero78]], [[@Nakagomi88]]). This all builds on Langevin equations, which are stochastic equations of motion, with connections to Ornstein-Ullenbach and Fokker-Planck etc. The specific restriction to heat bath dynamics vs. some kind of other intrinsic stochastic process is perhaps overly restrictive, but they nevertheless have a four-vector representation that seems to involve a conservation of energy between the time and momentum factors, which is really the essential calculus for the SHO model.
 
-One key "no-go" finding from [[@^Dudley65]] is that a purely markovian position-based system doesn't capture particle motion -- you _need_ an additional momentum / velocity vector as part of the state. This is definitely key.
+One key "no-go" finding from [[@^Dudley65]] is that a purely Markovian position-based system doesn't capture particle motion -- you _need_ an additional momentum / velocity vector as part of the state. This is definitely key.
 
 * compton wavelength as function of rest mass -- does this fall out?
 * $\nu$ is already 0-c normalized -- v/c

content/waves-simulation.md

@@ -8,9 +8,12 @@ bibfile = "mechphys.json"
 wavesim.Embed(b,
 	func(sim *wavesim.Sim) { // config
         sim.Config.GPU = true
-		sim.Config.Equation = wavesim.Wave1D
+		sim.Params.C = 1
+		sim.Params.ThreeD.SetBool(false)
+		sim.Config.Equation = wavesim.Wave
 		sim.Config.Size.Set(80, 1, 1)
 		sim.ViewInit(wavesim.Wave1DViewAll)
+		sim.WaveStats()
 	},
 	func(sim *wavesim.Sim) { // init
 		sim.PosWavePacket(wavesim.WavePos, math32.X, math32.Vec3i(40, 0, 0), -1, 8, 8, 0, 1.5)

content/waves.md

@@ -40,7 +40,7 @@ $$
 a = \frac{f}{m}
 $$
 
-In the discrete time framework, we can simply increment a new *velocity* term *v* by this acceleration:
+In the discrete time framework, we can simply increment a new _velocity_ term _v_ by this acceleration:
 
 {id="eq_" title="new velocity"}
 $$

go.mod

@@ -4,11 +4,11 @@ go 1.25.6
 
 require (
 	cogentcore.org/core v0.3.38
-	github.com/WaveReality/waves v0.0.4
+	github.com/WaveReality/waves v0.0.5
 )
 
 require (
-	cogentcore.org/lab v0.1.16 // indirect
+	cogentcore.org/lab v0.1.18 // indirect
 	github.com/Bios-Marcel/wastebasket/v2 v2.0.3 // indirect
 	github.com/Masterminds/vcs v1.13.3 // indirect
 	github.com/adrg/strutil v0.3.1 // indirect

go.sum

@@ -1,17 +1,17 @@
 codeberg.org/go-pdf/fpdf v0.11.1 h1:U8+coOTDVLxHIXZgGvkfQEi/q0hYHYvEHFuGNX2GzGs=
 codeberg.org/go-pdf/fpdf v0.11.1/go.mod h1:Y0DGRAdZ0OmnZPvjbMp/1bYxmIPxm0ws4tfoPOc4LjU=
-cogentcore.org/core v0.3.37 h1:YZyUbeRTr/jpVjKyV6pHFfzsyHt/fPcsH787N3LDlVQ=
-cogentcore.org/core v0.3.37/go.mod h1:11/KD463R4oHAcGyCEi/BLrABrX14nOYO5O4qLI+Zzg=
-cogentcore.org/lab v0.1.16 h1:TL/6rxEyeb9t2D9juMB9herUqLkU69NCZXKOn+DTSXE=
-cogentcore.org/lab v0.1.16/go.mod h1:Jm1CU2TnOZPAtxl/33RBe8keqMpM1BELMT+yAzU+J90=
+cogentcore.org/core v0.3.38 h1:uJe9PbuGYOK0h6AO/YK/LLz/c3iyKD7IYXtUR0Yt608=
+cogentcore.org/core v0.3.38/go.mod h1:11/KD463R4oHAcGyCEi/BLrABrX14nOYO5O4qLI+Zzg=
+cogentcore.org/lab v0.1.18 h1:caI1Uc4J9ceEviI+HgslGmuovvlzgqdNeyCTzOf5Z/E=
+cogentcore.org/lab v0.1.18/go.mod h1:jyZAg/wP3WUOvfNzDjaV2LuYz258UQEIdVB72yQ/p1I=
 git.sr.ht/~sbinet/overlayfs v0.1.1 h1:HvCHXT1cs8RMSjNLQXxPPosB2hgR3tRC8RniH0f3ESg=
 git.sr.ht/~sbinet/overlayfs v0.1.1/go.mod h1:TmrIWKlxyPJJ7vchTqk85DUcW6IDsIa7ONLvSGIw438=
 github.com/Bios-Marcel/wastebasket/v2 v2.0.3 h1:TkoDPcSqluhLGE+EssHu7UGmLgUEkWg7kNyHyyJ3Q9g=
 github.com/Bios-Marcel/wastebasket/v2 v2.0.3/go.mod h1:769oPCv6eH7ugl90DYIsWwjZh4hgNmMS3Zuhe1bH6KU=
 github.com/Masterminds/vcs v1.13.3 h1:IIA2aBdXvfbIM+yl/eTnL4hb1XwdpvuQLglAix1gweE=
 github.com/Masterminds/vcs v1.13.3/go.mod h1:TiE7xuEjl1N4j016moRd6vezp6e6Lz23gypeXfzXeW8=
-github.com/WaveReality/waves v0.0.3 h1:JsDhFCAEuaIW0gEIzqYg4/9GX6rQGpygV8qU5W4+LbE=
-github.com/WaveReality/waves v0.0.3/go.mod h1:KGk0G9rcpVP/lWMnMN4jmX9tcLZjGiMwIFMUfkDz8/8=
+github.com/WaveReality/waves v0.0.5 h1:jugQLUs59Txft4OwapSTeyOGLuBKzV6DQs9vTpmqR2g=
+github.com/WaveReality/waves v0.0.5/go.mod h1:qVdxjX78Ea2rLOaBc89xgoOQp7EVEaNoLPrYV6ZPNAA=
 github.com/adrg/strutil v0.3.1 h1:OLvSS7CSJO8lBii4YmBt8jiK9QOtB9CzCzwl4Ic/Fz4=
 github.com/adrg/strutil v0.3.1/go.mod h1:8h90y18QLrs11IBffcGX3NW/GFBXCMcNg4M7H6MspPA=
 github.com/alecthomas/assert/v2 v2.11.0 h1:2Q9r3ki8+JYXvGsDyBXwH3LcJ+WK5D0gc5E8vS6K3D0=