[David Cooper]

I've got another new version of the program ready for you. The nudges are now saved up and added to the accelerations caused by bar arrivals and are acted on only at those times - this removes the problem of some of the distance that the particles should be covering being lost, but there is still a bug which leads to energy going missing, to the point that a particle occasionally fails completely to respond to the movement of the other, and I don't know why that's happening. It may take a long time to work out where the fault is, but it tends to happen more often when there are multiple nudges, so it's possible that it involves an acceleration shifting to a different time slice due to the longer delay in the leading particle receiving the information, in which case that might allow it to cancel out an opposite acceleration and thereby eliminate both entirely.

A new problem shows up though in the way that when one particle moves towards the other, the latter responds by moving slightly further - this is the result of it taking longer for each bar to reach it and update its speed, so even though the accelerations and speeds are the same each time, the lengths of time that it's moving at a higher speed for are longer for the leading particle and the gap opens. This is a direct result of the difference in the speed of light relative to the particles in opposite directions - the starts and stops are all on bar arrivals and their spacing is further apart for the leading particle and reduced for the following one. I think this is an unavoidable consequence of your theory.

In my model, real particles can move only during the time they are sending a wave.

The program could be altered to save up the acceleration changes and add them at those times, but if these emissions of bars are also triggered by arrivals of bars, then that is the real trigger.

If they can be accelerated during that time, it is because the force exerted on a particle succeeds to overcome the blueshift its motion produces immediately on the light from the other particle, but when no force is exerted, thus when the particles are on constant motion, they automatically send their bars at the same time they receive the ones from the other particle. It means that a nudge has to take place between two bars: the particle has to begin moving at the instant the first bar is sent, and it has to stop moving at the instant the following bar is sent. If we want to be able to nudge two times in a row, there must thus be a way to keep the nudge button on, otherwise at least one bar will be sent without the second nudge being produced.

I'm having trouble following that. I want to see it as a clear list of rules. If the two particles are playing ping-pong with a single bar, it's easy (but very unresponsive - maybe that doesn't matter). If there are more bars on the go at the same time, it's more complex. Two nudges could spark off separate bars that would bounce to and fro between the two particles. Three nudges would result in there being three.

I was talking about the deceleration A would suffer when acceleration would stop, and I think you are talking about the acceleration B would suffer after A would have been accelerated. It's easy for B to copy-paste the blueshift from A, but how could A know how long it took the get the speed it has gotten? If it had to decelerate in the same time it took to accelerate, how would it proceed if it cannot know that time? We could consider that A decelerates to rest after each nudge, but it means that the second nudge in a row would have to be twice as important as the first one if we want the acceleration to stay constant. We can cheat and do as if the particles would have already found the solution, because we can play with the variables and force them to remember all the nudges, but we would then have to create an infinite number of variables, and we can't.

We have a system where particles jump in speed without doing any speeds in between, so no time is taken for any of the accelerations. What we have is a system that passes on information about speed differences and which changes the speed of each particle by those differences in an attempt to eliminate them, but the delays in reaction lead to this repeatedly recreating the differences forever. That's all it does.

What do I do meanwhile? Decelerate to rest or freeze and wait for the next nudge to come in? :0)  Know what? I tried to put b=0 and it works. I now have more time to observe the motion before that particle gets out of sight. Didn't succeed to produce the fifteen bars before the first one hits B though, but I'm working on it. Still trying to erase the bars when they hit a particle, a move I have to do before I can show all the bars and observe doppler effect becoming a cause.

If you hold down a Ctrl key and type "-" you may be able to see more on the screen when the particles would otherwise have left it. Ctrl with "+" zooms in again (while Ctrl with "0" takes it back to normal size in one go). If the visible bars are to disappear after a hit, you would have to detect the hit and then move them out of the way, preferably far off the left of the screen so that they stay out of sight until they are reused.

Code: [Select]

<HTML>
<HEAD>
<TITLE>Theory Simulation</TITLE>

<script type="text/javascript">

window.setInterval("run()",8) // controls repetition rate

function run()
{ t+=gr; // advance time by granularity unit
ty+=gr; tb+=gr // advance time counters too

// next we'll update the bar positions

r+=rv*gr; g+=gv*gr; // first move the visible bars

r1+=rv*gr; g1+=gv*gr; // then the hidden bars
r2+=rv*gr; g2+=gv*gr;
r3+=rv*gr; g3+=gv*gr;
r4+=rv*gr; g4+=gv*gr;
r5+=rv*gr; g5+=gv*gr;
r6+=rv*gr; g6+=gv*gr;
r7+=rv*gr; g7+=gv*gr;
r8+=rv*gr; g8+=gv*gr;
r9+=rv*gr; g9+=gv*gr;
r10+=rv*gr; g10+=gv*gr;
r11+=rv*gr; g11+=gv*gr;
r12+=rv*gr; g12+=gv*gr;
r13+=rv*gr; g13+=gv*gr;
r14+=rv*gr; g14+=gv*gr;
r15+=rv*gr; g15+=gv*gr;

// Next part reuses old bars for new ones, and it stores
// speed of particle at time of new bar emission.

if(ty>=fb){if(srb==16){srb=0} // identify bar to reuse
   ty=0; // reset count for the next reuse of a bar
   if(srb==0){r=b; cdr=0; pbv=bv}
   else{if(srb==1){r1=b; cdr1=0; pbv1=bv}
   else{if(srb==2){r2=b; cdr2=0; pbv2=bv}
   else{if(srb==3){r3=b; cdr3=0; pbv3=bv}
   else{if(srb==4){r4=b; cdr4=0; pbv4=bv}
   else{if(srb==5){r5=b; cdr5=0; pbv5=bv}
   else{if(srb==6){r6=b; cdr6=0; pbv6=bv}
   else{if(srb==7){r7=b; cdr7=0; pbv7=bv}
   else{if(srb==8){r8=b; cdr8=0; pbv8=bv}
   else{if(srb==9){r9=b; cdr9=0; pbv9=bv}
   else{if(srb==10){r10=b; cdr10=0; pbv10=bv}
   else{if(srb==11){r11=b; cdr11=0; pbv11=bv}
   else{if(srb==12){r12=b; cdr12=0; pbv12=bv}
   else{if(srb==13){r13=b; cdr13=0; pbv13=bv}
   else{if(srb==14){r14=b; cdr14=0; pbv14=bv}
   else{r15=b; cdr15=0; pbv15=bv;
   }}}}}}}}}}}}}}}
  srb+=1}
if(tb>=fy){if(sgb==16){sgb=0} // same for green bars
   tb=0;
   if(sgb==0){g=y; cdg=0; pyv=yv}
   else{if(sgb==1){g1=y; cdg1=0; pyv1=yv}
   else{if(sgb==2){g2=y; cdg2=0; pyv2=yv}
   else{if(sgb==3){g3=y; cdg3=0; pyv3=yv}
   else{if(sgb==4){g4=y; cdg4=0; pyv4=yv}
   else{if(sgb==5){g5=y; cdg5=0; pyv5=yv}
   else{if(sgb==6){g6=y; cdg6=0; pyv6=yv}
   else{if(sgb==7){g7=y; cdg7=0; pyv7=yv}
   else{if(sgb==8){g8=y; cdg8=0; pyv8=yv}
   else{if(sgb==9){g9=y; cdg9=0; pyv9=yv}
   else{if(sgb==10){g10=y; cdg10=0; pyv10=yv}
   else{if(sgb==11){g11=y; cdg11=0; pyv11=yv}
   else{if(sgb==12){g12=y; cdg12=0; pyv12=yv}
   else{if(sgb==13){g13=y; cdg13=0; pyv13=yv}
   else{if(sgb==14){g14=y; cdg14=0; pyv14=yv}
   else{g15=y; cdg15=0; pyv15=yv;
   }}}}}}}}}}}}}}}
  sgb+=1}

// Now we apply any accelerations & update particle positions

ha=0.5*ya*a // get half y's acceleration value
y+=yv+ha; // add y's old velocity+ha to its position
yv+=ya*a; // add y's acceleration value to its velocity
ha=0.5*ba*a // get half b's acceleration value
b+=bv+ha; // add b's velocity+ha to its position
bv+=ba*a; // add b's acceleration value to its velocity

ya=0; ba=0; // prevent repeat accelerations for same bar

// and now we update screen positions

ir.style.left=r*4+ro; // calculate bars' newscreen position
ig.style.left=g*4+go; // (4 units = one picometre)
iy.style.left=y*4; // calculate particle screen positions
ib.style.left=b*4+bo;
yloc.innerHTML=y; bloc.innerHTML=b; // update screen data
sep.innerHTML=b-y;
ping1.innerHTML=yv; ping2.innerHTML=bv;

// And then we have to deal with bars hitting particles
// This used to be done in a separate function called cd()
// (the "cd" part standing for collision detection)

if(r<=y && cdr==0){ya=ny+pbv-yv; ny=0; cdr=1}
if(g>=b && cdg==0){ba=nb+pyv-bv; nb=0; cdg=1}
if(r1<=y && cdr1==0){ya=ny+pbv1-yv; ny=0; cdr1=1}
if(g1>=b && cdg1==0){ba=nb+pyv1-bv; nb=0; cdg1=1}
if(r2<=y && cdr2==0){ya=ny+pbv2-yv; ny=0; cdr2=1}
if(g2>=b && cdg2==0){ba=nb+pyv2-bv; nb=0; cdg2=1}
if(r3<=y && cdr3==0){ya=ny+pbv3-yv; ny=0; cdr3=1}
if(g3>=b && cdg3==0){ba=nb+pyv3-bv; nb=0; cdg3=1}
if(r4<=y && cdr4==0){ya=ny+pbv4-yv; ny=0; cdr4=1}
if(g4>=b && cdg4==0){ba=nb+pyv4-bv; nb=0; cdg4=1}
if(r5<=y && cdr5==0){ya=ny+pbv5-yv; ny=0; cdr5=1}
if(g5>=b && cdg5==0){ba=nb+pyv5-bv; nb=0; cdg5=1}
if(r6<=y && cdr6==0){ya=ny+pbv6-yv; ny=0; cdr6=1}
if(g6>=b && cdg6==0){ba=nb+pyv6-bv; nb=0; cdg6=1}
if(r7<=y && cdr7==0){ya=ny+pbv7-yv; ny=0; cdr7=1}
if(g7>=b && cdg7==0){ba=nb+pyv7-bv; nb=0; cdg7=1}
if(r8<=y && cdr8==0){ya=ny+pbv8-yv; ny=0; cdr8=1}
if(g8>=b && cdg8==0){ba=nb+pyv8-bv; nb=0; cdg8=1}
if(r9<=y && cdr9==0){ya=ny+pbv9-yv; ny=0; cdr9=1}
if(g9>=b && cdg9==0){ba=nb+pyv9-bv; nb=0; cdg9=1}
if(r10<=y && cdr10==0){ya=ny+pbv10-yv; ny=0; cdr10=1}
if(g10>=b && cdg10==0){ba=nb+pyv10-bv; nb=0; cdg10=1}
if(r11<=y && cdr11==0){ya=ny+pbv11-yv; ny=0; cdr11=1}
if(g11>=b && cdg11==0){ba=nb+pyv11-bv; nb=0; cdg11=1}
if(r12<=y && cdr12==0){ya=ny+pbv12-yv; ny=0; cdr12=1}
if(g12>=b && cdg12==0){ba=nb+pyv12-bv; nb=0; cdg12=1}
if(r13<=y && cdr13==0){ya=ny+pbv13-yv; ny=0; cdr13=1}
if(g13>=b && cdg13==0){ba=nb+pyv13-bv; nb=0; cdg13=1}
if(r14<=y && cdr14==0){ya=ny+pbv14-yv; ny=0; cdr14=1}
if(g14>=b && cdg14==0){ba=nb+pyv14-bv; nb=0; cdg14=1}
if(r15<=y && cdr15==0){ya=ny+pbv15-yv; ny=0; cdr15=1}
if(g15>=b && cdg15==0){ba=nb+pyv15-bv; nb=0; cdg15=1}

}

