How can I write a computer simulation to test my theory

David Cooper · « **Reply #20 on:** 14/08/2017 00:45:10 »

Quote from: Le Repteux on 13/08/2017 16:21:07

I don't mind simulating particles first, but I would like to have buttons so that I could change the frequency and the speed of the wave easily. I think it should be interesting to compare different kind of waves.

It's easy to add buttons, and you can attach to them whatever maths you need. We'll certainly want to be able to use a much higher frequency for the light so that we don't have to wait ages to see each "beep".

Quote

I don't understand why you want to accelerate the first particle instantly though: why not accelerate it progressively with a button or a window to enter the acceleration rate and another one that we could hold to decide the duration of the acceleration?

Providing controls for that will be possible, but you need to decide what the difference is between an unbonded particle interacting with particle A and particle A interacting with particle B which is bonded with it in some way.

I've modified the program a bit to give you four objects to move on the screen and I've worked out the offsets to correct their positions. I've also simplified their names to make them easier to recognise because we don't need to differentiate between x and y coordinates, so they're now just the letters y b r g (relating to the colours of the objects). The objects won't continue to be controlled by buttons in the way they are at the moment, so their positions will be calculated by using the variables y b r g (while the offsets bo ro go will only be used when setting their positions on the screen - these offsets simply correct their positions to cancel out the misalignments caused by my trick of using text as graphics). I've also added a function cd() which does collision detection to detect the arrival of "beeps".

Code: [Select]

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

	<script type="text/javascript">

//	window.setInterval("run()",10) // this will control how fast we repeat the action

	function run()
	{	}

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

// We'll create and initialise all our variables here:-

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

	r=400; g=-400; // initial locations of the bars
	ro=-87; go=-112; // offsets to correct bar display loc.s

	t=0; // time in zeptoseconds
	d=200; // distance in picometres
	f=1000; // initial bonding-light frequency per zeptosecond

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

	function moveiy()
	{	y=y+1; iy.style.left=y; yloc.innerHTML=y; cd()}

	function moveib()
	{	b=b+1; ib.style.left=b+bo; bloc.innerHTML=b; cd()}

	function moveir()
	{	r-=1; ir.style.left=r+ro; rloc.innerHTML=r; cd()}

	function moveig()
	{	g+=1; ig.style.left=g+go; gloc.innerHTML=g; cd()}

	function cd() // collision detection
	{	if(r==y){ping1.innerHTML="PING"}
		if(g==b){ping2.innerHTML="PING"}}

	</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><a id="yloc"></a> &nbsp; <a id="bloc"></a> &nbsp; <a id="ping1"></a>
<p><a id="rloc"></a> &nbsp; <a id="gloc"></a> &nbsp; <a id="ping2"></a>
<p> <input type="button" value="Move Yellow" onclick="moveiy()"/> <input type="button" value="Move Blue" onclick="moveib()"/> <input type="button" value="Move Red" onclick="moveir()"/> <input type="button" value="Move Green" onclick="moveig()"/>
<p>
You can replace this text with your own to explain how to use the program.

</BODY>
</HTML>

Le Repteux · « **Reply #21 on:** 14/08/2017 16:51:22 »

Quote from: David Cooper on 14/08/2017 00:45:10

Providing controls for that will be possible, but you need to decide what the difference is between an unbonded particle interacting with particle A and particle A interacting with particle B which is bonded with it in some way.

The difference is only technical because the first steps particle B would make are identical to the steps particle A would have made before. At the beginning, before particle B would have moved, particle A's steps would depend on an acceleration formula. Later on, particle B's steps would depend on blueshift from particle A. After the acceleration of particle A would have stopped, both particles' steps would only depend on doppler effect, but if particle A would still be accelerated while redshiftt from particle B would come in, its steps would then depend on both redshift and the acceleration formula. What would happen then is that the steps the redshift would produce would add to the steps the acceleration would produce. For instance if the steps were already constant because acceleration would have stopped a long time ago, accelerating particle A again would mean adding some increasing lengths to the constant steps it already makes.

It is interesting to note that if both particles would be accelerated towards one another in the same time, thus if we would exert a force to compress their bond, the blueshift produced by their first steps on the light they emit would add to the blueshift produced later on on the incoming light from the other particle. They would move a bit, but they would suddenly suffer more blueshift than the one from their own steps. I figure that they could then step backward for a few steps, thus pushing harder on whatever pushes them together, what would produce redshift on the light emitted towards the other particle, what would bring the two particles closer after a while, what would produce blueshift on the light they emit, and so on. This way, what we observe as a constant force when matter is compressed would depend on particles vibrating to stay on sync. That vibration might be interesting to simulate if ever we succeed to simulate the steps.

David Cooper · « **Reply #22 on:** 15/08/2017 00:47:26 »

Well, it´s going to be your job to supply the maths for the accelerations. I've got another new version of the program which is sufficiently changed that I've had to post the whole thing. I've now enabled the setInterval part of the code and provided functionality for "run()". This routine advances the time counter by 1 every time it runs, but by changing the value of the variable gr to a value other than 1 it will be easy to change the speed the simulation runs at if we decide it's too slow. There are two time counters which are new, and these reset periodically to trigger new bars to be emitted from the particles so that we have an infinite number of them. The movement of the bars is now governed by c, so they no longer need buttons to move them. We need to design code next to govern the movement of the two particles in a similar way, but it'll be more complex as that's where the accelerations have to be handled. See if you can understand the program as it now is, and think about how you could add code into it to control the movement of the two particles.

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
		r+=rv*gr; g+=gv*gr; // update bar positions
		if(ty>=fb){r=b; ty=0, cdr=0} // reuse old bars for new bars
		if(tb>=fy){g=y; tb=0; cdg=0} // ... when timers time out
		ir.style.left=r*4+ro; // calculate bars' new screen positions
		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.
		cd(); // call collision detection function
	}

	function setup() // we'll 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=100; // initial x-coord locations of the dots
	        bo=-50; // offset to correct b's display location
	yv=0; yb=0; // initial speeds for particles

	r=100; 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

	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=1000; // initial bonding-light frequencies per zeptosecond
	fb=1000; // (one for each particle) [1000 = 1x10^18Hz]

	ry=0;gb=0;ry2=0;gb2=0;cdr=0;cdg=0; // collision detection var.s

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

	function cd() // collision detection
	{	if(r<=y && cdr==0){ping1.innerHTML="ping"; ry=t; cdr=1}
		if(g>=b && cdg==0){ping2.innerHTML="pong"; gb=t; cdg=1}
		ry2=t-ry; gb2=t-gb;
		if(ry2==60){ping1.innerHTML=""}
		if(gb2==60){ping2.innerHTML=""}
	}

	function moveiy() // test routine for moving yellow particle
	{	y=y+1}

	function moveib() // test routine for moving blue particle
	{	b=b+1}

	</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><a id="yloc"></a> &nbsp; <a id="bloc"></a> &nbsp; <a id="ping1"></a> 

&nbsp; <a id="ping2"></a>
<p> <input type="button" value="Move Yellow" onclick="moveiy()"/> <input type="button" value="Move Blue" onclick="moveib()"/>
<p>
You can replace this text with your own to explain how to use the program.

</BODY>
</HTML>

Le Repteux · « **Reply #23 on:** 17/08/2017 19:12:48 »

The acceleration formula goes like this:

a=v/t=d/t²,
so d=at²,
which translates by: the length of a step = the rate of the acceleration times the duration of a step squared.
For instance,
for t=0 to 5, and for a=1, then d=0, 1, 4, 9, 16, 32
for t=0 to 5, and for a=2, then d=0, 2, 8, 18, 32, 64

Of course, we have to use the same units than those we already use.

I tried to move the particles and I didn't succeed. I have to get used to many different new things, and it takes time because my short term memory is bad. I read Mozilla's pages on JavaScript to get used faster: https://developer.mozilla.org/fr/docs/Learn/JavaScript/First_steps/What_is_JavaScript

David Cooper · « **Reply #24 on:** 18/08/2017 02:25:29 »

Quote from: Le Repteux on 17/08/2017 19:12:48

d=at²,
which translates by: the length of a step = the rate of the acceleration times the duration of a step squared.
For instance,
for t=0 to 5, and for a=1, then d=0, 1, 4, 9, 16, 32
for t=0 to 5, and for a=2, then d=0, 2, 8, 18, 32, 64

I think we need to unpick the formula to run it in time slices. The formula always works from the same start time, whereas each of our calculations should start from the end of the previous time slice. With gravity (which I'm going to use to think this through as it's easiest to understand), the usual formula is S=ut+0.5at². The half is there because only half of the acceleration value is realised as new distance for each step while the full value of a is added to the speed by the end of the time slice. With a=10 we see the total distance go up as follows: 5; 20; 45; 80; etc. In each case, the speed goes up by 10 by the end of the time slice, so the distance covered in that time slice will always be the same distance covered in the previous time slice again plus half of a. Slice one: (speed 0-10m/s) 5m travelled [= 0+0+5]. Slice two: (10-20m/s) 20 [= 5+10+5], but only 15m of this is new. Slice three: (20-30mps) 45 [=20+20+5], but only 25m of this is new. Slice four: (30-40mps) 80 [= 45+30+5], but only 35m of this is new.

So, it's really very simple. We keep a value for the current speed of a particle and add that each time to the location to get the new position, but we also add half of a to it.

The acceleration should to change as the particles get closer together, but it might only change the speed when a bar hits the particle, which means the particle would accelerate in instantaneous jumps each time rather than smoothly. If the acceleration is to be continuous, it should increase all the time and not be a constant force, which leads to more complex controls needing to be programmed. Let's start though with something half way between those two alternatives where we have constant accelerations which are changed in an instant to new acceleration values whenever a new bar arrives.

I had thought that the big problem with deciding what the acceleration should be is that you'd need to count at least two bars and time the gap between them to work out the frequency, but actually you don't - all you need to do is work out the speed of the particle relative to the light to get a value that varies the same way as frequency (though you also ought to adjust for the slowing of functionality of the particle ("time dilation") that put that "bar" of light out because that will lower its frequency, and the speed of functionality of the particle receiving which may amplify it back up to a similar value, but we can modify the program to cover that later - we'll build it steadily piece by piece and add complexity over time).

Quote

I tried to move the particles and I didn't succeed. I have to get used to many different new things, and it takes time because my short term memory is bad.

You'll pick it up soon enough - it's good that you tried as you will still have learned a lot from it. I've made a few new additions (and corrected the name of a variable that I'd listed before but have only now started using), and the changes are sufficient to need to post the whole new version (as it would take more space to tell you which bits to edit otherwise):-

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
		r+=rv*gr; g+=gv*gr; // update bar positions
		if(ty>=fb){r=b; ty=0, cdr=0} // reuse old bars for new
		if(tb>=fy){g=y; tb=0; cdg=0} // ... when timers time out

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

		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.
		cd(); // call collision detection function
	}

	function setup() // we'll 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=100; // initial x-coord locations of the dots
	        bo=-50; // offset to correct b's display location
	yv=0; bv=0; // initial speeds for particles

	r=100; 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

	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=1000; // initial bonding-light frequencies per zeptosecond
	fb=1000; // (one for each particle) [1000 = 1x10^18Hz]

	ha=0; // variable to store a value temporarily
	ya=0; // acceleration value applying to yellow
	ba=0; // acceleration value for blue particle

	ry=0;gb=0;ry2=0;gb2=0;cdr=0;cdg=0; // collision detection var.s

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

	function cd() // collision detection
	{	if(r<=y && cdr==0){ping1.innerHTML="ping"; ry=t; cdr=1}
		if(g>=b && cdg==0){ping2.innerHTML="pong"; gb=t; cdg=1}
		ry2=t-ry; gb2=t-gb;
		if(ry2==60){ping1.innerHTML=""}
		if(gb2==60){ping2.innerHTML=""}
	}

	function incya()
	{	ya+=0.001}

	function decya()
	{	ya-=0.001}

	function moveiy() // test routine for moving yellow particle
	{	y=y+1}

	function moveib() // test routine for moving blue particle
	{	b=b+1}

	</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><a id="yloc"></a> &nbsp; <a id="bloc"></a> &nbsp; <a id="ping1"></a> &nbsp; <a id="ping2"></a>
<p> <input type="button" value="Move Yellow" onclick="moveiy()"/> <input type="button" value="Move Blue" onclick="moveib()"/> <input type="button" value="Acc+" onclick="incya()"/> <input type="button" value="Acc-" onclick="decya()"/>
<p>
You can replace this text with your own to explain how to use the program.

</BODY>
</HTML>

I've added six new lines into the function called run() to handle the accelerations of the particles, then I created three new variables (ha, ya and ba) to hold acceleration values. I also added two new buttons to control the acceleration force acting on the yellow particle so that we can test in manually and I added two new functions to link to from the buttons. The result is rather fun - see if you can keep the yellow particle on the screen, and see if you can stop it moving once you've started it. Next time we'll have to add more code to use the bar-particle interactions to control the accelerations instead instead of the buttons, but if you can work out how the new parts of the existing program work, you might just know enough to be able to try some experimental programming of the next step yourself.

Le Repteux · « **Reply #25 on:** 19/08/2017 21:12:23 »

Quote from: David Cooper on 18/08/2017 02:25:29

The half is there because only half of the acceleration value is realised as new distance for each step while the full value of a is added to the speed by the end of the time slice.

I didn't even care to take a look at wiki before answering, and I didn't remember that the acceleration formula had to be derived to get the distances, so you're right again, the new distance is .5at².

Quote

The acceleration should change as the particles get closer together, but it might only change the speed when a bar hits the particle, which means the particle would accelerate in instantaneous jumps each time rather than smoothly.

You seem to be giving importance to the collision with the bars during acceleration, and I think we should not. What you are actually trying to figure out is how we are going to bring mass into consideration, and I find it difficult to simulate because the mass induced by the resistance to acceleration between the components is a lot more important that the one induced by the resistance to acceleration between the particles, and because what we are actually trying to simulate is only the steps between the particles. I figured that, instead of accounting for the blueshift particle A would produce on incident light at the beginning of its acceleration, we could simplify the problem while accounting for it only at the end of its acceleration, but it doesn't seem to work, so the question remains: how do we account for blueshift during acceleration of particle A?