function setup() // we might use this later
{ }

// All variables are created and initialised here:-

c=0.3 // speed of light in pm/zs.

gr=1; // granularity for simulation in zeptoseconds
      // we can adjust this to speed/slow the action

y=-100; b=0; // initial x-coord locations of the dots
        bo=-50; // offset to correct b's display location
yv=0; bv=0; // set initial speeds for particles
pyv=0; pbv=0; // particle speeds when light bars sent out

// more vars like pyv and pbv for hidden bars

pyv1=0; pbv1=0; pyv2=0; pbv2=0; pyv3=0; pbv3=0;
pyv4=0; pbv4=0; pyv5=0; pbv5=0; pyv6=0; pbv6=0;
pyv7=0; pbv7=0; pyv8=0; pbv8=0; pyv9=0; pbv9=0;
pyv10=0; pbv10=0; pyv11=0; pbv11=0; pyv12=0; pbv12=0;
pyv13=0; pbv13=0; pyv14=0; pbv14=0; pyv15=0; pbv15=0;

srb=1; sgb=1; // to keep track of which bars last sent
rrb=1; rgb=1; // to keep track of which bars last received
// srb = sent red bar, sgb = sent green bar, rrb = received red...
// These will count up 1, 2, 3, 0, 1, 2, 3, 0, etc.
// or up to 7 before going back to 0, or up to 15.

r=0; g=-100; // initial locations of the bars
ro=-87; go=-112; // offsets to correct bar display loc.s
rv=-c; gv=c; // speeds for bars

// more vars like r and g for hidden bars:-

r1=0; g1=0; r2=0; g2=0; r3=0; g3=0; r4=0; g4=0; r5=0; g5=0;
r6=0; g6=0; r7=0; g7=0; r8=0; g8=0; r9=0; g9=0; r10=0; g10=0;
r11=0; g11=0; r12=0; g12=0; r13=0; g13=0; r14=0; g14=0; r15=0; g15=0;

t=0; // time in zeptoseconds
ty=0; // timer to emit new bars from yellow particle
tb=0; // and another for blue particle
d=200; // distance in picometres
fy=64; // initial bonding-light "frequencies"
fb=64; // (one for each particle) [1000 = 1x10^18Hz]
// These aren't frequencies, but no. of zeptoseconds/cycle
// Now using 250 to have four bars per cycle, three hidden.

a=1; // acceleration strength factor
ha=0; // variable to store a value temporarily
ya=0; // acceleration value applying to yellow
ba=0; // acceleration value for blue particle
ny=0; nb=0; // nudge acceleration values


cdr=0;cdg=0; // collision detection var.s - these are used to
     // restrict it to one registered hit each time to
     // avoid false hits after bar has passed particle

// more vars like cdr and cdg for hidden bars:-

cdr1=0; cdg1=0; cdr2=0; cdg2=0; cdr3=0; cdg3=0;
cdr4=0; cdg4=0; cdr5=0; cdg5=0; cdr6=0; cdg6=0;
cdr7=0; cdg7=0; cdr8=0; cdg8=0; cdr9=0; cdg9=0;
cdr10=0; cdg10=0; cdr10=0; cdg10=0; cdr11=0; cdg11=0;
cdr12=0; cdg12=0; cdr13=0; cdg13=0; cdr14=0; cdg14=0;
cdr13=0; cdg15=0;

// (milli, micro, nano, pico, femto, atto, zepto)


function inca() // increase strength of acceleration force
{ a*=2; force.innerHTML=a}

function deca() // decrease strength of acceleration force
{ a*=0.5; force.innerHTML=a}

function nudgeyl() // accelerate y to right
{ ny-=0.05}

function nudgeyr() // accelerate y to right
{ ny+=0.05}

function nudgebl() // accelerate b to left
{ nb-=0.05}

function nudgebr() // accelerate b to left
{ nb+=0.05}

function nudgeyrbl() // accelerate b to left
{ ny+=0.05; nb-=0.05}

</script>

</HEAD>

<BODY onload="setup()" style="background-color:black;color:white;font-family:arial,helvetica,sans-serif;font-size:18pt"><blockquote>
<center><H1>Theory Simulation</H1><br><br>

<tt>

<b id="iy" style="position:relative;left:-400;top:0;font-size:60;color:yellow">.</b>
<b id="ib" style="position:relative;left:350;top:0;font-size:60;color:#0020ff">.</b>
<b id="ir" style="position:relative;left:313;top:2;font-size:18;color:red">|</b>
<b id="ig" style="position:relative;left:-512;top:2;font-size:18;color:#00ff00">|</b>

</tt></center>

<p>Yellow's location = <a id="yloc"></a>
<br>Blue's location = <a id="bloc"></a>
<br>Distance apart = <a id="sep"></a>
<p>Latest speed of yellow particle = <a id="ping1"></a>
<br>Latest speed of blue particle = <a id="ping2"></a>
<p>Damping value = <a id="force">1</a>
<p> <input type="button" value="Damp less" onclick="inca()"/> <input type="button" value="Damp more" onclick="deca()"/> <input type="button" value="Nudge yellow left" onclick="nudgeyl()"/> <input type="button" value="Nudge yellow right" onclick="nudgeyr()"/> <input type="button" value="Nudge blue left" onclick="nudgebl()"/> <input type="button" value="Nudge blue right" onclick="nudgebr()"/> <input type="button" value="Nudge both together" onclick="nudgeyrbl()"/>
<p>
Click a "nudge" button to start things moving.

</BODY>
</HTML>

[Le Repteux (OP)]

You read my mind! I forgot to ask you to display the distance in my previous message. :0) The button to nudge both ways at a time is interesting too.

I just realize that quantum effects at the scale of particles cannot be the cause for what we observe at our scale. Accelerating a body at our scale takes a lot more time than at the scale of particles, so light has the time to make the roundtrip between particles billions of times during the slightest acceleration at our scale. In fact, what we are trying to do is get rid of the quantum uncertainty. The real way to do it would be to simulate a bunch of particles and let each of them chose its own speed and direction when we accelerate the bunch. Statistically, only some of them would find the right direction and speed at first, but all of them would finally find it after a while if the acceleration would go on, a while that would look very long at the particles' scale, but very short at our scale. Unless we find a way to predict the future of a unique particle, we can only simulate the case where, by chance, it finds the right way instantly.

It means that we can decelerate A the same way we have accelerated it, as if it could remember the past, and as if the past could always tell it what to do when it faces a change. Since B moves the same way A did before, A can forget about the way it decelerated once it has, because B will automatically behave like A when its waves will hit it and so on afterwards. What we need then is a way to remember the distance traveled by A between each bar it sends during the time it is accelerated, and decelerate it in reverse order when the acceleration stops. With an acceleration shorter than fifteen bars, it should work, but we can easily see that it would take a prohibitive number of variables to account for a long acceleration. There may be a way to create and destroy variables using conditional operators, but even so, it would be impossible to account for all the possibilities that could happen, and that's what that kind of simulation would have to do. Nevertheless, simulating a limited number of bars this way should give people a good idea of what that theory on motion is about.

A new problem shows up though in the way that when one particle moves towards the other, the latter responds by moving slightly further - this is the result of it taking longer for each bar to reach it and update its speed, so even though the accelerations and speeds are the same each time, the lengths of time that it's moving at a higher speed are longer for the leading particle and the gap opens. This is a direct result of the difference in the speed of light relative to the particles in opposite directions - the starts and stops are all on bar arrivals and their spacing is further apart for the leading particle and reduced for the following one. I think this is an unavoidable consequence of your theory.

If such a motion would really be happening between the particles, it may mean that the distance between bodies would be increasing with time without them being able to measure it, so it might be the cause for gravitation if that motion was still executed by the particles trying to stay on sync with others even when they are very far away from one another.

[David Cooper]

I just realize that quantum effects at the scale of particles cannot be the cause for what we observe at our scale. Accelerating a body at our scale takes a lot more time than at the scale of particles, so light has the time to make the roundtrip between particles billions of times during the slightest acceleration at our scale. In fact, what we are trying to do is get rid of the quantum uncertainty. The real way to do it would be to simulate a bunch of particles and let each of them chose its own speed and direction when we accelerate the bunch. Statistically, only some of them would find the right direction and speed at first, but all of them would finally find it after a while if the acceleration would go on, a while that would look very long at the particles' scale, but very short at our scale. Unless we find a way to predict the future of a unique particle, we can only simulate the case where, by chance, it finds the right way instantly.

If you have an object made of a thousand atoms, you should be able to accelerate the whole thing (because it's bonded together) just by nudging one of its atoms, and it may well be that when you do this with one nudge, the atoms move around in the way your theory suggests with only one of them moving at a time. If you give that atom another nudge when it isn't moving, you'll then have two of the atoms moving at a time. If you nudge it again while it's already moving, that atom will move more violently and pass that violent movement on to another atom. If you make millions of random nudges to it, you will make some of them at times when it isn't moving and others when it is already moving, and later on in this process, most of those nudges will be done when it is already moving, and indeed, most of the atoms will be moving by this time. Keep on nudging it, and, sooner or later, all of the atoms will already be moving, so your nudges will keep giving the same atom a kick which it then transfers on, slowing back down to the speed it was doing before that nudge. That probably does represent how the universe really works, and the differences in speeds of the atoms in the object represent heat. A smooth acceleration where all the atoms are nudged more evenly will generate less heat. The heat that you generate by kicking the object unevenly doesn't transfer into faster movement of the object, so it's wasted effort, and the heat eventually radiates off. That may all fit with your theory (unless you always want particles to be slowed to zero when they're decelerated), but the mechanisms for transferring the energy between atoms are a different matter, and clearly there is something missing from your theory in that it cannot distinguish between bonded atoms/particles and unbonded ones. That lack may not matter much at the moment though as what you want to explore is just the business of how the energy might be transferred.