If we keep constant the frequency of the steps, it seems that there is only one way: their length has to be reduced a bit, and it has to be reduced a fraction of the blueshift: the more the blueshift, the more the reduction. At each step forward, a small step backward would have to be subtracted. It looks like the contraction that would happen between the two particles during the time the blueshifted light from particle A would take to reach particle B. This contraction is proportional to the distance between the particles and to the rate and the duration of the acceleration. As I already said, I think it should be equivalent to the relativistic one, which is proportional to the speed, which is in our case proportional to the length of the step being made. We could try this way, but it would produce very small numbers because it would represent a tiny fraction of a step, so maybe we should first try to work without it.

Quote

I had thought that the big problem with deciding what the acceleration should be is that you'd need to count at least two bars and time the gap between them to work out the frequency, but actually you don't - all you need to do is work out the speed of the particle relative to the light to get a value that varies the same way as frequency (though you also ought to adjust for the slowing of functionality of the particle ("time dilation") that put that "bar" of light out because that will lower its frequency, and the speed of functionality of the particle receiving which may amplify it back up to a similar value, but we can modify the program to cover that later - we'll build it steadily piece by piece and add complexity over time).

Again, you seem to allow importance to the incoming bars during acceleration of particle A, and I think it is not necessary. On the other hand, it is necessary to account for them to accelerate particle B. If a bar strikes particle B just before it beeps, then particle B has to move away from particle A a bit. It cannot know how much it will have to move, it has to move until it beeps, so I guess it has to follow the bar during this time even if it is moving at c, because then, it would stay synchronized with it. I think that, this way, it will move the same distance particle A had moved before. How about programming the particles' beeps? We could then emit the bars continuously and observe the particles staying on sync with them if they are at the right distance from one another. The bars should also disappear when they are on sync with the particles, because the light emitted by the particle would interfere destructively with the incoming light. This way, during acceleration, we would see some bars escaping the system, which is also the case for light when we accelerate real particles in real accelerators.

Quote

The result is rather fun - see if you can keep the yellow particle on the screen, and see if you can stop it moving once you've started it.

I can almost stop it, but the motion is not constant: it slows down and accelerates when the computer does. I have too many windows opened in my browser for the computer speed to stay constant. Is that why you want a fast computer?

Quote

Next time we'll have to add more code to use the bar-particle interactions to control the accelerations instead of the buttons, but if you can work out how the new parts of the existing program work, you might just know enough to be able to try some experimental programming of the next step yourself.

I'm still trying to follow up.

David Cooper · « **Reply #26 on:** 20/08/2017 02:27:42 »

Quote from: Le Repteux on 19/08/2017 21:12:23

You seem to be giving importance to the collision with the bars during acceleration, and I think we should not.

Well, you have to pin down what happens by working out what (1) what causes effects, and (2) what are the effects. If the arrival of a bar doesn't change the acceleration, neither particle can make the other particle move unless the transfer of energy or information is performed in some other way that doesn't involve the bars.

Quote

What you are actually trying to figure out is how we are going to bring mass into consideration, and I find it difficult to simulate because the mass induced by the resistance to acceleration between the components is a lot more important that the one induced by the resistance to acceleration between the particles, and because what we are actually trying to simulate is only the steps between the particles.

I have no idea how mass is going to come into this other than being related to the speed of acceleration. We have an arbitrary strength of acceleration force which relates to an arbitrary mass.

Quote

I figured that, instead of accounting for the blueshift particle A would produce on incident light at the beginning of its acceleration, we could simplify the problem while accounting for it only at the end of its acceleration, but it doesn't seem to work, so the question remains: how do we account for blueshift during acceleration of particle A?

It would be easiest if I show you a variety of ways of doing things so that you can understand how they work, and then you'll be able to work out what you want to do differently, so we can keep modifying the simulation in whatever direction you want to take it.

Quote

If we keep constant the frequency of the steps, it seems that there is only one way: their length has to be reduced a bit, and it has to be reduced a fraction of the blueshift: the more the blueshift, the more the reduction.

Mechanistically, that needs the particles to have in-built clocks which aren't slowed by their speed of travel through space so that they can maintain a constant step rate. They would then decelerate if they receive a bar sooner than normal and accelerate if it's late. That would run into a problem though because the leading particle would always receive the signal from the trailing particle late while the trailing one would receive the other signal early, so they would get further and further apart as the front one keeps accelerating and the following one keeps decelerating.

Quote

At each step forward, a small step backward would have to be subtracted.

What happens if the particles are already moving and something acts on the front one to decelerate it? That would lead to the particles becoming closer together as the slow down. We'll be able to test that with the simulation, but there are a lot of things that clearly won't work and really shouldn't need to be tested.

Quote

Again, you seem to allow importance to the incoming bars during acceleration of particle A, and I think it is not necessary. On the other hand, it is necessary to account for them to accelerate particle B. If a bar strikes particle B just before it beeps, then particle B has to move away from particle A a bit. It cannot know how much it will have to move, it has to move until it beeps, so I guess it has to follow the bar during this time even if it is moving at c, because then, it would stay synchronized with it. I think that, this way, it will move the same distance particle A had moved before. How about programming the particles' beeps? We could then emit the bars continuously and observe the particles staying on sync with them if they are at the right distance from one another. The bars should also disappear when they are on sync with the particles, because the light emitted by the particle would interfere destructively with the incoming light. This way, during acceleration, we would see some bars escaping the system, which is also the case for light when we accelerate real particles in real accelerators.

We can build and modify the program to cover all of that, and then abandon all the things that don't do anything useful.

Quote

I can almost stop it, but the motion is not constant: it slows down and accelerates when the computer does. I have too many windows opened in my browser for the computer speed to stay constant. Is that why you want a fast computer?

It should run at a constant speed regardless of what the computer's doing to the processor speed, but it could freeze for a moment repeatedly if the processor can't keep up with all the things it's trying to do. It isn't necessary to use a fast computer - I'm currently using something with an Atom processor and it's more than fast enough - the only problem with it is that it runs XP and has too low a screen resolution to work adequately with later operating systems, which leaves it struggling to handle browsers. (Firefox kept upgrading itself until it froze, whereas Chrome decided to stop upgrading itself instead and is becoming more risky to use as a result of the lack of security fixes, a problem that affects the operating system too.) But so long as it can keep doing the job, I'll postpone the acquisition of a new machine because they keep getting better over time and it's always best to wait as long as you can.

Anyway, I've got a new version of the simulation ready for you. The previous version shows you how hard it is to control what a particle does with occasional accelerations - it can go wildly out of control very quickly, and the same applies when the those occasional accelerations are tied to the infrequent arrival of bars (which is what happens with the new version), which means you have to keep the acceleration force low. You need to nudge the yellow particle using a button to get things going - otherwise the particles will just sit where they are forever. You can click this button once or many times depending on how much you want to accelerate it. You can also test deceleration by nudging the blue particle the other way, and this shows that the particles do indeed end up closer together when you decelerate them. The program simply calculates an acceleration force whenever a bar hits a particle by comparing the speeds of the receiving particle and the source particle (using the speed of the source particle when that bar was sent out from it rather than its current speed because they aren't always the same if you've nudged a particle). This provides an energy value equivalent to the Doppler shift. So, we now have a functional simulation which can be adapted in all manner of different directions and have extra complexity added to it.

[Edited the code to correct a display fault - copying code from Notepad keeps breaking it as it adds in extra returns in the middle of some lines. I normally check it after posting, but my machine froze and I decided the check could wait till today, so it's lucky it was just a display issue that made one of the bars the wrong size.]

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
		r+=rv*gr; g+=gv*gr; // update bar positions
		if(ty>=fb){r=b; ty=0, cdr=0; // reuse old bars for new
			   pbv=bv}   // store speed of b at this moment
		if(tb>=fy){g=y; tb=0; cdg=0; // ... when timers time out
			   pyv=yv}   // store speed of y at this moment

		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

		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
		ping1.innerHTML=ya; ping2.innerHTML=ba;
		cd(); // call collision detection function
	}

	function setup() // we'll 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=100; // initial x-coord locations of the dots
	        bo=-50; // offset to correct b's display location
	yv=0; bv=0; // initial speeds for particles
	pyv=0; pbv=0; // particle speeds when light sent out

	r=100; 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

	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=1000; // initial bonding-light frequencies per zeptosecond
	fb=1000; // (one for each particle) [1000 = 1x10^18Hz]

	a=0.001; // 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

	cdr=0;cdg=0; // collision detection var.s

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

	function cd() // collision detection
	{     if(r<=y && cdr==0){ya=pbv-yv; cdr=1}
	      if(g>=b && cdg==0){ba=pyv-bv; cdg=1}
	} 

// When bar hits particle, we calculate new acceleration value.
// The "ya=pbv-yv" above calculates the speed (and thereby energy) of the red
// bar relative to both the particle it came from and the one it has just hit so
// that we can generate a new acceleration value from this to act on the hit
// particle.

	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 nudgey() // accelerate y to right
	{	yv+=0.001}

	function nudgeb() // accelerate b to left
	{	bv-=0.001}

	</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>
<p>Latest acceleration applied to yellow particle = <a id="ping1"></a>
<br>Latest acceleration applied to blue particle = <a id="ping2"></a>
<p>Fundamental force strength = <a id="force">0.001</a>
<p> <input type="button" value="Force +" onclick="inca()"/> <input type="button" value="Force -" onclick="deca()"/> <input type="button" value="Nudge yellow right" onclick="nudgey()"/> <input type="button" value="Nudge blue left" onclick="nudgeb()"/>
<p>
Click a "nudge" button to start things moving.

</BODY>
</HTML>

Le Repteux · « **Reply #27 on:** 21/08/2017 03:07:35 »

While accelerating both particles before their acceleration had the time to accelerate the other particle, I succeeded to contract them to less than zero distance, so that they were crisscrossing each other continuously. I could even imagine that they were orbiting one around the other. Then I accelerated them more, and they began staying on the wrong side of the screen, sending their bars away from the other particle, nevertheless continuing to make an effect on one another, as if the software was sending invisible bars between them.

Quote

Mechanistically, that needs the particles to have in-built clocks which aren't slowed by their speed of travel through space so that they can maintain a constant step rate. They would then decelerate if they receive a bar sooner than normal and accelerate if it's late. That would run into a problem though because the leading particle would always receive the signal from the trailing particle late while the trailing one would receive the other signal early, so they would get further and further apart as the front one keeps accelerating and the following one keeps decelerating.

We get the same kind of result when we try to use light to produce orbital motion between two bodies: they begin to swirl away from one another. My model should help us to analyze that problem. When we nudge particle A, we automatically contract the distance between the two particles, but also between the bars, so I think that if a bar would be emitted at each beep, the first bar to be out of sync with particle B would strike it too soon, not too late, and since it is the inverse for particle B, its bars would strike particle A too late, not too soon. Since the frequency of the bars is very low on the simulation, I could contract the distance a lot because I could nudge A a lot of times before it emitted a bar that would account for the acceleration. With bars emitted at a higher frequency, the distance between the bars would contract sooner and the bars would thus nudge the other particle sooner.

Nevertheless, I think that the particles would not stay at a constant distance from one another after the acceleration would have stopped. Why? Because we cannot account for the steps between their components. Nature accounts for them, and it even accounts for the steps between their own components, but a simulation cannot. Maybe we could account for a constant change in distance between the two particles while correcting the distance constantly as soon as the acceleration would have stopped, and as long as we wouldn't change the speed of the system. That's what they do for the GPS: they check the satellites' clocks at constant intervals, and they correct them if they are a bit out of sync with the earthbound ones. Fortunately, it doesn't prevent the system from working properly.

Quote

What happens if the particles are already moving and something acts on the front one to decelerate it? That would lead to the particles becoming closer together as they slow down. We'll be able to test that with the simulation, but there are a lot of things that clearly won't work and really shouldn't need to be tested.

In my model, no motion with regard to ether means no doppler effect between the particles, so if we accelerate the system to the right and stop it afterwards, there shouldn't be any doppler effect left between the particles. If contraction happens at acceleration and if we stop the system after a while, contraction should also resorb, not increase. It might increase for a while and then rebound the same way a balloon contracts and rebounds. How to stop the system without getting a rebound is another problem. It probably has to be slowed down progressively until it hits a limit that the particles cannot account for.

Quote

I'll postpone the acquisition of a new machine because they keep getting better over time and it's always best to wait as long as you can.

Looks like my limit problem! Did you give it a dead line? :0)