What we need then is a way to remember the distance traveled by A between each bar it sends during the time it is accelerated, and decelerate it in reverse order when the acceleration stops.

Shouldn't the deceleration be entirely controlled by its relative movement to B when it receives a signal from B? If it always decelerates in the same way as it previously accelerated, it will end up back at zero speed and an object will never be able to reach the speed of half c.

There may be a way to create and destroy variables using conditional operators, but even so, it would be impossible to account for all the possibilities that could happen, and that's what that kind of simulation would have to do.

There is an instruction called "eval" (evaluate) which lets you write code that generates new code, and this can be used to generate new variables whenever they're needed so that the programmer doesn't have to make them all directly, and you can also create infinite arrays of variables more directly, but you soon run into speed limits with JavaScript - complexity translates into slow, so it's better to switch to a different programming language (and lose the convenience of JavaScript that allows our little programs here to run easily on each other's machines). But we don't need high complexity yet.

If such a motion would really be happening between the particles, it may mean that the distance between bodies would be increasing with time without them being able to measure it, so it might be the cause for gravitation if that motion was still executed by the particles trying to stay on sync with others even when they are very far away from one another.

I may have been wrong when I said "I think this is an unavoidable consequence of your theory" - it is only an unavoidable consequence of my way of attempting to do something approximating your theory. If we just have one bar per nudge though, that bar will bounce back and forth between the particles in a way that might not lead to such an increase in distance between the particles, so I think it needs to be programmed as an alternative approach to the one I've explored so far. I'll work on that and see what happens - I think it may be closer to what you want to do, though it's hard to be sure until you produce a list of clear rules for me to act on. The rules I have in mind for this new program are as follows:-

(1) Whenever a particle is nudged, it changes its speed accordingly and sends out a bar towards the other particle to tell it that its speed has changed.

(2) Whenever a particle receives a bar, it looks at the energy of the bar (which relates directly to the relative speeds of the two particles [after any previous accelerations have been applied]), calculates a new speed for itself accordingly, and then it sends a new bar back.

These two rules should be sufficient to drive the model. The particles will keep taking turns to speed up and slow down, and the round trip will be the same for ABA as for BAB, which means the times they are moving will be equal, and so will the times that they're stationary. If A is nudged to the right, the average distance between them will be decreased, but it will alternate between two values, one of which will be the original separation. If B is nudged to the right instead though, the average distance between them will be increased while it alternates between two values, the lower of which will be the original separation. Every new nudge would create a new bar, and the bars would continue to exist for so long as they don't coincide in time - any that do coincide can be merged into one bar. Bars that are near each other could optionally be merged too, though that would introduce some damping, but it might be worth doing to limit the maximum number of bars that the program has to handle.

[Le Repteux (OP)]

Shouldn't the deceleration be entirely controlled by its relative movement to B when it receives a signal from B?

Stopping the acceleration of A before its light accelerates B is a good way to study the way deceleration could happen. Will A decelerate at the same rate if doppler effect is strong than if it is weak? Maybe the only way to accelerate it more than once is to wait for B to get away. There could be a threshold for the first acceleration to be permitted, and maybe many threshold to permit a variety of accelerations. Could those depend on the quantum numbers? Electrons make quantum jumps, they don't accept any quantity of energy. If an atom is hit by a light that is not at the right energy, it may as well not be affected, and the light will not be intercepted.

Such thresholds would permit a first nudge of a certain energy, but they would only permit a second nudge of the same energy when doppler effect would have gotten down because B has moved away. This way, A could decelerate in the same time it has accelerated if the nudge stops, or it could go on moving at the same speed if the nudge is still there, or it could even go on accelerating if the nudge energy would increase and hit another threshold.

(1) Whenever a particle is nudged, it changes its speed accordingly and sends out a bar towards the other particle to tell it that its speed has changed.

What does it do after having sent its bar? Has it already decelerated to rest or is it going to do so? It cannot go on moving indefinitely since it is actually producing blueshift on the light from the other particle. How about accelerating the first particle the same way A would be accelerating B, which is with doppler effect. This way, we would be forced to define a rule for a particle that is caught between two different doppler effects. If A suffers blueshift from the outside for example, it is forced to move toward B, thus to produce blueshift on the light from B until the two blueshifts become equal. Once the acceleration from the outside would decrease, A would slow down at the same rate, and it would stop moving, thus stop producing blueshift at the moment the acceleration would stop. This way, it would be the external acceleration that would tell A how to decelerate, thus the nudge would have to be given a duration and a rate of deceleration.

[David Cooper]

Stopping the acceleration of A before its light accelerates B is a good way to study the way deceleration could happen.

What rule(s) would you have to control that? How does A even know that B exists in order to know to stop without getting a signal from B? If B isn't there, A shouldn't stop, and if A doesn't get a signal from B to tell it to stop, that's the same as would happen if B doesn't exist. You need to produce a set of rational rules that dictate events.

What does it do after having sent its bar? Has it already decelerated to rest or is it going to do so?

It has just been accelerated by a nudge, so if it immediately sends out a bar and then stops, in effect it hasn't been nudged at all, but the bar will move on to the other particle and effectively nudge it instead.

How about accelerating the first particle the same way A would be accelerating B, which is with doppler effect.

Doppler effect from what? A light signal coming from a third particle? If so, how do we get it going without giving it a nudge? That nudge would be just as artificial unless we use a fourth particle to push the third one so that the third one can push particle A. But there's still a nudge needed to get the fourth particle moving, so we need an infinite series of particles pushing particles to feed into particle A, all to eliminate a nudge by moving it an infinite number of steps away. No matter how infinite the number of particles is that you use to lead up to this, at some point it takes a nudge to get things going, and it's easier to have that nudge within a finite number of particles of particle A than putting it at the other end of an infinite number of them because the latter approach means the universe will have ended before particle A starts moving. There is no alternative to an artificial nudge, and it is no different in its effect from the transfer of energy that goes from A to B, so it isn't a problem in the first place.

This way, we would be forced to define a rule for a particle that is caught between two different doppler effects.

In effect, you then have three bonded particles, which is fine - we can program for that, and we can do it in two or three dimensions instead of just the one, but you still have to nudge one using energy from something that isn't bonded to the three particles and which isn't subsequently monitored - it should not be dragged along for the ride.

If you want to work with a three particle system, you then need to work out how the middle particle reacts to the signal from A. If B speeds up and sends out a bar, does it send that bar to A or C, or does it send a bar to each of them? If it sends one to both, what effect does that have? B starts moving and sends out two bars, then those bars are received by A and C. If the bars both send the energy they would have had before a bar hit B, then A will be stopped by its bar from B and C will not move at all when it receives a bar from B (and B will keep going without emitting another bar, which means it will crash into C), but if they send the energy representing B's speed after B receives a bar, then A will keep going and C will start moving, so all three particles will be moving along at the same speed, thereby carrying three times as much kinetic energy as was given to A by the nudge. This is complicated stuff, and you need to try to work out rules setting out the cause-and-effect actions in such a way that useful results might be produced.

If A suffers blueshift from the outside for example, it is forced to move toward B, thus to produce blueshift on the light from B until the two blueshifts become equal. Once the acceleration from the outside would decrease, A would slow down at the same rate, and it would stop moving, thus stop producing blueshift at the moment the acceleration would stop. This way, it would be the external acceleration that would tell A how to decelerate, thus the nudge would have to be given a duration and a rate of deceleration.

The energy transfers between particles happen when bars hit particles, so those are instantaneous accelerations. There is no room for a sustained acceleration other than as a series of bars arriving to produce a series of instantaneous accelerations, which means a sustained nudge with a duration greater than instantaneous has to manifest itself as a series of lesser instantaneous nudges, each producing a new bar to carry the signal/energy on to the next particle.

[Le Repteux (OP)]

Stopping the acceleration of A before its light accelerates B is a good way to study the way deceleration could happen.

What rule(s) would you have to control that? How does A even know that B exists in order to know to stop without getting a signal from B? If B isn't there, A shouldn't stop, and if A doesn't get a signal from B to tell it to stop, that's the same as would happen if B doesn't exist. You need to produce a set of rational rules that dictate events.

I think you mean that A would go on moving after having been nudged since the system is not considered to be moving to begin with, and you may be right because I always considered that the particles' components would be sending light only during the time they are not on sync, thus during an acceleration. I never thought of that possibility, but it is interesting, so let's try it. It means that the resistance to acceleration of A, thus its mass, would only be caused by its components getting out of sync, the same way B gets a little bit out of sync with A when doppler effect from A begins to come in. But then, how would the resistance of B be transferred to A?  Is it possible that what we measure as mass would only represent half the volume of matter we measure? If A would go on moving after a nudge, B would do the same after a while, and both particles would be traveling at the same speed forever since they would always suffer the same doppler effect wrt the other particle. Motion is a lot simpler to understand this way, but it may mean that when we measure the mass of a molecule, we might only get half of it.

The energy transfers between particles happen when bars hit particles, so those are instantaneous accelerations. There is no room for a sustained acceleration other than as a series of bars arriving to produce a series of instantaneous accelerations, which means a sustained nudge with a duration greater than instantaneous has to manifest itself as a series of lesser instantaneous nudges, each producing a new bar to carry the signal/energy on to the next particle.

That describes the way components of A would move to stay synchronized with components of B at the same time A would move to stay synchronized with B. That process should go down to infinities, which is impossible to simulate, but I think we cannot use instantaneousness either. I think the way you suggested before is good if we don't accelerate things instantly: we could nudge A a certain distance in a certain time, thus give it the speed it has at the end of that time, and make it send a bar that carries that speed to B at the end of that time too. It would then accelerate and keep its speed, so if we would nudge it a second time, that speed would increase. No need to program longer nudges this way, but it would be interesting to get back the button to change the rate of acceleration. I wonder what this system will do when we will try to stop it? I think it will simply decelerate to rest after a while. I also notice that the distance between the particles would only contract during the time A would move toward B, because that distance would simply stretch back during the time B would be accelerating away from A later on.

[David Cooper]

It's pointless to have a sustained nudge if you don't have an infinite series of bars transferring that on from there, so it should be a series of instantaneous accelerations with each transferred by its own bar. The number of bars is the limit of the resolution of the accelerations. There is probably also no need for infinite numbers of bars as ultimately energy likely has a minimum package size, and each minimum-sized lump of energy can have its own bar. Once you're dealing with hundreds of bars, there's no need to deal with millions of bars for smaller amounts of energy as there should be little difference in the results, so a simulation only needs to use a granularity that's sufficiently fine to get the same end result with as few calculations as possible.

[No new version of the simulation yet - I've been busy writing a different program to help illustrate length contraction and "time" dilation, but that's done now - you might like it: http://www.magicschoolbook.com/science/Lorentz.htm]

[Le Repteux (OP)]

Nice simulation again David. It took a while before I understood why the light was bouncing back and forth rapidly between the mirrors in the middle and at the end of the distance traveled by the green clock. I had to refer to your MMx simulation to realize it did so but at the beginning and only once, and then I saw the counter adding one each time light was hitting the correct mirror. Maybe you could add a few dots to the light path. If I get good enough at making simulations, I'll make one with light traveling sideways to the motion in a laser, hitting a mirror, and reentering the laser the same way it had left it as it does for a moving telescope. I think it would help people to understand more rapidly the two phenomenon linked to the relativistic aberration of light: the one at the source and the one at the observer.

By the way, I began restudying your first simulations, and I did not succeed to understand why the two dots were distant from one another on the screen while they are attributed the same coordinates at the beginning. I suspect it is due to the "position:relative" property that you use, and to the distance between two dots 60 pixels large, but I didn't find the exact rule.

[David Cooper]

By the way, I began restudying your first simulations, and I did not succeed to understand why the two dots were distant from one another on the screen while they are attributed the same coordinates at the beginning. I suspect it is due to the "position:relative" property that you use, and to the distance between two dots 60 pixels large, but I didn't find the exact rule.

If you create one dot, then copy and paste some more like it, giving them different names but keeping the coordinates the same, each one will appear further along to the right, so you have to change the x coordinate each time by a multiple of a set amount to make them all appear in the same place, the last of them hiding all the others underneath it. I just use trial-and-error to line up the first two, then once I know how much to adjust by, it's easy to work out the right values for the rest. I've never checked to see if there's a predictable adjustment related to each point size.

[Le Repteux (OP)]

I succeeded to build my first simulation! :0) Yellow particle sends a bar when it is nudged forward, and the same bar nudges the two particles forward later. I'm trying to tell A to wait until the bar nudges it to accept getting nudged again by pushing the button. I'm learning, it's fun, but I'm slow!

Code: [Select]

<HTML>
<HEAD>
<TITLE>Theory Simulation</TITLE>

<script type="text/javascript">

// All variables are created and initialised here:-

c=0.3;       // speed of light (and bar) in pm/zs.

y=-100; b=0; // initial x-coord locations of the dots
bo=-50;      // offset to correct b's display location

g=-100;      // initial locations of the green bar
go=-80;      // offsets to correct bar display locations

dir=0      // bar's direction of motion
my=0; mb=0   // move particles later

// (milli, micro, nano, pico, femto, atto, zepto)


window.setInterval("run()",8) // controls repetition rate

function run()

{ if(g>=b && dir==c){dir=-c; }  // change direction of bar on collision with b
if(g>=b && mb==1){b=b+1; mb=0; my=1}  // move b if y has moved, move y later
if(dir==-c){g=g-c}            // move bar to the left if direction is left

if(g<=y && dir==-c){dir=c}    // change direction of bar on collision with y
if(g<=y && my==1){y=y+1; my=0; mb=1}  // move y if b has moved, move b later
if(dir==c){g=g+c}             // move bar to the right if direction is right
   

ig.style.left=g*4+go;         // calculate bars' new screen positions
              // (4 units = 1 picometer)
 
iy.style.left=y*4;            // calculate particles' screen positions
ib.style.left=b*4+bo;
}

function moveiy()             // move yellow particle
{y=y+1; dir=c; mb=1}


</script>

</HEAD>

<BODY   style="background-color:black; color:white; font-family:arial,helvetica,sans-serif;font-size:18pt">
<blockquote>
<center>
<H1>Theory Simulation</H1>
<p>
<tt>
<b id="iy" style="position:relative; left:-400; top:0; font-size:60; color:yellow">.</b>
<b id="ib" style="position:relative; left: 350; top:0; font-size:60; color:#0020ff">.</b>
<b id="ig" style="position:relative; left:-512; top:2; font-size:18; color:#00ff00">|</b>
</tt>
</center>
<p>
<input type="button" value="Move Yellow" onclick="moveiy()"/>
<p>
Click the button to nudge yellow particle
</BODY>
</HTML>

[David Cooper]

I succeeded to build my first simulation!

I ran it last night and was just about to congratulate you on it at the time, but the Internet became inaccessible when my data ran out. I think my 4G-wifi device went off the rails a couple of days ago and used over 5GB of data in the space of a few hours while no computer was even linked to it. Had to take the battery out to reset it.

Anyway, it's good to see that you're making great progress with programming - it helps you to run ideas in your head better when you start thinking that way, giving you greater clarity of thought. And when you can't run something in your head because the complexity's too high, a program can resolve issues for you.

I've been writing a new version of the program too, and you might want to borrow some ideas from it. I allow ten bars to be used, each one being associated with a nudge, and they then keep on going forever to and fro between the two particles.

Code: [Select]

<HTML>
<HEAD>
<TITLE>Theory Simulation</TITLE>

<script type="text/javascript">

window.setInterval("run()",20) // controls repetition rate

function run()
{ if(ss==1){
t++; // advance time by 1

// next we update the bar positions
// (The ten bar direction vars are 0 for inactive,
// 1 for moving right, and 2 for moving left.)

if(d0>0){if(d0==1){l0+=c}else{l0-=c}}
if(d1>0){if(d1==1){l1+=c}else{l1-=c}}
if(d2>0){if(d2==1){l2+=c}else{l2-=c}}
if(d3>0){if(d3==1){l3+=c}else{l3-=c}}
if(d4>0){if(d4==1){l4+=c}else{l4-=c}}
if(d5>0){if(d5==1){l5+=c}else{l5-=c}}
if(d6>0){if(d6==1){l6+=c}else{l6-=c}}
if(d7>0){if(d7==1){l7+=c}else{l7-=c}}
if(d8>0){if(d8==1){l8+=c}else{l8-=c}}
if(d9>0){if(d9==1){l9+=c}else{l9-=c}}

// Then we need to detect bars hitting particles
// If any do, direction is reversed, energy is transferred,
// and new energy-to-carry value is stored for that bar.

     if(l0>=g && d0==1){d0=2; gv+=e0-gv; e0=gv}
else{if(l1>=g && d1==1){d1=2; gv+=e1-gv; e1=gv}
else{if(l2>=g && d2==1){d2=2; gv+=e2-gv; e2=gv}
else{if(l3>=g && d3==1){d3=2; gv+=e3-gv; e3=gv}
else{if(l4>=g && d4==1){d4=2; gv+=e4-gv; e4=gv}
else{if(l5>=g && d5==1){d5=2; gv+=e5-gv; e5=gv}
else{if(l6>=g && d6==1){d6=2; gv+=e6-gv; e6=gv}
else{if(l7>=g && d7==1){d7=2; gv+=e7-gv; e7=gv}
else{if(l8>=g && d8==1){d8=2; gv+=e8-gv; e8=gv}
else{if(l9>=g && d9==1){d9=2; gv+=e9-gv; e9=gv}
}}}}}}}}}
g+=gv; // move green particle

     if(l0<=r && d0==2){d0=1; rv+=e0-rv; e0=rv}
else{if(l1<=r && d1==2){d1=1; rv+=e1-rv; e1=rv}
else{if(l2<=r && d2==2){d2=1; rv+=e2-rv; e2=rv}
else{if(l3<=r && d3==2){d3=1; rv+=e3-rv; e3=rv}
else{if(l4<=r && d4==2){d4=1; rv+=e4-rv; e4=rv}
else{if(l5<=r && d5==2){d5=1; rv+=e5-rv; e5=rv}
else{if(l6<=r && d6==2){d6=1; rv+=e6-rv; e6=rv}
else{if(l7<=r && d7==2){d7=1; rv+=e7-rv; e7=rv}
else{if(l8<=r && d8==2){d8=1; rv+=e8-rv; e8=rv}
else{if(l9<=r && d9==2){d9=1; rv+=e9-rv; e9=rv}
}}}}}}}}}
r+=rv; // move red particle

// and now we update screen positions, bars first:-

b0.style.left=l0*3+l0o; b1.style.left=l1*3+l1o;
b2.style.left=l2*3+l2o; b3.style.left=l3*3+l3o;
b4.style.left=l4*3+l4o; b5.style.left=l5*3+l5o;
b6.style.left=l6*3+l6o; b7.style.left=l7*3+l7o;
b8.style.left=l8*3+l8o; b9.style.left=l9*3+l9o;

ir.style.left=r*3; // calculate particle screen positions
ig.style.left=g*3+go;
rloc.innerHTML=r; gloc.innerHTML=g; // update screen data
sep.innerHTML=g-r;
ping1.innerHTML=rv; ping2.innerHTML=gv;
}}

function setup() // we might use this later
{ }

// All variables are created and initialised here:-

c=0.3 // speed of light in pm/zs.

t=0; // time in zeptoseconds
d=100; // distance in picometres

ss=1; // stop-start variable

// dot vars:-

r=-100; g=0; // initial x-coord locations of the dots
        go=-50; // offset to correct b's display location
rv=0; gv=0; // set initial speeds for particles

  // bar vars:-

l0=-100; l1=-500; l2=-500; l3=-500; l4=-500;
l5=-500; l6=-500; l7=-500; l8=-500; l9=-500;

  // offsets to correct bar display loc.s:-

l0o=-87; l1o=-112; l2o=-137; l3o=-162; l4o=-187;
l5o=-212; l6o=-237; l7o=-262; l8o=-287; l9o=-312;

  // vars to store direction bars are moving in:-
  // (0 = inactive; 1 = moving right; 2 = moving left)

d0=0; d1=0; d2=0; d3=0; d4=0; d5=0; d6=0; d7=0; d8=0; d9=0;

  // vars to store the energy that bars are carrying:-

e0=0; e1=0; e2=0; e3=0; e4=0; e5=0; e6=0; e7=0; e8=0; e9=0;

b=0; // keep track of how many bars are in use


// (milli, micro, nano, pico, femto, atto, zepto)