Quote

The program simply calculates an acceleration force whenever a bar hits a particle by comparing the speeds of the receiving particle and the source particle (using the speed of the source particle when that bar was sent out from it rather than its current speed because they aren't always the same if you've nudged a particle). This provides an energy value equivalent to the Doppler shift.

It works when there is only one bar to account for, but if we had a thousand bars, we would need a thousand variables to account for them, and I suspect it would be too heavy. If we had a thousand bars to account for the distance between the beeps from particle A, the bars would automatically bring the doppler shift to particle B, and it could move along with the bars to keep beeping on sync with them. Of course, a thousand bars might be too close to one another for us to observe the shift, but we could show only one out of ten and get a good enough picture.

I didn't have time to study the language today, but I'll have it tomorrow. I'm eager to be able to handle the software a bit.

guest4091 · « **Reply #28 on:** 21/08/2017 18:03:51 »

Quote from: Le Repteux on 11/08/2017 14:32:28

The bond in question is the one that permits atoms to form molecules, or that permits nucleons to form nucleus.

The 1st is em fields, the electron cloud, the basis of chemistry.
The 2nd is the strong force, quark-gluon interactions, which is many orders of magnitude greater than the 1st.

Le Repteux · « **Reply #29 on:** 21/08/2017 18:40:25 »

Hi Phity,

You're right about the kind of bonds, but the idea is to consider that those bonds are executed at no more than the speed of light, and then simulate what could happen if we accelerate the system. In fact, it is a relativity issue applied to the scale of particles. Do you know how to handle JavaScript?

guest4091 · « **Reply #30 on:** 21/08/2017 19:14:03 »

Quote from: Le Repteux on 21/08/2017 18:40:25

Hi Phity,

You're right about the kind of bonds, but the idea is to consider that those bonds are executed at no more than the speed of light, and then simulate what could happen if we accelerate the system. In fact, it is a relativity issue applied to the scale of particles. Do you know how to handle JavaScript?

No, but it has similarities to other languages.

Le Repteux · « **Reply #31 on:** 21/08/2017 20:52:53 »

You're welcome to participate if you wish. The issue is uncertain, but the pleasure is proportional to the uncertainty. :0)

David Cooper · « **Reply #32 on:** 22/08/2017 00:48:57 »

Quote from: Le Repteux on 21/08/2017 03:07:35