function nujrl() // accelerate r to left
{ b+=1;
if(b==1){d0=1; e0=-0.02; l0=r; rv-=0.02}
if(b==2){d1=1; e1=rv-0.02; l1=r; rv-=0.02}
if(b==3){d2=1; e2=rv-0.02; l2=r; rv-=0.02}
if(b==4){d3=1; e3=rv-0.02; l3=r; rv-=0.02}
if(b==5){d4=1; e4=rv-0.02; l4=r; rv-=0.02}
if(b==6){d5=1; e5=rv-0.02; l5=r; rv-=0.02}
if(b==7){d6=1; e6=rv-0.02; l6=r; rv-=0.02}
if(b==8){d7=1; e7=rv-0.02; l7=r; rv-=0.02}
if(b==9){d8=1; e8=rv-0.02; l8=r; rv-=0.02}
if(b==10){d9=1; e9=rv-0.02; l9=r; rv-=0.02}
}

function nujrr() // accelerate r to right
{ b+=1;
if(b==1){d0=1; e0=0.02; l0=r; rv+=0.02}
if(b==2){d1=1; e1=rv+0.02; l1=r; rv+=0.02}
if(b==3){d2=1; e2=rv+0.02; l2=r; rv+=0.02}
if(b==4){d3=1; e3=rv+0.02; l3=r; rv+=0.02}
if(b==5){d4=1; e4=rv+0.02; l4=r; rv+=0.02}
if(b==6){d5=1; e5=rv+0.02; l5=r; rv+=0.02}
if(b==7){d6=1; e6=rv+0.02; l6=r; rv+=0.02}
if(b==8){d7=1; e7=rv+0.02; l7=r; rv+=0.02}
if(b==9){d8=1; e8=rv+0.02; l8=r; rv+=0.02}
if(b==10){d9=1; e9=rv+0.02; l9=r; rv+=0.02}
}

function nujgl() // accelerate g to left
{ b+=1;
if(b==1){d0=2; e0=-0.02; l0=g; gv-=0.02}
if(b==2){d1=2; e1=gv-0.02; l1=g; gv-=0.02}
if(b==3){d2=2; e2=gv-0.02; l2=g; gv-=0.02}
if(b==4){d3=2; e3=gv-0.02; l3=g; gv-=0.02}
if(b==5){d4=2; e4=gv-0.02; l4=g; gv-=0.02}
if(b==6){d5=2; e5=gv-0.02; l5=g; gv-=0.02}
if(b==7){d6=2; e6=gv-0.02; l6=g; gv-=0.02}
if(b==8){d7=2; e7=gv-0.02; l7=g; gv-=0.02}
if(b==9){d8=2; e8=gv-0.02; l8=g; gv-=0.02}
if(b==10){d9=2; e9=gv-0.02; l9=g; gv-=0.02}
}

function nujgr() // accelerate g to right
{ b+=1;
if(b==1){d0=1; e0=0.02; l0=g; gv+=0.02}
if(b==2){d1=1; e1=gv+0.02; l1=g; gv+=0.02}
if(b==3){d2=1; e2=gv+0.02; l2=g; gv+=0.02}
if(b==4){d3=1; e3=gv+0.02; l3=g; gv+=0.02}
if(b==5){d4=1; e4=gv+0.02; l4=g; gv+=0.02}
if(b==6){d5=1; e5=gv+0.02; l5=g; gv+=0.02}
if(b==7){d6=1; e6=gv+0.02; l6=g; gv+=0.02}
if(b==8){d7=1; e7=gv+0.02; l7=g; gv+=0.02}
if(b==9){d8=1; e8=gv+0.02; l8=g; gv+=0.02}
if(b==10){d9=1; e9=gv+0.02; l9=g; gv+=0.02}
}

function nujb() // accelerate both together
{ nujrr(); nujgl()}

function os() // one step
{ ss=1; run(); ss=0}

function stopstart()
{ if(ss==0){ss=1}else{ss=0}}

</script>

</HEAD>

<BODY onload="setup()" style="background-color:black;color:white;font-family:arial,helvetica,sans-serif;font-size:18pt"><blockquote>
<center><H1>Theory Simulation</H1><br><br>

<tt>

<b id="ir" style="position:relative;left:-300;top:0;font-size:60;color:red">.</b>
<b id="ig" style="position:relative;left:-50;top:0; font-size:60;color:#00ff00">.</b>
<b id="b0" style="position:relative;left:-387;top:2;font-size:18;color:blue">|</b>
<b id="b1" style="position:relative;left:-412;top:2;font-size:18;color:blue">|</b>
<b id="b2" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b3" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b4" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b5" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b6" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b7" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b8" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b9" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>

</tt></center>

<p>Red's location = <a id="rloc"></a>
<br>Green's location = <a id="gloc"></a>
<br>Distance apart = <a id="sep"></a>
<p>Latest speed of red particle = <a id="ping1"></a>
<br>Latest speed of green particle = <a id="ping2"></a>
<p><input type="button" value="Nudge red left" onclick="nujrl()"/> <input type="button" value="Nudge red right" onclick="nujrr()"/> &nbsp; <input type="button" value="Nudge green left" onclick="nujgl()"/> <input type="button" value="Nudge green right" onclick="nujgr()"/> &nbsp; <input type="button" value="Nudge both together" onclick="nujb()"/> &nbsp; <input type="button" value="one step" onclick="os()"/> <input type="button" value="stop/start" onclick="stopstart()"/>
<p>
Click away!

</BODY>
</HTML>

When a bar's sent out, it carries with it a value for the speed of the particle it has left, and the difference between that value and the speed of the particle receiving it is then either added to or taken away from that particle, then the bar heads off the opposite way carrying that new value with it.

It's pretty weird, the way it behaves. If you nudge a particle to the right four times, nudging it or the other six times to the left doesn't stop the two particles moving to the right on average. It all relates to how long the particles move each way, the first four nudges to the left only stopping the movement from the previous four nudges to the right without them getting any opportunity to move them the opposite way, and even an extra two nudges to the left can't outdo the advantage of the nudges to the right occurring first.

Your way of doing it doesn't suffer from that problem because you move a particle and then stop it right away, so four movements to the right plus six to the left would always move it two places to the left regardless of the lengths of the delays between arriving bars.

[Le Repteux (OP)]

I was about to send you a version I made from my last simulation when I recieved yours. I added a bar to see the doppler effect becoming a cause for motion. I had a hard time trying to send the bars at the same place the particles were making a step. I didn't find the rule yet, and I suspect there is none. We can also see the doppler effect in action in yours, but we have to increase the speed of the particles, so I did it for the red particle. When we nudge it twice, we can see the blueshift and the redshift, and if we stop it each time we nudge it, it does a bit what mine does, except that your particles accelerate for a while whereas mine make an instant step.

Here is yours with faster speed for red particle:

Code: [Select]

<HTML>
<HEAD>
<TITLE>Theory Simulation</TITLE>

<script type="text/javascript">

window.setInterval("run()",20) // controls repetition rate

function run()
{ if(ss==1){t++; // advance time by 1

// next we update the bar positions
// (The ten bar direction vars are 0 for inactive,
// 1 for moving right, and 2 for moving left.)

if(d0>0){if(d0==1){l0+=c}else{l0-=c}}
if(d1>0){if(d1==1){l1+=c}else{l1-=c}}
if(d2>0){if(d2==1){l2+=c}else{l2-=c}}
if(d3>0){if(d3==1){l3+=c}else{l3-=c}}
if(d4>0){if(d4==1){l4+=c}else{l4-=c}}
if(d5>0){if(d5==1){l5+=c}else{l5-=c}}
if(d6>0){if(d6==1){l6+=c}else{l6-=c}}
if(d7>0){if(d7==1){l7+=c}else{l7-=c}}
if(d8>0){if(d8==1){l8+=c}else{l8-=c}}
if(d9>0){if(d9==1){l9+=c}else{l9-=c}}

// Then we need to detect bars hitting particles
// If any do, direction is reversed, energy is transferred,
// and new energy-to-carry value is stored for that bar.

     if(l0>=g && d0==1){d0=2; gv+=e0-gv; e0=gv}
else{if(l1>=g && d1==1){d1=2; gv+=e1-gv; e1=gv}
else{if(l2>=g && d2==1){d2=2; gv+=e2-gv; e2=gv}
else{if(l3>=g && d3==1){d3=2; gv+=e3-gv; e3=gv}
else{if(l4>=g && d4==1){d4=2; gv+=e4-gv; e4=gv}
else{if(l5>=g && d5==1){d5=2; gv+=e5-gv; e5=gv}
else{if(l6>=g && d6==1){d6=2; gv+=e6-gv; e6=gv}
else{if(l7>=g && d7==1){d7=2; gv+=e7-gv; e7=gv}
else{if(l8>=g && d8==1){d8=2; gv+=e8-gv; e8=gv}
else{if(l9>=g && d9==1){d9=2; gv+=e9-gv; e9=gv}
}}}}}}}}}
g+=gv; // move green particle

     if(l0<=r && d0==2){d0=1; rv+=e0-rv; e0=rv}
else{if(l1<=r && d1==2){d1=1; rv+=e1-rv; e1=rv}
else{if(l2<=r && d2==2){d2=1; rv+=e2-rv; e2=rv}
else{if(l3<=r && d3==2){d3=1; rv+=e3-rv; e3=rv}
else{if(l4<=r && d4==2){d4=1; rv+=e4-rv; e4=rv}
else{if(l5<=r && d5==2){d5=1; rv+=e5-rv; e5=rv}
else{if(l6<=r && d6==2){d6=1; rv+=e6-rv; e6=rv}
else{if(l7<=r && d7==2){d7=1; rv+=e7-rv; e7=rv}
else{if(l8<=r && d8==2){d8=1; rv+=e8-rv; e8=rv}
else{if(l9<=r && d9==2){d9=1; rv+=e9-rv; e9=rv}
}}}}}}}}}
r+=rv; // move red particle

// and now we update screen positions, bars first:-

b0.style.left=l0*3+l0o; b1.style.left=l1*3+l1o;
b2.style.left=l2*3+l2o; b3.style.left=l3*3+l3o;
b4.style.left=l4*3+l4o; b5.style.left=l5*3+l5o;
b6.style.left=l6*3+l6o; b7.style.left=l7*3+l7o;
b8.style.left=l8*3+l8o; b9.style.left=l9*3+l9o;

ir.style.left=r*3; // calculate particle screen positions
ig.style.left=g*3+go;
rloc.innerHTML=r; gloc.innerHTML=g; // update screen data
sep.innerHTML=g-r;
ping1.innerHTML=rv; ping2.innerHTML=gv;
}}

function setup() // we might use this later
{ }

// All variables are created and initialised here:-

c=0.3 // speed of light in pm/zs.

t=0; // time in zeptoseconds
d=100; // distance in picometres

ss=1; // stop-start variable

// dot vars:-

r=-100; g=0; // initial x-coord locations of the dots
        go=-50; // offset to correct b's display location
rv=0; gv=0; // set initial speeds for particles

  // bar vars:-

l0=-100; l1=-500; l2=-500; l3=-500; l4=-500;
l5=-500; l6=-500; l7=-500; l8=-500; l9=-500;

  // offsets to correct bar display loc.s:-

l0o=-87; l1o=-112; l2o=-137; l3o=-162; l4o=-187;
l5o=-212; l6o=-237; l7o=-262; l8o=-287; l9o=-312;

  // vars to store direction bars are moving in:-
  // (0 = inactive; 1 = moving right; 2 = moving left)

d0=0; d1=0; d2=0; d3=0; d4=0; d5=0; d6=0; d7=0; d8=0; d9=0;

  // vars to store the energy that bars are carrying:-

e0=0; e1=0; e2=0; e3=0; e4=0; e5=0; e6=0; e7=0; e8=0; e9=0;

b=0; // keep track of how many bars are in use


// (milli, micro, nano, pico, femto, atto, zepto)


function nujrl() // accelerate r to left
{ b+=1;
if(b==1){d0=1; e0=-0.1; l0=r; rv-=0.1}
if(b==2){d1=1; e1=rv-0.1; l1=r; rv-=0.1}
if(b==3){d2=1; e2=rv-0.1; l2=r; rv-=0.1}
if(b==4){d3=1; e3=rv-0.1; l3=r; rv-=0.1}
if(b==5){d4=1; e4=rv-0.1; l4=r; rv-=0.1}
if(b==6){d5=1; e5=rv-0.1; l5=r; rv-=0.1}
if(b==7){d6=1; e6=rv-0.1; l6=r; rv-=0.1}
if(b==8){d7=1; e7=rv-0.1; l7=r; rv-=0.1}
if(b==9){d8=1; e8=rv-0.1; l8=r; rv-=0.1}
if(b==10){d9=1; e9=rv-0.1; l9=r; rv-=0.1}
}

function nujrr() // accelerate r to right
{ b+=1;
if(b==1){d0=1; e0=0.1; l0=r; rv+=0.1}
if(b==2){d1=1; e1=rv+0.1; l1=r; rv+=0.1}
if(b==3){d2=1; e2=rv+0.1; l2=r; rv+=0.1}
if(b==4){d3=1; e3=rv+0.1; l3=r; rv+=0.1}
if(b==5){d4=1; e4=rv+0.1; l4=r; rv+=0.1}
if(b==6){d5=1; e5=rv+0.1; l5=r; rv+=0.1}
if(b==7){d6=1; e6=rv+0.1; l6=r; rv+=0.1}
if(b==8){d7=1; e7=rv+0.1; l7=r; rv+=0.1}
if(b==9){d8=1; e8=rv+0.1; l8=r; rv+=0.1}
if(b==10){d9=1; e9=rv+0.1; l9=r; rv+=0.1}
}

function nujgl() // accelerate g to left
{ b+=1;
if(b==1){d0=2; e0=-0.02; l0=g; gv-=0.02}
if(b==2){d1=2; e1=gv-0.02; l1=g; gv-=0.02}
if(b==3){d2=2; e2=gv-0.02; l2=g; gv-=0.02}
if(b==4){d3=2; e3=gv-0.02; l3=g; gv-=0.02}
if(b==5){d4=2; e4=gv-0.02; l4=g; gv-=0.02}
if(b==6){d5=2; e5=gv-0.02; l5=g; gv-=0.02}
if(b==7){d6=2; e6=gv-0.02; l6=g; gv-=0.02}
if(b==8){d7=2; e7=gv-0.02; l7=g; gv-=0.02}
if(b==9){d8=2; e8=gv-0.02; l8=g; gv-=0.02}
if(b==10){d9=2; e9=gv-0.02; l9=g; gv-=0.02}
}

function nujgr() // accelerate g to right
{ b+=1;
if(b==1){d0=1; e0=0.02; l0=g; gv+=0.02}
if(b==2){d1=1; e1=gv+0.02; l1=g; gv+=0.02}
if(b==3){d2=1; e2=gv+0.02; l2=g; gv+=0.02}
if(b==4){d3=1; e3=gv+0.02; l3=g; gv+=0.02}
if(b==5){d4=1; e4=gv+0.02; l4=g; gv+=0.02}
if(b==6){d5=1; e5=gv+0.02; l5=g; gv+=0.02}
if(b==7){d6=1; e6=gv+0.02; l6=g; gv+=0.02}
if(b==8){d7=1; e7=gv+0.02; l7=g; gv+=0.02}
if(b==9){d8=1; e8=gv+0.02; l8=g; gv+=0.02}
if(b==10){d9=1; e9=gv+0.02; l9=g; gv+=0.02}
}

function nujb() // accelerate both together
{ nujrr(); nujgl()}

function os() // one step
{ ss=1; run(); ss=0}

function stopstart()
{ if(ss==0){ss=1}else{ss=0}}

</script>

</HEAD>

<BODY onload="setup()" style="background-color:black;color:white;font-family:arial,helvetica,sans-serif;font-size:18pt"><blockquote>
<center><H1>Theory Simulation</H1><br><br>

<tt>

<b id="ir" style="position:relative;left:-300;top:0;font-size:60;color:red">.</b>
<b id="ig" style="position:relative;left:-50;top:0; font-size:60;color:white">.</b>
<b id="b0" style="position:relative;left:-387;top:2;font-size:18;color:blue">|</b>
<b id="b1" style="position:relative;left:-412;top:2;font-size:18;color:blue">|</b>
<b id="b2" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b3" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b4" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b5" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b6" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b7" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b8" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>
<b id="b9" style="position:relative;left:-999;top:2;font-size:18;color:blue">|</b>

</tt></center>

<p>Red's location = <a id="rloc"></a>
<br>Green's location = <a id="gloc"></a>
<br>Distance apart = <a id="sep"></a>
<p>Latest speed of red particle = <a id="ping1"></a>
<br>Latest speed of green particle = <a id="ping2"></a>
<p><input type="button" value="Nudge red left" onclick="nujrl()"/> <input type="button" value="Nudge red right" onclick="nujrr()"/> &nbsp; <input type="button" value="Nudge green left" onclick="nujgl()"/> <input type="button" value="Nudge green right" onclick="nujgr()"/> &nbsp; <input type="button" value="Nudge both together" onclick="nujb()"/> &nbsp; <input type="button" value="one step" onclick="os()"/> <input type="button" value="stop/start" onclick="stopstart()"/>
<p>
Click away!

</BODY>
</HTML>
And here is mine:

Code: [Select]

<HTML>
<HEAD>
<TITLE>Theory Simulation</TITLE>

<script type="text/javascript">

// All variables are created and initialised here:-

c=0.3;       // speed of light (and bars) in pm/zs.

y=-100;      // 100 initial x-coord locations of y
yo=38;       // offset to correct y's display location

g=-99;       // initial locations of green bar
go=-44;      // offset to correct display location of green bar

r=-98;      // initial location of red bar
ro=-66;      // offset to correct display location of red bar

b=-50;       // initial x-coord locations of b
bo=-10;      // offset to correct b's display location

dirg=0;      // green bar's direction of motion
dirr=0;      // red bar's direction of motion
     
mbg=0;       // move blue particle later with green bar
myg=0;       // move yellow particle later with green bar
mbr=0;       // move blue particle later with red bar
myr=0;       // move yellow particle later with red bar


// (milli, micro, nano, pico, femto, atto, zepto)


{window.setInterval("run()",20)}// controls repetition rate

function run()

{ if(g>=b && dirg==c){dirg=-c}  //change direction of g bar on collision with b
if(g>=b && mbg==1){b=b+4;     //move b if y has moved, move y later
   g=g+4; mbg=0; myg=1}
if(dirg==-c){g=g-c}           // move green bar to the left if direction is left

if(g<=y && dirg==-c){dirg=c}  // change direction of g bar on collision with y
if(g<=y && myg==1){y=y+4;     //move y if b has moved, move b later
   g=g+3.95; myg=0; mbg=1}
if(dirg==c){g=g+c}            // move green bar to the right if direction is right

if(r>=b && dirr==c){dirr=-c}  // change direction of r bar on collision with b
if(r>=b && mbr==1){b=b+4;     // move b if y has moved, move y later
   r=r+3.95; mbr=0; myr=1}
if(dirr==-c){r=r-c}           // move red bar to the left if direction is left

if(r<=y && dirr==-c){dirr=c}  // change direction of r bar on collision with y
if(r<=y && myr==1){y=y+4;     //move y if b has moved, move b later
   r=r+4; myr=0; mbr=1}
if(dirr==c){r=r+c}            // move red bar to the right if direction is right    

ig.style.left=g*4+go;         // calculate bars' screen positions
ir.style.left=r*4+ro;       // (4 units = 1 picometer)

 
iy.style.left=y*4+yo;         // calculate particles' screen positions
ib.style.left=b*4+bo;
}

function move()
        {dirg=c; mbg=1; dirr=c; mbr=1}




</script>

</HEAD>

<BODY   style="background-color:black; color:white; font-family:arial,helvetica,sans-serif;font-size:18pt">
<blockquote>
<center>
<H1>Theory Simulation</H1>
<p>
<tt>
<b id="iy" style="position:relative;   top:0; font-size:60; color:yellow">.</b>
<b id="ib" style="position:relative;   top:0; font-size:60; color:#0020ff">.</b>
<b id="ig" style="position:relative;   top:0; font-size:18; color:#00ff00">|</b>
<b id="ir" style="position:relative;   top:0; font-size:18; color:red">|</b>
</tt>
</center>
<p>
<input type="button" value="Move photon" onclick="move()"/>
<p>
The distance between a red and a green photon is contracted by the motion of a yellow particle and stretched by the motion of a blue one. The particles send their photon when they move, and they move to send their photon on sync with the incoming one, so they move towards it when they see it is stretched, and away from it when they see it is contracted. Notice that the red photon stays the leader all the time: that's what happens when waves get reflected.

</BODY>
</HTML>

[David Cooper]

I'm not terribly keen on the 0.1 value that you've used instead of 0.02 - the speed of light is 0.3 on this scale, so it only takes three or four nudges in the same direction to make it go crazy, but it's fun when you nudge a particle right, then left again as soon afterwards as possible. You can use all ten bars that way without the particle ever reaching 0.3, and yes - I see it doing the same thing as the new version of your program.

This stuff is really making me think more though about how energy might actually be transferred between bonded particles, because I still can't work out how it could happen. The energy must be transferred along with the light (or force carrier), but how can it know it's going to reach the other particle and not just be lost to both of them?

[Le Repteux (OP)]