While accelerating both particles before their acceleration had the time to accelerate the other particle, I succeeded to contract them to less than zero distance, so that they were crisscrossing each other continuously. I could even imagine that they were orbiting one around the other. Then I accelerated them more, and they began staying on the wrong side of the screen, sending their bars away from the other particle, nevertheless continuing to make an effect on one another, as if the software was sending invisible bars between them.

Once you've got the blue particle to the left of the yellow one, you break the collision detection mechanism and get false hits which reset the acceleration forces. The hits occur as soon as a bar reaches or is found to be past its target particle, so once the particles have passed each other, you get an immediate false hit as soon as a new bar is sent out. That could be fixed by modifying the code in cd() to prevent a hit being registered if y>b: e.g. if(r<=y && cdr==0 && y<b){...etc. So, the orbiting is fake - once yellow is to the right of blue, the acceleration shouldn't be changed again unless it is already strong enough to bring yellow back to the left of blue.

Quote

We get the same kind of result when we try to use light to produce orbital motion between two bodies: they begin to swirl away from one another. My model should help us to analyze that problem. When we nudge particle A, we automatically contract the distance between the two particles, but also between the bars, so I think that if a bar would be emitted at each beep, the first bar to be out of sync with particle B would strike it too soon, not too late, and since it is the inverse for particle B, its bars would strike particle A too late, not too soon. Since the frequency of the bars is very low on the simulation, I could contract the distance a lot because I could nudge A a lot of times before it emitted a bar that would account for the acceleration. With bars emitted at a higher frequency, the distance between the bars would contract sooner and the bars would thus nudge the other particle sooner.

The frequency of the bars is already 1000 times as high as visible light - we're running the simulation very slowly at the moment, and we're also using very high accelerations. I think it would be better not to keep applying the acceleration between the bars, but just to apply one acceleration at the time of each hit and then run the simulation a bit faster (but not so much faster that we can no longer see what the bars are doing). We can then use bigger accelerations, and importantly, the particles won't get out of control so easily if we increase the forces. Of course, the bars needn't only occur once per crest/trough of a wave - we can have 2,4, 8, maybe 16 or more of them because the receiving particle can compare them with some component of itself that oscillates at the same frequency (a clock) and which can continually tell when there's Doppler shift and react to it. We needn't show all the bars either - we can adjust the accelerations continually whether there's a bar shown on the screen reaching a particle or not. This would make everything much quicker at adjusting to speed changes of the other particle and keep things under better control.That would mean we don't need to speed up the sim and that we can keep the bars visible and moving at sensible speeds across the screen while having much more responsive action going on.

Quote

Nevertheless, I think that the particles would not stay at a constant distance from one another after the acceleration would have stopped. Why? Because we cannot account for the steps between their components. Nature accounts for them, and it even accounts for the steps between their own components, but a simulation cannot.

A simulation can do everything - you just have to work out what the rules are that it is to apply, and part of that will involve defining what a step is.

Quote

Maybe we could account for a constant change in distance between the two particles while correcting the distance constantly as soon as the acceleration would have stopped, and as long as we wouldn't change the speed of the system. That's what they do for the GPS: they check the satellites' clocks at constant intervals, and they correct them if they are a bit out of sync with the earthbound ones. Fortunately, it doesn't prevent the system from working properly.

One thing shows up clearly from the existing simulation, and that is that just responding to Doppler shift with simple rules doesn't work - the particles get closer together as you accelerate them, but they also get closer together as you decelerate them. You need to find rules that move them further apart again on deceleration to restore the original separation when they're at rest again. Particles are clocks (in that they have functionality that operates in cycles), so you could use that to maintain distances between particles which would contract the separation length at higher speeds of travel exactly as relativity has them contract, but the problem with that is that they aren't pinging serial numbers back and forwards to each other in any way that would tell a particle that it's been sent a reply to a specific message which can be used to calculate the apparent round-trip distance, so what can you have that would be a more realistic mechanism? Forces that reduce over distance can do it. Standing waves might do it. Whatever you decide to try out, all you have to do is work out the rules as to what effects what, when it affects it, and how it affects it, then you should be able to produce the right maths to go with it and fit that into a simple program which can run the maths and rules. You also have to work out what the results of a simulation actually say - when you see two particles taking turns to wobble a bit to the right and then to the left such that they're repeatedly getting further apart then closer together, that looks to me like heat energy which doesn't add to their combined motion, and it's energy that could be radiated off.

Quote

In my model, no motion with regard to ether means no doppler effect between the particles, so if we accelerate the system to the right and stop it afterwards, there shouldn't be any doppler effect left between the particles. If contraction happens at acceleration and if we stop the system after a while, contraction should also resorb, not increase. It might increase for a while and then rebound the same way a balloon contracts and rebounds. How to stop the system without getting a rebound is another problem. It probably has to be slowed down progressively until it hits a limit that the particles cannot account for.

One problem with your model is that you accelerate these bonded particles by accelerating only the rear one. In the real universe you can pull something up to higher speed and it still length-contracts. What happens if we reverse the direction of the "nudge blue left" button to turn it into "nudge blue right" (while adjusting the code that does the actual nudging)? All you need to do to try it out is change a negative to a plus in the function nudgeb(). ... Yes, they settle down after a while further apart than they started. This is the sort of thing your theory needs to fix in a hurry.

Quote

It works when there is only one bar to account for, but if we had a thousand bars, we would need a thousand variables to account for them, and I suspect it would be too heavy.

It can handle a hundred bars, and probably a thousand - the thing to avoid is displaying them to the screen because that's what really slows things down in JavaScript. (It wouldn't be a problem for a machine code program with more direct control of screen memory, but we're using JavaScript for reasons of simplicity and compatibility.)

Quote

If we had a thousand bars to account for the distance between the beeps from particle A, the bars would automatically bring the doppler shift to particle B, and it could move along with the bars to keep beeping on sync with them. Of course, a thousand bars might be too close to one another for us to observe the shift, but we could show only one out of ten and get a good enough picture.

I don't know what you mean by having particles move along with the bars - we don't want the particles moving at c.

Quote

I didn't have time to study the language today, but I'll have it tomorrow. I'm eager to be able to handle the software a bit.

There's not much to it. The accelerations are calculated in cd() and are then applied in run(). I've made a new version in which the accelerations are only applied once per bar and where those accelerations are stronger, but it doesn't look greatly different and still goes out of control if you increase the fundamental acceleration force, so there's no point in posting it until I've created more "hidden bars" to adjust the accelerations more often - it should end up as a much better version of the program.

Le Repteux · « **Reply #33 on:** 22/08/2017 19:47:24 »

Quote from: David Cooper on 22/08/2017 00:48:57

Once you've got the blue particle to the left of the yellow one, you break the collision detection mechanism and get false hits which reset the acceleration forces. The hits occur as soon as a bar reaches or is found to be past its target particle, so once the particles have passed each other, you get an immediate false hit as soon as a new bar is sent out. That could be fixed by modifying the code in cd() to prevent a hit being registered if y>b: e.g. if(r<=y && cdr==0 && y<b){...etc. So, the orbiting is fake - once yellow is to the right of blue, the acceleration shouldn't be changed again unless it is already strong enough to bring yellow back to the left of blue.

I get it!

Quote