That's a question physicists must also answer for electrons, because the bonding phenomenon depends on them, and because no energy is lost in the process either. It is only during an acceleration that light is sent. When molecules collide in a gaz for instance, they produce infrared light so some energy from their bonding is actually lost, and once they get their speed, they keep going on indefinitely without emitting light anymore. Of course, light seems to be emitted in all directions by particles, but that direction might depend on a random process happening at the quantum scale, which means that they might send it in one direction at a time, a direction that might get as constant as their steps when they are not accelerated. If it was so, and if the steps were made to stay synchronized with the incoming light, they would absorb almost all that light by interference, only a tiny part due to the loss of intensity with distance could not be absorbed, a part that could be carrying the information for gravitation.

As we could see, there is many ways to simulate the information transfer, but if the model is right, only one of them is right. Looking at the speeds I could give to your particles, I realized that we will probably have to introduce mass increase in the simulation one day or another, which means that we will be forced determine more precisely how mass develops. This constraint might help us to reduce the possibilities. I always thought that mass would be due to a loss of synchronism during acceleration, and that the relativistic mass increase could be due to the particles having to respect the sinusoidal shape of the incident light waves, because then, their speed in the middle of a wave would be a lot faster than their mean speed.

Water molecules move that way to reproduce a wave, they accelerate from rest and decelerate to rest once the wave has been reproduced. At the top of the wave, they get their top speed forward, and it happens that the wave breaks when the top molecules are moving forward faster than the wave itself. It is evident that the particles cannot move faster than their own waves if the motion of their components themselves depend on the same kind of waves. At .1 pm/zs as a mean speed, a particle would probably have to wait a moment in the middle of its step for the light from the other particle's step to produce its own step, so it would take more time, thus more energy to stretch its step more, and it is while making longer steps without changing its frequency that a particle increases its speed.

It would be interesting to simulate the way only one particle would behave if it had to send its own light on sync with only one incoming sinusoidal wave, with a single variable to change the frequency of the wave to test different speeds. The wave could be represented by a sinusoidal curve moving to the right on the screen with its first part producing the acceleration of the particle and its last one producing the deceleration. We could divide the wave in ten different parts that would represent ten different speeds, and the particle would have to accelerate and decelerate to stay on sync with those different speeds. At a particular incoming blueshift, the top speed would be equal to c while the mean speed would not, and the particle would not be able to move faster even if we would increase the redshift, thus the energy of the force. Of course the inverse is also true, no particle should be able to produce a blueshifted wave where the middle of the wave comes from its speed being faster than c. So, what is really happening when we accelerate particles to almost the speed of light? Could we use that kind of simulation to discover it?

For instance, what would happen if we would try to accelerate the particle at a top speed of c? Theoretically, it should start running after the middle of the wave indefinitely without being able to reach it, the middle of its step getting longer and longer with time. We could then try to use the time dilation principle of relativity to slow down the progression of the acceleration during the step, but it seems to produce the contrary: the more the particle would get to its top speed during the step, the more its frequency would slow down, so the more the wave that produces its speed would appear blueshifted, thus increasing the force on the particle instead of slowing it down. You know better than me how relativity works, so maybe you can figure it out better than me. We have to be careful though, because we are working on a mechanism that should be the source of motion, so it should explain relativity instead of relying on it to work properly.

After having had this idea, I measured the time light takes two way between your two particles at different speeds, and instead of taking more time with speed as in your MMx simulation, it takes about the same time. This seems to be due to the contraction being more important than the relativity one. For a speed of .2 for instance, which is .666c, the contraction is about .666 of the distance at rest and it should be closer to .4. Maybe this kind of contraction has nothing to do with the relativity one, but I think that the time dilation should be the same, so that constraint should help us to eliminate some possibilities. We can do better than just apply the relativity contraction to the system, we're in a position to look for its underlying mechanism.

I nudged the red particle at .2E and stopped it when the distance between the particles was around 50, and it went on oscillating between 100 and 50 indefinitely after, so their mean distance was around 75. If I had waited the right amount of time to stop it, their mean distance might have coincided to the relativity contraction for a molecule traveling at such a speed. I'll try to add counters to your simulation to display the mean speed of the system and the mean distance between the particles. The idea is to find a way to calculate the time a particle should take to get back to rest after having been accelerated. Of course, the doppler effect would still be the cause for that deceleration, but the intensity of the light would have to be considered when the distance between the particles drops as much as it does at relativistic speeds. The force should follow the inverse square law: twice closer, four times the deceleration force.

[Le Repteux (OP)]

Hi David,

Before getting into your proposition of doing a simulation with four particles at the corners of a square, I bring back here the conversation we were having on the Anti-Relativity forum about my simulation of the Twins paradox. I did the simulation while using the light clocks each twin had instead of using the computer clock like you did in your last MMx simulation, and I realized that it was impossible to synchronize the clocks this way, because the steps the clock of the  moving twin makes to execute its motion cannot coincide perfectly with the ones light makes: the photon has already passed the particle when the computer detects it. This way, the traveling light clock always travels less than what light travels in the same time, so it never gets back to the rest clock on time: if we stop the motion when the rest clock is at 32 seconds, the traveling clock should read 16 seconds and stand where it started, but it reads only 14 seconds and is short from where it started. If we add precision to the simulation, what anybody can do while dividing the speed of light and the speed of particles by 100 for instance, it seems to work, but in reality, there is no way to get an absolute precision this way. Here is the simulation again and your answer to my questioning after. (Again, if anybody wants to run it, copy paste it on Notepad, save it as an HTML file, and open the file. It will open in your browser)

Code: [Select]

<HTML>
<HEAD>
<TITLE>Twins 1</TITLE>

<script type="text/javascript">

//
sd=0; md=0;                // direction of photons for static and moving clocks
mlx=200; mrx=210;     // initial location of moving mirrors
slx=200; srx=220;         
spx=200; mpx=200;     // initial location of photons
tsx=0; tmx=0;             // time display for static and moving clocks
v=.8660254038; c=1;  // mirrors speed vs speed of photon
st=0;                            // start variable
//

window.setInterval("run()",10)

function run()

{
// moving mirrors
if(st==1){mlx+=v; mrx+=v}          // start mirrors
 
if(mpx>mrx && md==1){md=-1; }     // detect right collision, reverse directions

if(mpx<mlx && md==-1){md=1;  tmx+=1}   // detect left collision, reverse direction, update time

if(md==-1){mpx-=c}    // move photon both directions
if(md== 1){mpx+=c}

if(tmx==8){v=-.8660254038}      // moving clock gets back home when its clock reads 8 sec
if(tsx==32){md=0; sd=0; st=0}   // stop the simulation when the rest clock reads 32 sec



// Static mirrors
if(spx>=220 && sd==1){sd=-1}             // detect right collision, reverse mirror direction
if(spx<=200 && sd==-1){sd=1; tsx+=1}     //detect left collision, reverse direction, update time

if(sd==-1){spx-=c}     // move photon both directions
if(sd== 1){spx+=c}



// Update display
sp.style.left=spx;                   // update photons positions
mp.style.left=mpx;

ml.style.left=mlx;                   // update moving clock position
mr.style.left=mrx;

ts.innerHTML=tsx;      // update time display
tm.innerHTML=tmx;
}


function start()
{md=1; sd=1; st=1}


</script>

</HEAD>

<BODY style="background-color:black;color:white;font-family:arial,helvetica,sans-serif;font-size:18pt">

<center><H1>Twins Paradox Simulation</H1><br></center>

<code>
<b id="sp" style="position:absolute; left:200;top:100; font-size:18; color:red">|</b>
<b id="mp" style="position:absolute; left:200;top:120; font-size:18; color:red">|</b>

<b  style="position:absolute; left:220;top:100; font-size:18; color:blue">|</b>
<b  style="position:absolute; left:200;top:100; font-size:18; color:blue">|</b>

<b id="ml" style="position:absolute; left:210;top:120; font-size:18; color:yellow">|</b>
<b id="mr" style="position:absolute; left:200;top:120; font-size:18; color:yellow">|</b>
</code>

<a id="ts" style="position:absolute; left:180;top:100; font-size:18; color:blue"></a>
<a id="tm" style="position:absolute; left:180;top:120; font-size:18; color:yellow"></a>


<input type="button" style="position:absolute; left:200; top:200" value="start" onclick="start()"/>

</BODY>
</HTML>

we can only detect a collision when light has already passed the particle

You can wait for the collision to be recognized (after the event), then undo the action the exact amount needed to get to the actual time for the collision and correct events accordingly. It would make the program a lot more complicated, of course, but it can be done and it would eliminate the errors that are adding up as a result of turning the light round late every time it hits a mirror, allowing events to run fast and with precision. When you detect a collision, you need to go back a step (one whole time slice) and work out how long it should take for the two things to collide from that point in time, which is best done by working out the closing speed between the light and the mirror and then treating one of them as stationary and the other as moving towards it at that closing speed. That lets you work out the time needed to get to the collision, and once you have that, you can apply that time to the actual speed of travel of the light to work out where it needs to turn round. You can then move it back the other way from that location for the rest of the time available in that time slice and then display it in its correct position.

I began doing this, and then I realized that the particles could not. They can only use their own clocks and try to make their steps on sync with the incoming light waves, so those steps are necessary late a bit if they make any. If we add precision to them, the gap can be very tiny, but as the simulation shows, those distance gaps add up over time and light doesn't, so if two bodies are very distant from one another, a frequency difference must show up, and that's what we observe with gravitation. With a simulation, we can see how light travels between moving bodies of different scales, and discover how those bodies could behave when it strikes them, but I'm afraid it is impossible to simulate absolute motions this way, whereas light can really produce them. If some light is lost during the steps at a given scale, then this light is automatically transferred to the steps at the next scale, not lost, and so on indefinitely. That's how I figure the steps would produce gravitation, but I'm not there yet, I need to discover how the steps would be executed first, and as we can see, it is less evident than when I was just turning doppler effect into a cause in my mind. At that moment, I knew that the synchronism between the particles would depend on the one between the components, and I knew that it would add complexity to the simulation if we were forced to account for it, but I never realized that doppler effect itself would be so touchy to simulate.

If we replace the two particles by two cars able to detect doppler effect on sound, we don't have to be that precise. The cars only need to be able to accelerate so as to nullify the effect. They necessarily accelerate late with regard to the perceived waves since they have to let it go by a bit before being able to detect if there is any doppler effect in it, but it doesn't matter as long as that delay is included in the wave they send when they make their own step. Accelerating late each time they make a step means losing time at each step, which means losing distance with time, which means slowing down, what should produce redshift on the waves that escape from their steps, which is what we observe on the light from galaxies.