The frequency of the bars is already 1000 times as high as visible light - we're running the simulation very slowly at the moment, and we're also using very high accelerations. I think it would be better not to keep applying the acceleration between the bars, but just to apply one acceleration at the time of each hit and then run the simulation a bit faster (but not so much faster that we can no longer see what the bars are doing). We can then use bigger accelerations, and importantly, the particles won't get out of control so easily if we increase the forces. Of course, the bars needn't only occur once per crest/trough of a wave - we can have 2,4, 8, maybe 16 or more of them because the receiving particle can compare them with some component of itself that oscillates at the same frequency (a clock) and which can continually tell when there's Doppler shift and react to it. We needn't show all the bars either - we can adjust the accelerations continually whether there's a bar shown on the screen reaching a particle or not. This would make everything much quicker at adjusting to speed changes of the other particle and keep things under better control.That would mean we don't need to speed up the sim and that we can keep the bars visible and moving at sensible speeds across the screen while having much more responsive action going on.

Why not emit a bar only when hitting the nudge button, and add a function to keep nudging as long as the button is on? This way, if we would stop nudging A before the bar would hit B, we could better study the effect an acceleration of A would have on B and vice-versa. B should move the same way A had moved before, and A should stop moving at the same rate it took to accelerate, it should thus get at rest before the bar from B would have the time to begin nudging it again. In principle, the motion of each particle should look like a wave, and that wave should get more complex if we would go on nudging A after the bar would hit B.

Quote

A simulation can do everything - you just have to work out what the rules are that it is to apply, and part of that will involve defining what a step is.

The wavelike motion I'm describing is what I call a step, and if we were to account for the components, they would be making similar steps but at a much higher frequency. In fact, the more frequent steps between the components would have to travel the same distance one step between the particles would have to travel during the same time. It would also be the light escaped from the frequent components' steps that would produce later on the less frequent steps between the particles.

Quote

One thing shows up clearly from the existing simulation, and that is that just responding to Doppler shift with simple rules doesn't work - the particles get closer together as you accelerate them, but they also get closer together as you decelerate them.

I'm not sure that we would get a contraction with what I am suggesting to try. I think that there would be no overall contraction if we would stop nudging A before the first bar hits B for example, but what would happen if we would go on nudging A is too complicated for me to figure out. We could add a variable to tell us the distance between the two wavelike motion of the particles, but if we would use the beginning of those waves as a marker for instance, I think that the distance would always stay the same. The same reasoning would apply if we would nudge B away from A: it would create the same wavelike motion between the particles, and no difference in distance should be observed between the waves.

Quote

You also have to work out what the results of a simulation actually say - when you see two particles taking turns to wobble a bit to the right and then to the left such that they're repeatedly getting further apart then closer together, that looks to me like heat energy which doesn't add to their combined motion, and it's energy that could be radiated off.

That wobbling happens because we are nudging the particles towards one another. If we could nudge them at the same time, they should vibrate on the spot. It is that deduction that made me guess such a vibration could be the cause for the increasing force we observe while compressing a solid body.

Quote from: David

Quote
If we had a thousand bars to account for the distance between the beeps from particle A, the bars would automatically bring the doppler shift to particle B, and it could move along with the bars to keep beeping on sync with them. Of course, a thousand bars might be too close to one another for us to observe the shift, but we could show only one out of ten and get a good enough picture.
I don't know what you mean by having particles move along with the bars - we don't want the particles moving at c.

A particle has to begin moving when the beep arrives, and it has to stop moving when the beep leaves, so that was only a technical way for B to beep on sync with the wave with only a bar to guide its motion. I now think that if we nudge B with a bar that remembers A's nudge, and if A and B decelerate the same way they have accelerated, nudge by nudge, then we should get the wavelike motion I am talking about.

Quote

There's not much to it. The accelerations are calculated in cd() and are then applied in run(). I've made a new version in which the accelerations are only applied once per bar and where those accelerations are stronger, but it doesn't look greatly different and still goes out of control if you increase the fundamental acceleration force, so there's no point in posting it until I've created more "hidden bars" to adjust the accelerations more often - it should end up as a much better version of the program.

More hidden bars, and if you think it's worth trying it, a bar emitted by A only at the moment we hit the nudge button, which means that a bar would be emitted by B only at the moment the bar from A would hit it, and so on for all the next bars. I suggest that the nudge button becomes unavailable as soon as we raise the finger from the mouse, so that only one bar is displayed on the screen at each attempt.

I tried the last version again, and I realized that A began moving backward after having been nudged forward whenever a bar from B would hit it. At most, A should decelerate to rest if B was at rest when its bar was emitted, and if it was moving to the right, that bar should pull A to the right.

David Cooper · « **Reply #34 on:** 23/08/2017 00:29:47 »

Quote from: Le Repteux on 22/08/2017 19:47:24

Why not emit a bar only when hitting the nudge button, and add a function to keep nudging as long as the button is on?

How much nudging does it need? If you want to repeat a nudge many times, click the button and then hold down the return key to repeat its action many times, but it shouldn't need many repeats. If you want different nudge code, you can redesign it and add new buttons for different sizes of nudge.

Quote

This way, if we would stop nudging A before the bar would hit B, we could better study the effect an acceleration of A would have on B and vice-versa. B should move the same way A had moved before, and A should stop moving at the same rate it took to accelerate, it should thus get at rest before the bar from B would have the time to begin nudging it again. In principle, the motion of each particle should look like a wave, and that wave should get more complex if we would go on nudging A after the bar would hit B.

The only way to get B to accelerate in the same way A did would be to send a lot more signals out from A as its speed changes. At the moment, if you click nudge in the pattern N_N_N_N between bar hits it has the same effect as using the pattern NN__NN______N or NNNNN because all that does is add five times an additional amount of speed to the particle. If you want to change the way the particle accelerates, you need to apply a different amounts of nudging between bars over several cycles. Sending out a new bar for each nudge would be a very different way of working, taking us away from a light frequency into nudge frequency, and that would eliminate the role of light in any meaningful sense. The bars would transfer the same information though, bouncing to and fro between the particles until the speeds are equalised, at which point the bars could be absorbed and not be sent back, but the effect of this on the particles would be very little different from what we're already doing except that the frequency of the exchange of information would be much more variable.

Quote

The wave I'm describing is what I call a step, and if we were to account for the components, they would be making similar steps but at a much higher frequency. In fact, the numerous steps between the components would have to travel the same distance than one step between the particles, and in the same time. It would also be the light escaped from the numerous components' steps that would produce later on the step between the particles.

How does light escape? What are the rules that explain when this happens and how much light escapes?

Quote

I'm not sure that we would get a contraction with what I am suggesting to try. I think that there would be no overall contraction if we would stop nudging A before the first bar hits B for example, but what would happen if we would go on nudging A is too complicated for me to figure out.

As it stands, there is nothing to determine distance between the particles other than how much they have been nudged closer together, so you need to add an additional mechanism to the model to handle it.

Quote

We could add a variable to tell us the distance between the two wavelike motion of the particles, but if we would use the beginning of the waves as a marker for instance, I think that the distance would always stay the same. The same reasoning would apply if we would nudge B away from A: it would create the same wavelike motion between the particles, and no difference in distance should be observed between the waves.

You need to come up with some maths to drive the action such that the particles regulate their relative positions. Everything needs to be specified in terms of causes and effects. If it involves equations, show the equations and explain what to do with the numbers that are produced from them. Then we can work out how to rewrite them as program code. What we cannot do is program for fuzzy notions which haven't been expanded into a full set of "if x then do y" rules.

Quote

That wobbling happens because we are nudging the particles towards one another. If we could nudge them at the same time, they should vibrate on the spot. It is that deduction that made me guess such a vibration could be the cause for the increasing force we observe while compressing a solid body.

I actually see with the latest version (not ready to post yet) the vibrating disappearing quickly with the "heat" energy vanishing by magic. I'll need to think about why that happens.

Quote

A particle has to begin moving when the wave arrives, and it has to stop moving when the wave leaves, so that was only a technical way for B to beep on sync with the wave with only a bar to guide its motion. I now think that if we nudge B with a bar that remembers A's nudge, and if A and B decelerate the same way they have accelerated, nudge by nudge, then we should get the wavelike motion I am talking about.

Rather than repeatedly rewriting the simulation code, it might be better just to write a full description of the rules that a simulation should run. That means producing a list of rules stating things like, "when a bar hits a particle, x should be added to its speed", and "if a bar has been received and hasn't been completely absorbed, a new bar should be sent out the other way with the value y tied to it", etc. I want to see a tight specification for the simulation that tells me exactly what it should be programmed to do so that there's nothing left needing to be guessed at.

Le Repteux · « **Reply #35 on:** 24/08/2017 21:48:09 »

Hi David,

I'm trying to figure out how particle A would behave if we would stop the acceleration after a few nudges, and I have a hard time. A should stop moving after a while because it faces blueshift from B, but the same blueshift can be obtained during a long but weak acceleration, and during a short but strong one, a difference I think a real particle cannot account for just by considering the doppler effect it produces on the waves from the other particle. The problem is simpler when doppler effect from A hits B: B only has to accelerate for its own waves to stay on sync with the waves from A, and it could decelerate the same way if it had that information from A. Of course, we could also consider that A would decelerate for its waves to get back on sync with the waves from B, but at what rate? We could also consider that it is B that is accelerating towards A, but we wouldn't know either its rate of deceleration.

Well, either I'm slow or I'm wrong, because I still don't understand the picture after two days. You have any idea? Is there something I don't get?

David Cooper · « **Reply #36 on:** 25/08/2017 02:54:06 »

Quote from: Le Repteux on 24/08/2017 21:48:09

I'm trying to figure out how particle A would behave if we would stop the acceleration after a few nudges, and I have a hard time. A should stop moving after a while because it faces blueshift from B, but the same blueshift can be obtained during a long but weak acceleration, and during a short but strong one, a difference I think a real particle cannot account for just by considering the doppler effect it produces on the waves from the other particle.