Your idea of particles going on moving after a nudge is interesting for testing the wave like shape of a step, which is done by nudging the red particle five times to the right and immediately five times to the left, but a particle should stop moving by itself after a step if we want this deceleration to explain mass. To study that question, I'm actually planning to add a constraint to the steps: a first particle will have to wait for the other particle to make its step and for the light from that step to be back, before making another one, but during this time, a force will have to be exerted on it to keep it there otherwise it will get back where it was. That's a nice way to introduce mass in the steps, but It creates other problems. For instance, I think that, this way, at the particles' scale, acceleration would have to be quantized, which would not be that surprising since the light emitted by the particles already is.

[David Cooper]

I meant to reply to your previous post at the time, but there were too many competing things happening for me to be able to concentrate on it, and then I forgot to return to it. There are also a lot of ideas in it which will likely take a lot of time to explore, but whenever you want to implement a specific idea and have difficulty working out how to do so, I'll be happy to look at it and see if I can help.

We have to be careful though, because we are working on a mechanism that should be the source of motion, so it should explain relativity instead of relying on it to work properly.

I think that might be difficult, but there's a key part of the mechanism behind relativity that I don't understand. Whenever a nudge is made to a particle, that is adding energy in, and that energy has an effect on the power of subsequent nudges, reducing their effectiveness as the particle moves faster because of relativistic mass. By the time a particle is moving at 0.866c, for example, it effectively has a mass twice as high as it had at rest, so a new nudge may only be half as effective. If it's moving at 0.968c a new nudge may only be a quarter as effective. If it's moving at 0.992c, a new nudge may only be and eighth as effective. The numbers are strange though. The square of 0.866 is 0.75, or 3/4, which fits neatly with three quarters of the total energy of the moving particle trying to move one way while the other quarter tries to go the opposite way (the particle itself being made up of energy which if released would move off in opposite directions), but the square of 0.968 is 0.9375, or 15/16 (rather than the 7/8 that I had expected [because it's seven lots of energy working against one]) and the square of 0.992 is 63/64 (rather than 15/16 [because it's fifteen lots of energy working against one]). And why should it be squared anyway? These are still very neat fractions though, so they must be meaningful.

I nudged the red particle at .2E and stopped it when the distance between the particles was around 50, and it went on oscillating between 100 and 50 indefinitely after, so their mean distance was around 75.

The main problem with the size of the nudges being applied is that they'd tear bonded particles apart, while if you make them small enough to be realistic, it's hard to get them up to relativistic speeds without running the program for a very long time and tracking the particles as they gradually accelerate and share out the energy from the nudges evenly between them. We need to understand where all the energy is and what it's doing.

[I'll reply to your new post tomorrow - I got here too late in the day to work on that now.]

[Le Repteux (OP)]

Whenever a nudge is made to a particle, that is adding energy in, and that energy has an effect on the power of subsequent nudges, reducing their effectiveness as the particle moves faster because of relativistic mass.

If we imagine a simulation where we have to hold a first particle in place after having forced it to make a step toward the second one, we can easily imagine the photons from that second one hitting the first one too soon, thus pushing on it to bring it back to the right bonding distance. If the step needs to get longer because the force is more important, the timing gets worse and the force needed to keep it there has to increase. That explains the difference between a weak and a strong acceleration, but it doesn't explain the relativistic mass increase. Contrary to the impossibility to measure the speed of light one way, it is possible to measure mass increase one way, so it shouldn't be linked to aether the same way light is, but with the steps, the only way I see to explain that increase is with the limited speed of light, which is not the same two ways if aether exists even if we can't measure it, so if the steps also exist, there should be a difference in the exact amount of energy needed to accelerate a particle depending on our speed with regard to aether, but I don't know if particle accelerators are precise enough to detect that difference. If they are, we could have a way to determine if aether exists while detecting the rotational or orbital speed of the earth this way, and we could also determine if the CMBR dipole anisotropy is related to aether.

With the steps, this mass increase would be due to the steps getting their top speed in the middle of a step, a top speed that could not overcome the speed of the information that induces it. We can see from the simulations that, to account for the deceleration of the steps, the speed of a molecule would have to be a lot less important than the mean speed of the steps between its atoms, but that is only a mean speed, which means that the top speed of those steps might get very close to c even if the molecule's speed is still quite low. With bonded particles, whenever we try to stretch a first particle's step that is already close to c in the middle, it cannot do so before the information to do so comes in, so it has to stay partially stretched and wait for that information to come in.

[David Cooper]

I began doing this, and then I realized that the particles could not. They can only use their own clocks and try to make their steps on sync with the incoming light waves, so those steps are necessary late a bit if they make any. If we add precision to them, the gap can be very tiny, but as the simulation shows, those distance gaps add up over time and light doesn't, so if two bodies are very distant from one another, a frequency difference must show up, and that's what we observe with gravitation. With a simulation, we can see how light travels between moving bodies of different scales, and discover how those bodies could behave when it strikes them, but I'm afraid it is impossible to simulate absolute motions this way, whereas light can really produce them.

I can't see where gravitation comes into it, and I can't see why a simulation shouldn't be able to model what the universe does.

If some light is lost during the steps at a given scale, then this light is automatically transferred to the steps at the next scale, not lost, and so on indefinitely. That's how I figure the steps would produce gravitation, but I'm not there yet,

What is this gravitation acting on? How is gravitation going to come out of this if the particles are all at rest?

I need to discover how the steps would be executed first, and as we can see, it is less evident than when I was just turning doppler effect into a cause in my mind. At that moment, I knew that the synchronism between the particles would depend on the one between the components, and I knew that it would add complexity to the simulation if we were forced to account for it, but I never realized that doppler effect itself would be so touchy to simulate.

There isn't a big problem with simulating it. The only issue is that we jump forward in jumps and can miss the exact timing of some of the events, but it can be put right after the event, thereby keeping things every bit as accurate as they would be if we ran trillions of sub-jumps for every jump. This allows us to run the action fast without losing any of the action. The only reason we haven't done this from the start is that it takes longer to write programs, but once we have a program that's worth doing properly, we can make it perfect and eliminate the errors. Until then, it's best to work with a reasonable granularity and not worry about small errors when we have sufficient precision to get a clear view of how things will behave under different rules.

Anyway, I think a four particle simulation might show up something interesting, and it's worth doing one with their functionality being slowed by their movement and where the nudges add energy in such a way as to conform to relativistic velocity addition. Once we have that, it should be easy to modify it to try out other ideas on top of it, but this would provide a basic framework for that. I'm going to have a go at building this program, and if you want to try building one the same or similar to it that could be a good programming exercise. My idea for controlling the effect of the nudges is that they be considered to be added from something co-moving with the particle being nudged - this will make it easy to calculate the new speed for the particle because a nudge which makes its speed change from 0 to 0.2c would lead to an identical second nudge changing the particle's speed to (0.2 plus 0.2) / (1 minus 0.2 times 0.2) = 0.385. A third nudge will then change the particle's speed to (0.385 + 0.2) / (1 + (0.385 x 0.2)) = 0.543. By doing this, we can go on adding an infinite number of 0.2c nudges without the particle ever reaching c.

[guest4091]

There is a playground ride (merry-go-round), that relates to this behavior. A person can grab a metal bar, give it a push to get it spinning. As it spins faster, each revolution requires additional energy to match the hand speed to the bar, then add a push. Thus each increase in speed requires more energy than the previous.
In the example of a particle accelerator, the transfer of energy to the particles, the time increases exponentially. I refer to this as 'diminishing returns on an increasing investment'. Originally this phenomenon was misinterpreted as increasing inertial resistance, i.e. mass increase. That term is obsolete, since it is due to time dilation, a slowing of a process. The equations use m₀ for rest mass and a term for kinetic energy (which increases as v^2). If a light clock could move at c, no em energy could be transferred to the mirror!

[Le Repteux (OP)]

I can't see where gravitation comes into it, and I can't see why a simulation shouldn't be able to model what the universe does.

Gravitation would be a scale effect where the components of atoms would try to stay on sync with the components of other atoms while the atoms themselves are already doing the same thing. I said we couldn't simulate that because I think it would be too long to run. I only made my simulation of the twins paradox a hundred times more precise and it ran for almost half an hour. We're dealing with particles that are million times smaller than atoms, so it might take too long before we can observe the effect.

How is gravitation going to come out of this if the particles are all at rest?

No inertial motion, no gravitational motion either. Either things move or they don't. If they do, then it is with regard to aether, and we can easily see from our simulations that this assumption produces real effects on timing and distances, so it is up to us to discover how such effects would produce gravitation. What I am saying about it for the moment is only pure speculation, but when you began helping me simulating the steps, I knew we might be able to test that idea too.

but I never realized that doppler effect itself would be so touchy to simulate.

There isn't a big problem with simulating it. The only issue is that we jump forward in jumps and can miss the exact timing of some of the events, but it can be put right after the event, thereby keeping things every bit as accurate as they would be if we ran trillions of sub-jumps for every jump. This allows us to run the action fast without losing any of the action. The only reason we haven't done this from the start is that it takes longer to write programs, but once we have a program that's worth doing properly, we can make it perfect and eliminate the errors. Until then, it's best to work with a reasonable granularity and not worry about small errors when we have sufficient precision to get a clear view of how things will behave under different rules.

Anyway, I think a four particle simulation might show up something interesting, and it's worth doing one with their functionality being slowed by their movement and where the nudges add energy in such a way as to conform to relativistic velocity addition. Once we have that, it should be easy to modify it to try out other ideas on top of it, but this would provide a basic framework for that. I'm going to have a go at building this program, and if you want to try building one the same or similar to it that could be a good programming exercise. My idea for controlling the effect of the nudges is that they be considered to be added from something co-moving with the particle being nudged - this will make it easy to calculate the new speed for the particle because a nudge which makes its speed change from 0 to 0.2c would lead to an identical second nudge changing the particle's speed to (0.2 plus 0.2) / (1 minus 0.2 times 0.2) = 0.385. A third nudge will then change the particle's speed to (0.385 + 0.2) / (1 + (0.385 x 0.2)) = 0.543. By doing this, we can go on adding an infinite number of 0.2c nudges without the particle ever reaching c.

As you know, I'm still trying to understand how a particle would behave after having made a step, so I think I will try to elucidate that while you build that new simulation. If mass is part of the motion process, a particle has to resist being accelerated, so I think it has to stop by itself after each step even if a force is still applied to it. But if the force is constant, the particle cannot increase its speed this way since the length of its steps will be constant, it has to wait until the second particle makes a step away. Once the red shifted light from that second particle will have reached it, it will stop resisting to make its step, so it will have time to make a longer one, thus to increase its speed. That's quite different from the acceleration we observe at our scale, but it doesn't mean that we are on a wrong path.