The problem is the long delays in changing the acceleration, but the new version (see below sends fifteen invisible bars in between the visible ones, so you get better speed adjustments. You can now nudge A a few times, wait a couple of seconds, then nudge it again a few times just before the red bar hits it - you will then see B react to the two accelerations separately. You will also find delays in each particle responding to the accelerations of the other, but they gradually settle down until they are moving at the same speed.

Quote

The problem is simpler when doppler effect from A hits B: B only has to accelerate for its own waves to stay on sync with the waves from A, and it could decelerate the same way if it had that information from A. Of course, we could also consider that A would decelerate for its waves to get back on sync with the waves from B, but at what rate? We could also consider that it is B that is accelerating towards A, but we wouldn't know either its rate of deceleration.

It would be possible to get the program to give you lists of numbers as to how the particles accelerated and decelerated, but you can get a fair idea of what those numbers would be just by watching how they behave visually. The relative motion of the particles is clearly damped.

The program still breaks if the particles pass each other, but they shouldn't be able to reach each other anyway if they maintain their separation properly - that needs different rules. As it stands, they get closer together both on acceleration and deceleration. If you click on "nudge yellow" and then hold down the return key, you'll see that the acceleration stops working after a short time - this is because it is reacting to the difference in speed between the two particles and it is being slowed down more as the speed difference grows. Another problem with the program at the moment is that it allows particles to accelerate to >c, but there's no need to rush to improve that as there are more important things to fix with the theory. Note that the function cd() has been removed - its content has been moved into the main function run(). The program is more bulky, but the additions to it since the last time are really just duplications of bar functionality to handle 16 times as many bars as before, though they are invisible bars. It may be worth making some or all of them visible in the next version.

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

	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 nudgey() // accelerate y to right
	{	yv+=0.05}

	function nudgeb() // accelerate b to left
	{	bv-=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>
<p>Latest speed of yellow particle = <a id="ping1"></a>
<br>Latest speed of blue particle = <a id="ping2"></a>
<p>Fundamental force strength = <a id="force">0.5</a>
<p> <input type="button" value="Force +" onclick="inca()"/> <input type="button" 

value="Force -" onclick="deca()"/> <input type="button" value="Nudge yellow right" 

onclick="nudgey()"/> <input type="button" value="Nudge blue left" onclick="nudgeb

()"/>
<p>
Click a "nudge" button to start things moving.

</BODY>
</HTML>

Le Repteux · « **Reply #37 on:** 26/08/2017 19:24:57 »

Nice improvements David! We're beginning to get what we're expecting.

Quote

It would be possible to get the program to give you lists of numbers as to how the particles accelerated and decelerated, but you can get a fair idea of what those numbers would be just by watching how they behave visually. The relative motion of the particles is clearly damped.

Here are a few observations:

-When we nudge A only once, there shouldn't be any damping after a while and there is: B should be making the same step A had made before and vice-versa.

-It also seems to accelerate faster than it decelerates, but it shouldn't be so since you use the same acceleration formula in both cases. Is there another reason why the two rates wouldn't be the same?

-The mean distance between the particles also reduces constantly after a while with only one nudge and it should not, unless we think that bodies should be shrinking with time.

-The speed of the particles also gets down with time after only one nudge and it should not, otherwise inertial motion would not be constant at our scale. Maybe the reason they do so is the same that causes the damping.

I discovered something interesting about a phenomenon that I considered a problem: since the distance light travels between the particles is longer to the right than to the left, they should be running like animals, making a long jump ahead with the rear legs because the front legs are getting away from them, and a short jump with the front legs because the rear legs are catching them. Chronologically, there should be more time between A and B than between B and A (like this: A BA BA BA BA ...), but as for animals, it shouldn't affect their overall speed. I thought it would cause a synchronization problem, but as we can see, it is not the case for animals, so it should not be the case for particles either.

About the deceleration A suffers after it has accelerated during the time it sends one bar, we can use its speed and decelerate it to rest during one bar too, but if it had accelerated during ten bars, how could it know it has to decelerate during ten bars? The only thing A can know instantly is if the incoming bars from B arrive at the same time it sends its own bars, and if they arrive too soon because it has been accelerated towards B, it knows it has to decelerate, but it doesn't know how fast. It could stop moving and wait till the bars from the acceleration of B are back, and then it could move toward B at each incoming bar to stay on sync with the bars, but it means that B also would stop to move and wait for the bars from A to be back. I don't know what would happen to the bond during a long acceleration, but I think it's worth a trial. It is interesting to note that even if this way, the atoms would stop moving inside the molecule, the molecule itself would not stop moving. We can even compare with our own feet that stop on the ground while we keep on moving. But this behavior causes a problem: during the time an atom would be waiting for the light from the other atom to come in, its components would always be moving, because it takes a lot less time for their light to make the roundtrip.

I also use to say that randomness is the characteristic of any change, so that particles should accelerate (and decelerate) at random and let the environment chose the right direction or speed, but I think it is too soon to consider that possibility.

David Cooper · « **Reply #38 on:** 27/08/2017 01:06:10 »

Quote from: Le Repteux on 26/08/2017 19:24:57

-When we nudge A only once, there shouldn't be any damping after a while and there is: B should be making the same step A had made before and vice-versa.

There's a problem with the timing of the nudges which leads to it having wildly different effects on the distance travelled by a particle before it is slowed or halted by a bar - it would be better if the nudges could only take place at times when that particle is also being hit by a bar rather than at any points between bar arrivals. I suspect this may also have allowed some energy to go missing. It show how easy it is for bugs to mess up even a simple program.

The damping is caused when the fundamental force is set to 0.5 or lower because that spreads the effect from one time slice over two or more slices, and over time that spreads the responses across all 16 time slices and thereby equalises the speeds of the two particles (if you wait long enough). Click the "Force+" button to set it to 1 instead of 0.5, and then you can see that the particles respond to each other by copying the each other's action each time without any damping. Higher values amplify the difference and send the particles ever faster in opposite directions, so they shouldn't be used.

Quote

-It also seems to accelerate faster than it decelerates, but it shouldn't be so since you use the same acceleration formula in both cases. Is there another reason why the two rates wouldn't be the same?

That was again the fault of the fundamental force not being set to 1 - it seems obvious now that it should never have been set to any other value, and yet I think it had to be much lower with earlier versions of the program to stop it going wrong (I can't now remember why that was the case), and it still isn't behaving properly with it set to 1, so there's a bug that needs to be fixed.

Quote

-The mean distance between the particles also reduces constantly after a while with only one nudge and it should not, unless we think that bodies should be shrinking with time.

I don't think I've seen that happen - they settle down to the same speed because of the damping and then the separation becomes fixed (i.e. constant), but even when it's varying, I think the average separation is already fixed.

Quote

-The speed of the particles also gets down with time after only one nudge and it should not, otherwise inertial motion would not be constant at our scale. Maybe the reason they do so is the same that causes the damping.

The average speed should not fall, but if there is damping (due to using 0.5 for the so-called "fundamental force" - it turns out that this is really just a damping value), the speed appears to fall, but it is merely being shared out more evenly over time.

Quote

I discovered something interesting about a phenomenon that I considered a problem: since the distance light travels between the particles is longer to the right than to the left, they should be running like animals, making a long jump ahead with the rear legs because the front legs are getting away from them, and a short jump with the front legs because the rear legs are catching them.

WIth the damping removed, the distance can be restored repeatedly to the original separation, but on average it is reduced as the particles move faster. When the bug is fixed, it should be possible to have a nudge in a series of time slices narrow the gap a lot further before the front particle reacts to the first one, at which point it will respond to the first by removing some of the contraction before it is contracted a bit more by the next, and it will never be able to remove all the contraction because the rear particle is accelerating and decelerating just as often. I think this is getting closer to what you wanted to do from the start, so the bug needs to be fixed to make it happen. It will be interesting to see if it can be done in a way that ties in with relativity's length-contraction, and maybe it can once we add in the effects of relativistic mass (which is, after all, the real cause of length-contraction anyway).

Quote

About the deceleration A suffers after it has accelerated during the time it sends one bar, we can use its speed and decelerate it to rest during one bar too, but if it had accelerated during ten bars, how could it know it has to decelerate during ten bars?

That's easy enough - each bar carries a stored value with it for the speed of the particle that it came from recorded at the time when it left, so if you have an acceleration in each of ten time slices, they will be delivered to the other particle by ten different bars and it will respond in ten time slices too.

Quote

It is interesting to note that even if this way, the atoms would stop moving inside the molecule, the molecule itself would not stop moving.

With the force set to 1 instead of 0.5, you see one particle move and then stop, then the other particle reacts a while later by doing the same thing, then the first particle repeats its original action when the signals get back to it, and on it goes like that. On average the particle is moving the whole time, but much of the time both particles are stationary (and simultaneously stationary too). But the action is carried on by the signals in flight between the two which are in a sense carrying energy.

Quote

But this behavior causes a problem: during the time an atom would be waiting for the light from the other atom to come in, its components would always be moving, because it takes a lot less time for their light to make the roundtrip.

Spread out particles where you can't pin down where and when they are... Sounds familiar, so not necessarily a problem. Anyway, I'll see if I can fix the program and then we can advance it further.

Le Repteux · « **Reply #39 on:** 27/08/2017 23:07:07 »

Quote from: David Cooper on 27/08/2017 01:06:10

There's a problem with the timing of the nudges which leads to it having wildly different effects on the distance traveled by a particle before it is slowed or halted by a bar - it would be better if the nudges could only take place at times when that particle is also being hit by a bar rather than at any points between bar arrivals. I suspect this may also have allowed some energy to go missing. It shows how easy it is for bugs to mess up even a simple program.

In my model, real particles can move only during the time they are sending a wave. 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.

Quote

The damping is caused when the fundamental force is set to 0.5 or lower because that spreads the effect from one time slice over two or more slices, and over time that spreads the responses across all 16 time slices and thereby equalizes the speeds of the two particles (if you wait long enough). Click the "Force+" button to set it to 1 instead of 0.5, and then you can see that the particles respond to each other by copying the each other's action each time without any damping. Higher values amplify the difference and send the particles ever faster in opposite directions, so they shouldn't be used.

It works great this way! A even seems to be nudged longer when by chance redshift from B coincides with a nudge.

Quote

I think this is getting closer to what you wanted to do from the start, so the bug needs to be fixed to make it happen. It will be interesting to see if it can be done in a way that ties in with relativity's length-contraction, and maybe it can once we add in the effects of relativistic mass (which is, after all, the real cause of length-contraction anyway).

In my model, mass is due to blueshift from particle B, and the increase of mass with the increase of speed is due to a step from a particle being an acceleration followed by a deceleration, so that the speed in the middle of a step is always higher that the speed of the molecule. When the speed of the molecule gets close to c, the speed of the step would be more than c if it could, but it cannot, so it takes more and more time to increase its speed instead. In other words, the two phenomenon seem to come from two different mechanisms.

Quote from: David

Quote
About the deceleration A suffers after it has accelerated during the time it sends one bar, we can use its speed and decelerate it to rest during one bar too, but if it had accelerated during ten bars, how could it know it has to decelerate during ten bars?
That's easy enough - each bar carries a stored value with it for the speed of the particle that it came from recorded at the time when it left, so if you have an acceleration in each of ten time slices, they will be delivered to the other particle by ten different bars and it will respond in ten time slices too.

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.

Quote

Quote
But this behavior causes a problem: during the time an atom would be waiting for the light from the other atom to come in, its components would always be moving, because it takes a lot less time for their light to make the roundtrip.
Spread out particles where you can't pin down where and when they are... Sounds familiar, so not necessarily a problem. Anyway, I'll see if I can fix the program and then we can advance it further.

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.

How can I write a computer simulation to test my theory

Le Repteux (OP)

Le Repteux (OP)

Le Repteux (OP)

Le Repteux (OP)

guest4091

Le Repteux (OP)

guest4091

Le Repteux (OP)

Le Repteux (OP)

Le Repteux (OP)

Le Repteux (OP)

Le Repteux (OP)