Naked Science Forum

On the Lighter Side => New Theories => Topic started by: Le Repteux on 07/08/2017 21:51:23

Title: How can I write a computer simulation to test my theory
Post by: Le Repteux on 07/08/2017 21:51:23
Hi Everybody!

I asked David Cooper  (http://www.magicschoolbook.com/science/relativity.html)to help me design a Java software for simulating my small steps and surprisingly, he accepted, and he also accepted to do it right here in case people would like to participate or even "learn the way to test their own theories through software", so here we are.

I guess you already know what my model is about, but here is a refreshing. I figure that mass and motion could be due to the bonding between two particles being limited to c, because it would then take time for the information to travel between them, which would desynchronize their bond during acceleration. The first particle to be accelerated would resist to move because it would produce blueshift right away on the information coming from the second particle, and that second particle would only move after a while because it would take time for the information from the acceleration to reach it. Resistance to acceleration is mass, so accelerating the first particle and stopping the acceleration before that information hits the second particle should give us the mass of the whole system, which is weird since the second particle has not been affected by the acceleration yet. Stopping the acceleration of the first particle means that it should decelerate to rest after a while until it doesn't produce anymore blueshift, and I figure that it should decelerate by the time the second particle would be accelerating, which means that the information from that second acceleration should hit the first particle at the moment it would be at rest, which means that that first particle should start accelerating again, and that it would do so while the second particle would be decelerating. A particle would then be accelerating while the other would be decelerating and vice-versa later on. Of course, we could accelerate the first particle for a longer time, but I need to know what will happen if we stop the acceleration at the moment the information from the acceleration hits the second particle.

That time shifted motion is hard to illustrate with static diagrams, and I think it would also be hard to put into equations, but I hope it can be simulated. What needs to be simulated is doppler effect from a particular motion that becomes a cause for another motion, so I think we would need that the particles are sources of waves, but I'm afraid that computers cannot produce them fast and precise enough, so I guess that we will have to rely on timing beeps, which computers cannot provide with absolute accuracy either, so the system will probably drift after a while, but I hope it won't drift too much, and that we can use a way to correct the drift if necessary. We want to see what will happen, so we need the particles to be as far as possible from one another on the screen, and that the beeps do not move too fast between them. We also need to see the beeps going both ways, so we might put them on two rows, one over the other, and we might use large vertical bars for the particles and smaller vertical bars, half the length of the large ones, for the traveling beeps. The beeps of the particles could be illustrated with the large bar hopping a small distance back and forth, disappearing and reappearing at the next location, and the beeps of the information could be illustrated by the small bars hopping the same small distance but in the same direction, but it means that all the rows would disappear and reappear once they would be full of beeps, so it would be necessary to accelerate and decelerate the bars between the beeps in order to see the motion. I guess we could more simply move the bars at a constant speed as you did in one of your simulation. This way, while both particles would be at rest, we would see the small bars integrating the large ones while new small ones would simultaneously be leaving the large ones.

To accelerate the first particle, we could move the left large bar a small distance, and double that distance each new beep. Normally, to be more precise, we should account for what would happen inside the particle during its acceleration, thus for the motion of its components, represented by the left side and the right side of the vibrating large bar, but to simplify the problem, we might as well just use the constant timing between the left and the right side of the bar, and move the second side after the first one would have moved, thus reducing the distance between the small bars by doppler effect, but not the size of the particles, thus not the distance between the two sides of the large bars. During acceleration, the small incoming bars and the accelerated large bar would get out of sync, and if the acceleration would stop at the moment the information from that acceleration would hit the other large bar, the accelerated one should decelerate until synchronization is recovered, thus it should get back to rest, and at the same rate it was accelerated.

By the time that large bar would start to decelerate, the second large bar should star accelerating to stay tuned with the incoming small bars, thus it should accelerate at the same rate the first large bar did, and then of course decelerate to rest in order to stay tuned with the small incoming ones. As I said, it's too difficult to imagine the effect the time gap between the components would have on the one between the particles during acceleration, so I think it is better to neglect it at first, and then adjust the simulation if we feel it is necessary. If anyone thinks he has a better way to initiate the simulation, he is welcome. I hope my description is good enough to be understood, but don't hesitate to ask for precisions if you want to participate to the simulation.

Ready for a crash? You should, because we never know what is going to come out of a new move! :0)
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 08/08/2017 23:20:17
This might help a few people here to write simple simulations to test their ideas. Trying to see if an idea works using just pen, paper and calculator is a hard task which really needs to be replaced with writing a proper program to cut out all the repetition and eliminate mistakes. Most programming environments aren't friendly, but JavaScript is something everyone can access easily without downloading any software. All you need is a text editor to write the code in and a browser (the one you're reading this with) to run it. You don't necessarily need any graphics for a simulation as it may be enough just to produce lots of numbers, but it can help you interpret the numbers more quickly if there's also some kind of graphical display to make it easier to work out what the numbers are actually saying, though you'll want to keep that minimal. Most of the program should be focused on crunching numbers rather than making things look pretty - we are really just looking to use the computer as an advanced kind of calculator.

I'll start things off with a simple JavaScript program here which we can develop into a simulation. You can see the program code below, and you should be able to copy-and-paste it into a text editor. Once you have done that, you must save the file as "simulation.htm" and then open that file (it should automatically open in your browser) - there is no need to upload it to the Internet as it will run straight from your own hard drive. The initial program simply draws a couple of dots on the screen and allows you to move them by clicking buttons. (On a proper computer you may find you can repeat the action of a button many times just by holding down the return key after clicking the button on the screen.) You can create new objects just by adding more of them with new names. The two objects I've provided for you up front are called i0 and i1 (and I chose the letter "i" because it stands for "item"). You can find them near the bottom of the HTML document in the BODY section, the first one being the <b id="i0" style="position:relative;left:0;top:0;font-size:60;color:yellow">.</b> (the name of this object is stated up front, the full stop near the end is the yellow dot that will actually appear on the screen, and all the stuff in between controls the appearance of the dot and its location on the screen). JavaScript is not designed for doing graphics, so it will struggle if you create too many such objects - it's best not to use more than a few dozen of them. (An image can be used as an object too, so if you have lots of items that don't need to move relative to each other, it's best to draw them in a drawing application such as Paint and then use that image - that's what I did for the MMX apparatus on my relativity page, and I then use simple code to move the image across the screen and to move a couple of dots to represent pulses of light which have to move relative to the apparatus.) [Note: I'm not using the word "object" in the programming sense, but simply mean an item that will appear on the screen.]

The HEAD part of the document contains the program code (while the BODY part contains text, and because our initial two objects are just big dots made out of punctuation they must be put in the BODY section rather than with the program code). Buttons are also put in this part of the document, and they'll be needed to control things.

Where you see // in the HEAD section, this prevents any code to the right on that line of code from being run, so this can be used to write comments into your code to help you understand it, but it can also be used to disable a line of code which you will want to use later but don't want to run yet. For example, the window.setInterval bit of code will run the function called "run" repeatedly so that we don't have to keep clicking a button to keep the action going, but I've disabled it for now as it currently has nothing to do. The functions "run" and "setup" are both empty, but we'll put stuff into them later.

The functions "move i0" and "move i1" simply add 1 to the horizontal positions of the dots. We'll write more useful code to control them later, but the immediate priority is to see if you can get this program to run on your computer so that we can find out whether this is going to be a viable way of working.

(Note that there is a complication with the numbers used for the horizontal positioning as the two dots are shown in different positions for the same x-axis number value, so we'll need to write code to correct that - each object's natural position is to appear to the right of the one listed before it in the document because we are using punctuation as our objects, and each character will naturally be printed to the right of the one before it, so an adjustment is required for each object to line it up correctly with our coordinate grid.)

Code: [Select]
<HTML>
<HEAD>
<TITLE>Theory Simulation</TITLE>

<script type="text/javascript">

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

function run()
{ }

function setup()
{ }

xi0=0; xi1=0; // Initial side-to-side locations of the dots

function movei0()
{ xi0=xi0+1; i0.style.left=xi0; xi0loc.innerHTML=xi0}

function movei1()
{ xi1=xi1+1; i1.style.left=xi1; xi1loc.innerHTML=xi1}

</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="i0" style="position:relative;left:0;top:0;font-size:60;color:yellow">.</b>
<b id="i1" style="position:relative;left:0;top:0;font-size:60;color:#0020ff">.</b>

</tt></center>

<p><a id="xi0loc"></a> &nbsp; <a id="xi1loc"></a>
<p>
<input type="button" value="Move Yellow" onclick="movei0()"/> <input type="button" value="Move Blue" onclick="movei1()"/>
<p>
If you want any text here to provide instructions for the user, you can replace this with your own text. It's always worth doing this because you might forget how your own program works if you come back to it after a long break.

</BODY>
</HTML>

Once we've established that you can get this code to run, we can start putting some maths into the program. It shouldn't be necessary to post the whole program every time - we will normally just post the additions which need to be pasted into it. I'll show you how to code mathematical functions next time.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 09/08/2017 15:50:10
Hi David,

Again, thanks for the formidable opportunity! :0)

I copied the java text and saved the file as simulation.htm, but when I opened it, it is the text that showed up, not the simulation, so I looked for a JavaScript tool on my browser, and I found one, so I copied the text in it, and when I tried to execute it, it showed this error:

/*
Exception: SyntaxError: expected expression, got '<'
@Scratchpad/3:10
*/
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 09/08/2017 16:37:41
I copied the java text

By the way, JavaScript and Java are completely unrelated programming languages.

Quote
...and saved the file as simulation.htm, but when I opened it, it is the text that showed up, not the simulation, so I looked for a JavaScript tool on my browser, and I found one, so I copied the text in it, and when I tried to execute it, it showed this error:

/*
Exception: SyntaxError: expected expression, got '<'
@Scratchpad/3:10
*/

I don't know what it thinks is an error, but I'd like to check it out. Which browser provides this particular JavaScript tool?

If you have a text editor like Notepad, you should find that it does the job though, and the browser should run it without finding any error.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 09/08/2017 17:28:50
I tried WordPad and OpenOffice and it didn't work, but I tried Notepad as you suggested and it worked. I can now move the two colored dots one pixel at a time.

The tool I found is a web development tool which is called Scratchpad on Firefox, and it's for Java Script. It's in the toolbox on the toolbar at the top.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 09/08/2017 19:58:22
That's good - use Notepad from now on. (I'll investigate the Scratchpad error later - I can't run Firefox on this old machine any more as it just freezes as soon as I start it up.)

I told you to save the file as simulation.htm, but you're going to be modifying the file repeatedly and it will doubtless stop working at some point because of errors that may be hard to find. When that happens, it will often be easiest to fix it by reverting to the previous version and making all the changes again. One simple way to do this is to start each session by saving the file as .html instead of .htm  (both of these mean the same thing, .htm simply being an older version of the same ending dating back to when there was a three-char limit on the part of a filename following the dot). You can then make changes to the content and save the new version as .htm, knowing that you have a backup stored as .html if anything goes wrong. You can then simply refresh the page on the browser where you still have the previous version open and it will replace it with the new one.

The most important things for you to learn now are how to add your own code, and although I'm going to help you with it, there will usually be long delays between replies, so you'll get things done a lot more quickly if you can do your own experimental coding. Creating variables is essential. Look at the line in the existing program that says:-

xi0=0; xi1=0; // Initial side-to-side locations of the dots

This line creates variables with the names xi0 and xi1 (the x coordinate for each of our objects), and it sets them both to the value zero. This then allows these variables to be used inside functions (and to be accessed from inside any functions) where their values can be changed. If you need to hold a value for anything, you should always make up a name for it and set it up as a variable in the same way. You can put your new variables after the two that are already there - just start new lines for them, separate them with semi-colons, and write comments after // to remind yourself what they are and what they're used for.

The other thing you'll need to do is write code to do maths inside functions. If you wanted to move an object across the screen along a circular path, for example, you could modify the code in:-

   function movei0()
   {   xi0=xi0+1; i0.style.left=xi0; xi0loc.innerHTML=xi0}

The maths is currently done by the first bit where the variable xi0 has 1 added to it. The rest of the line then uses the new value of xi0 to change the location of the object on the screen and then prints the new value of xi0 further down on the screen. To move the object in a circle, we would first need to create a new variable to hold the y coordinate for that object, which should be called yi0, we'd then add code into the function to change the value of yi0 using some maths (and write new code to make xi0 move appropriately too), we'd then have to add  i0.style.top=yi0; into the function to change the vertical position of the object on the screen using the new yi0 value, and then we might add yi0loc.innerHTML=yi0 into the function as well to post the number to the screen underneath, but if we do that last bit, we would also need to create a place for that number to appear on the screen by adding such a place to  the bit low down in the document that says <a id="xi0loc"></a> &nbsp; <a id="xi1loc"></a>  and we could do this by turning it into <a id="xi0loc"></a> &nbsp; <a id="yi0loc"></a> &nbsp; <a id="xi1loc"></a>

Because a row of spaces always turns into just one single space when displayed, you have to use "&nbsp;" to make a space that is retained, and that allows you to make bigger gaps between numbers printed to the screen.

For doing arithmetic, just copy from the following:-

To add to a variable, state the variable first, put "=" after it, then put the variable again, then put "+", then put either a number or another variable, and finish with a semicolon to separate this from whatever might follow.

xi0=xi0+x ;

To assign a new value to a variable, state the variable, then put "=", then put a number or variable after it, and finish with a semicolon.

xi0=1;

You can use more complex constructions to the right of the "=".

xi0=(x+1)*n;

Subtraction, multiplication and division are done the same way, but using the signs "-", "*" and "/"

xi0=xi0-x;
xi0=4*5;
xi0=xi0/2;

There are some shortcuts for simple modifications which are worth knowing too:-

x=x+1; can also be written as x+=1;
x=x*2; can also be written as x*=2;
x=x-n; can also be written as x-=n;
x=x/2; can also be written as x/=2;

Other maths is represented in more clumsy ways. Here are the trig ones (but be aware that they use radians - to convert degrees to radians or the reverse, multiply or divide by pi/180):-

n=Math.sin(a);
n=Math.asin(a);
n=Math.cos(a);
n=Math.acos(a);
n=Math.tan(a);
n=Math.atan(a);

For roots and powers:-

a=Math.pow(a,2); // squared
a=Math.pow(a,0.5); // square root

If you need pi, assign it to a variable and then use that variable from then on without ever changing it:-

pi=Math.PI;

Note: some names aren't allowed for variables, and if the program stops working for no obvious reason it may be because you've used a banned variable name.

Programming goes beyond the normal functionality of a calculator when you write code that tests for conditions and does different things in response. For example, you can write code to see if a variable is equal to a particular value and do one thing if it is and a different thing if it isn't. If you need to do that, you can get a long way using simple code like this:-

if(n==5) {n=0} else {n+=1};

This increases the value of n, but if n has reached 5, it resets it to 0. The double "=" is weird, but you just have to remember to use it. You can also use ">" or "<" (without doubling them), and you can use "!=" to mean "not equal to":-

if(n!=0) {n-=1};

This decreases the value of n unless it has already reached 0. The "else" clause is optional.

That gives you the basics of programming, but the hardest part of writing programs is actually working out what you're trying to do with what, and when you should be doing it. So the big challenge is working out how to break your theory down into manageable chunks that can be crunched. I'll post this now in case it enables you to get going with something, and then I'll spend some time taking a proper look at the first post in this thread to try to work out where best to start.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 10/08/2017 01:39:43
The first particle to be accelerated would resist to move because it would produce blueshift right away on the information coming from the second particle, and that second particle would only move after a while because it would take time for the information from the acceleration to reach it.

The first problem I see with this (ignoring the lack of any mechanism by which the first particle is accelerated) is how much it's going to move before it stops? How quickly will it accelerate and how quickly is that acceleration slowed as the perceived frequency of the signal from the second particle changes? As soon as particle A starts moving, the perceived frequency goes up, so does it stop instantly? This question then impacts on how the frequency of the signal from A to B will affect B, because if A stops straight away, it won't move any distance and B will detect no change.

Quote
Resistance to acceleration is mass, so accelerating the first particle and stopping the acceleration before that information hits the second particle should give us the mass of the whole system, which is weird since the second particle has not been affected by the acceleration yet. Stopping the acceleration of the first particle means that it should decelerate to rest after a while until it doesn't produce anymore blueshift, and I figure that it should decelerate by the time the second particle would be accelerating, which means that the information from that second acceleration should hit the first particle at the moment it would be at rest, which means that that first particle should start accelerating again, and that it would do so while the second particle would be decelerating.

I can't see how the acceleration and deceleration of A is going to measure the mass. I'm not convinced that you're doing anything involving mass after the initial acceleration of A, and that part of the process may happen in an instant right at the start. What happens after that appears to have more to do with how that energy is then shared with another particle bonded with the first. Anyway, if you double the amount of energy you're putting in, particle A is going to move further before it stops, and if you halve the energy you're putting in, it will stop sooner, so it looks as if you'll need to be able to vary how quickly particle A accelerates and decelerates under these different mechanisms (direct energy absorbtion with the initial move that kicks things off vs. acceleration control by perceived frequencies of each particle upon the other) depending on how much energy has been put into moving it. If it accelerates more quickly, it will perceive a stronger frequency change, so that may help decelerate it more quickly as the frequency goes higher, though as it decelerates it may then be slowed progressively more slowly until the frequency is back to the original value.

I don't know if we'll ever get to a working simulation, but, in the course of attempting to build one, this should force us to work out where maths is required and exactly what it has to do. I can already see that we need to establish details about the initial acceleration of particle A to spell out how instantaneous its change in speed is, and then we need rules about how it gets slowed down by its perceived frequency of B's signal, with that same rule controlling B's acceleration when it perceives a change in the frequency of the signal from A. We could program this in such a way that we can change the behaviour of these accelerations later just by changing values in control variables. That would be the safest way to do things if you aren't sure how quickly these accelerations should be handled.

Quote
A particle would then be accelerating while the other would be decelerating and vice-versa later on. Of course, we could accelerate the first particle for a longer time, but I need to know what will happen if we stop the acceleration at the moment the information from the acceleration hits the second particle.

That seems to be an arbitrary timing because A won't know when the wobble in his signal reaches B

Quote
That time shifted motion is hard to illustrate with static diagrams, and I think it would also be hard to put into equations, but I hope it can be simulated. What needs to be simulated is doppler effect from a particular motion that becomes a cause for another motion, so I think we would need that the particles are sources of waves, but I'm afraid that computers cannot produce them fast and precise enough, so I guess that we will have to rely on timing beeps, which computers cannot provide with absolute accuracy either, so the system will probably drift after a while, but I hope it won't drift too much, and that we can use a way to correct the drift if necessary.

It should be possible to calculate exact timings for things even if we're moving the action on in jumps for the visual display, but it may involve more complex maths to get those exact values. I can't supply the right maths for that, but I'm sure we can get reasonable results just by working with jumps of varying granularity with a fixed frequency value for each jump, and we can change that granularity to see how it affects the results - they should be inaccurate with large jumps and get better with smaller jumps until there's no point in going smaller. (What I mean by this is that when the change in a perceived frequency can be shown by a curve on a graph, we can carry out a round of calculations at regular time intervals and use whichever frequency the graph gives us at that time point, applying it uniformly for that whole slice of time). The visual display won't need to change for each round if we're doing more fine-grained calculations, so it can be updated every now and then at a fixed frequency while we vary the rate of the underlying calculations.

Quote
We want to see what will happen, so we need the particles to be as far as possible from one another on the screen...

We can worry about the visuals later. The first priority is to work out how to control the accelerations and decelerations.

Quote
To accelerate the first particle, we could move the left large bar a small distance, and double that distance each new beep.

I don't understand why you'd have repeated doublings.

Quote
Normally, to be more precise, we should account for what would happen inside the particle during its acceleration, thus for the motion of its components, represented by the left side and the right side of the vibrating large bar, but to simplify the problem, we might as well just use the constant timing between the left and the right side of the bar, and move the second side after the first one would have moved, thus reducing the distance between the small bars by doppler effect, but not the size of the particles, thus not the distance between the two sides of the large bars.

I'm confused now as to what's what. If A and B are both large bars representing two particles, are we now to have each of these particles made of two parts as well? If so, each one could be represented by two large bars, and we'd then need clear rules to control how those two bars move relative to each other.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 10/08/2017 20:04:14
The first particle to be accelerated would resist to move because it would produce blueshift right away on the information coming from the second particle, and that second particle would only move after a while because it would take time for the information from the acceleration to reach it.
The first problem I see with this (ignoring the lack of any mechanism by which the first particle is accelerated) is how much it's going to move before it stops? How quickly will it accelerate and how quickly is that acceleration slowed as the perceived frequency of the signal from the second particle changes? As soon as particle A starts moving, the perceived frequency goes up, so does it stop instantly? This question then impacts on how the frequency of the signal from A to B will affect B, because if A stops straight away, it won't move any distance and B will detect no change.
The first particle would be accelerated by another molecule, but I think we can simply give it an imaginary push. It moves against the doppler effect, so it has to be forced. Since it vibrates and it has to oppose the acceleration, we could state that it can only move freely when it vibrates away from the push, and that it is blocked by whatever stops it when it makes its step towards the push. If what pushes has time to move a bit when the particle vibrates away, then the acceleration is weak, and if it has time to move a lot, then the acceleration is strong. Once the vibration would have been shortened a bit by the push, the particle would still have to vibrate the same distance back and forth to keep its frequency constant, so it would be forced to travel a bit towards the other particle, what would shorten the beeps sent towards it.

If the push would stop after only one beep, then the speed of the molecule would depend on the strength of that short acceleration, and if it would stop after many beeps, then the speed of the molecule would also depend on the duration of that long acceleration. In the first case, we can see that the speed of the molecule would depend on the time the beep takes to make its roundtrip between the two particles. In the second case, we can see that the accelerated particle could already be pulled towards the other particle during the time it would be accelerated, because the other particle could have already moved away from it, what would have produced redshift on the beeps it has sent back to the accelerated particle, what would pull that already accelerated particle forward at each beep it makes. It means that what accelerates the particle has to follow it in its acceleration, and that we do not have to accelerate its motion to accelerate the particle, only to continue pushing, thus reducing temporarily the length of the vibration at the same rate. (I leave that here in case it would help to understand the model, but I changed my mind below about the way the particle could be simulated.)

Quote from: David
Quote
Resistance to acceleration is mass, so accelerating the first particle and stopping the acceleration before that information hits the second particle should give us the mass of the whole system, which is weird since the second particle has not been affected by the acceleration yet. Stopping the acceleration of the first particle means that it should decelerate to rest after a while until it doesn't produce anymore blueshift, and I figure that it should decelerate by the time the second particle would be accelerating, which means that the information from that second acceleration should hit the first particle at the moment it would be at rest, which means that that first particle should start accelerating again, and that it would do so while the second particle would be decelerating.
I can't see how the acceleration and deceleration of A is going to measure the mass. I'm not convinced that you're doing anything involving mass after the initial acceleration of A, and that part of the process may happen in an instant right at the start. What happens after that appears to have more to do with how that energy is then shared with another particle bonded with the first. Anyway, if you double the amount of energy you're putting in, particle A is going to move further before it stops, and if you halve the energy you're putting in, it will stop sooner, so it looks as if you'll need to be able to vary how quickly particle A accelerates and decelerates under these different mechanisms (direct energy absorption with the initial move that kicks things off vs. acceleration control by perceived frequencies of each particle upon the other) depending on how much energy has been put into moving it. If it accelerates more quickly, it will perceive a stronger frequency change, so that may help decelerate it more quickly as the frequency goes higher, though as it decelerates it may then be slowed progressively more slowly until the frequency is back to the original value.
My former message was about the acceleration process, so here is how I see the deceleration one. If the acceleration stops after only one beep for instance, the acceleration takes only one beep, so I think the deceleration must take one beep too. In other words, the acceleration would contract the particle a bit and the deceleration would stretch it back, and it would stay there at rest as long as the information from the motion of the other particle would be back. It means that if the acceleration lasts two beeps, the particle would automatically contract twice the distance, and it would thus take two beeps to stretch it back.

That's too hard to imagine, and I think the only way out would be to account for the way the components of each particle would progress, which is too complicated for a baby simulation, so maybe we should rely on doppler effect produced by a point source instead, or a point bar in the case we use bars to represent the sources. This way, the large bar representing the particle would move a bit during acceleration, and it would move during the time it is producing a beep, what would immediately produce blueshift on the incoming and leaving waves, what would thus desynchronize the two particles. I would be fine if we could have the possibility to move it during only one beep or during many beeps, or to move it a bit or a lot during a beep. I still think that the distance it would accelerate during a beep should equal the distance it decelerates during a beep, but for a point source, we might simply consider that the deceleration happens within the beep. In fact, those steps would be quantized the same way light is: they would start at the beginning of a beep and stop at the end.

Quote
I don't know if we'll ever get to a working simulation, but, in the course of attempting to build one, this should force us to work out where maths is required and exactly what it has to do. I can already see that we need to establish details about the initial acceleration of particle A to spell out how instantaneous its change in speed is, and then we need rules about how it gets slowed down by its perceived frequency of B's signal, with that same rule controlling B's acceleration when it perceives a change in the frequency of the signal from A. We could program this in such a way that we can change the behaviour of these accelerations later just by changing values in control variables. That would be the safest way to do things if you aren't sure how quickly these accelerations should be handled.
I think the point source particle will help us handle that kind of problem.

Quote from: David
Quote
A particle would then be accelerating while the other would be decelerating and vice-versa later on. Of course, we could accelerate the first particle for a longer time, but I need to know what will happen if we stop the acceleration at the moment the information from the acceleration hits the second particle.
That seems to be an arbitrary timing because A won't know when the wobble in his signal reaches B
That would be a problem if we needed that the waves move at the speed of light, but I think we can use lower speeds for the waves and still get the behavior we are looking for as long as the speed of the particles depend on the speed of the waves they exchange. So this way, if we needed to account for the distance between the sources for a particular analysis as in my example, we could since the computer would be a lot faster than the waves.

Quote from: David
Quote
That time shifted motion is hard to illustrate with static diagrams, and I think it would also be hard to put into equations, but I hope it can be simulated. What needs to be simulated is doppler effect from a particular motion that becomes a cause for another motion, so I think we would need that the particles are sources of waves, but I'm afraid that computers cannot produce them fast and precise enough, so I guess that we will have to rely on timing beeps, which computers cannot provide with absolute accuracy either, so the system will probably drift after a while, but I hope it won't drift too much, and that we can use a way to correct the drift if necessary.
It should be possible to calculate exact timings for things even if we're moving the action on in jumps for the visual display, but it may involve more complex maths to get those exact values. I can't supply the right maths for that, but I'm sure we can get reasonable results just by working with jumps of varying granularity with a fixed frequency value for each jump, and we can change that granularity to see how it affects the results - they should be inaccurate with large jumps and get better with smaller jumps until there's no point in going smaller. (What I mean by this is that when the change in a perceived frequency can be shown by a curve on a graph, we can carry out a round of calculations at regular time intervals and use whichever frequency the graph gives us at that time point, applying it uniformly for that whole slice of time). The visual display won't need to change for each round if we're doing more fine-grained calculations, so it can be updated every now and then at a fixed frequency while we vary the rate of the underlying calculations.
OK.

Quote
Quote
To accelerate the first particle, we could move the left large bar a small distance, and double that distance each new beep.
I don't understand why you'd have repeated doublings.
If the particle travels a certain distance in one beep and then stops, its speed is the distance over a beep, and if the speed has to increase, then more distance has to be traveled next beep, and if the acceleration is constant, then the rate at which the speed increases has to stay constant, so you're right, during acceleration, the distance traveled during each beep must follow an acceleration curve.

Quote from: David
Quote
Normally, to be more precise, we should account for what would happen inside the particle during its acceleration, thus for the motion of its components, represented by the left side and the right side of the vibrating large bar, but to simplify the problem, we might as well just use the constant timing between the left and the right side of the bar, and move the second side after the first one would have moved, thus reducing the distance between the small bars by doppler effect, but not the size of the particles, thus not the distance between the two sides of the large bars.
I'm confused now as to what's what. If A and B are both large bars representing two particles, are we now to have each of these particles made of two parts as well? If so, each one could be represented by two large bars, and we'd then need clear rules to control how those two bars move relative to each other.
That's what my model is about, but as I said, it looks a lot easier to start with a point source particle.

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 10/08/2017 22:16:35
I think we should use realistic numbers, so the speed of light will be the one used for the signals. We don't have to work in seconds though - we're dealing with very small things very close together and moving tiny distances which we will show greatly enlarged and slowed on the screen. So, how far apart are the particles going to be? Perhaps 200 picometres (a fifth of a nanometre) would be a reasonable starting point if these particles are bonded atoms.

What kind of speed are we going to accelerate the first particle to? (The display can track the particles so that they always stay on the screen, so that shouldn't limit your choice.)

What frequency is the light that you're using for the signals? The "beeps" should represent the crests or troughs of waves in the light signal, so 1x10^15Hz might be a reasonable value, which is 1 per femtosecond. (Milli, micro, nano, pico, femto, atto, zepto.) In the program we might use the variable t for time with t representing one zeptosecond, and d for distance with d representing one femtometre. (Light moves about a third of a picometre in one zeptosecond.)

Do these sound like reasonable units and sizes? Check them to make sure by doing your own research if you aren't sure - I may have made big errors as this kind of stuff goes way outside my experience.

(Edit: changed 1 per attosecond to 1 per femtosecond in the bit about light frequency).
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 10/08/2017 23:24:41
I think we should use realistic numbers, so the speed of light will be the one used for the signals. We don't have to work in seconds though - we're dealing with very small things very close together and moving tiny distances which we will show greatly enlarged and slowed on the screen. So, how far apart are the particles going to be? Perhaps 200 picometres (a fifth of a nanometre) would be a reasonable starting point if these particles are bonded atoms.
Sounds good!

Quote
What kind of speed are we going to accelerate the first particle to? (The display can track the particles so that they always stay on the screen, so that shouldn't limit your choice.)
How about 1nm/s to begin with?

Quote
What frequency is the light that you're using for the signals? The "beeps" should represent the crests or troughs of waves in the light signal, so 1x10^15Hz might be a reasonable value, which is 1 per attosecond. (Milli, micro, nano, pico, femto, atto, zepto.) In the program we might use the variable t for time with t representing one zeptosecond, and d for distance with d representing one femtometre. (Light moves about a third of a picometre in one zeptosecond.)

Do these sound like reasonable units and sizes? Check them to make sure by doing your own research if you aren't sure - I may have made big errors as this kind of stuff goes way outside my experience.
They sound good too, but I didn't go that far in my analysis yet, so I guess we will both have to get used to them. While reading about JavaScript, I realize that it is commonly used with HTML, a language that I had already used about 20 years ago to build my own web pages, so it should help.

Title: Re: How can I write a computer simulation to test my theory
Post by: chris on 10/08/2017 23:28:58
Just so you all know, I implemented a "code" bbc button above the posting box so you can insert lines of code into the forum and it will format correctly.

It's the square button with a hash (#) symbol.

You wrap it around your lines i.e. highlight the text and then click the code button - and it will format for you.

e.g.

Code: [Select]
<?php
echo "Print this comment";
?>
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 11/08/2017 00:51:13
How about 1nm/s to begin with?

That sounds a bit low - the gas molecules around us bounce off each other at over a thousand miles an hour, and if we're working with zeptoseconds, it might take millions of years for the simulation to move a particle across the screen. A speed in m/s is the same value in nm/ns, so 500nm/ns ought to be a realistic speed to use.

Quote
They sound good too, but I didn't go that far in my analysis yet, so I guess we will both have to get used to them.

Again, this is why everyone with a theory should try to simulate it, because it forces them to put proper numbers to the things their theory is going to operate on.

Quote
While reading about JavaScript, I realize that it is commonly used with HTML, a language that I had already used about 20 years ago to build my own web pages, so it should help.

We're not going to use a lot of complex HTML or JavaScript - we're really just using it as a calculator with a few extra bells and whistles to repeat the same calculations millions of times and to display the results in a way that makes it practical to understand them. If anything that I haven't already covered is needed, I'll provide it. The important thing is to work out what maths is needed and to put it into a form that can be run as program code. We can add these three variables into our program along with some information to help us understand what they are:-

Code: [Select]
t=0; // time in zeptoseconds (milli, micro, nano, pico, femto, atto, zepto)
d=200; // distance in picometres
f=1000; // initial bonding-light frequency per zeptosecond

We can change the units later if necessary - we might prefer to work with a distance unit equal to a tenth or hundredth of a picometre, for example, but we'll only find that out once we've got something up and running. I think we can make the initial acceleration of A instant, so the first bit of maths programming we need to write is going to be to handle the deceleration as A interacts with the signal from B, and that code needs to be adjustable so that we can change the deceleration rate just by changing a value in a single control variable. I'm going to think about that tomorrow. You might like to think about it too, and then we can compare notes and try to turn it into functional code.

________________________________________________________________


Just so you all know, I implemented a "code" bbc button above the posting box so you can insert lines of code into the forum and it will format correctly.

Thanks for making that available - I wasn't sure if it was there by default and hoped you wouldn't mind program code being posted here. It would be wise though to get the mods to keep a careful eye on how it's being used though so that nothing appears that isn't fully documented to explain what it does. No one should be allowed to post any code that obfuscates what it does.
Title: Re: How can I write a computer simulation to test my theory
Post by: mrsmith2211 on 11/08/2017 02:49:41
I am having trouble understanding you original premise. Sure a program could be writen for anything but if the basic brick is faulty so will everything that follows be faulty.

"I figure that mass and motion could be due to the bonding between two particles being limited to c" And you go on, is this a gravitational bonding, electrical or magnetic bonding?
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 11/08/2017 14:32:28
Hi Mrsmith,

The model I want to simulate is described here (https://www.thenakedscientists.com/forum/index.php?topic=53171.0). The bond in question is the one that permits atoms to form molecules, or that permits nucleons to form nucleus. If the information takes time between two atoms, then when the molecule is accelerated, both atoms should not move at the same time, what should produce doppler effect between them. What I suggest is that they can use that doppler effect for the same purpose we do, which is in this case as an information to control the timing of their bond. With doppler effect, the atoms would get out of sync when we accelerate them because one of them would be forced to move before the other for a while, and for the same reason, they would move by time shifted steps to stay on sync after having been accelerated. I think this mechanism explains the two opposed meanings of inertia, motion and resistance to move (mass), but it is hard to analyze with static diagrams, so I opted for a simulation, and David accepted to help me out with the software. As any new project, we will probably be facing new technical difficulties, but if inertia really depends on such a mechanism, we should be able to simulate it properly. You're welcome to participate if you wish! It's not a mainstream idea, but it doesn't contradict the facts either.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 11/08/2017 17:30:47
How about 1nm/s to begin with?
That sounds a bit low - the gas molecules around us bounce off each other at over a thousand miles an hour, and if we're working with zeptoseconds, it might take millions of years for the simulation to move a particle across the screen. A speed in m/s is the same value in nm/ns, so 500nm/ns ought to be a realistic speed to use.
I made a mistake, I meant 1 m/s, so 500 is OK, it's in the same order of magnitude.

Quote
I think we can make the initial acceleration of A instant, so the first bit of maths programming we need to write is going to be to handle the deceleration as A interacts with the signal from B, and that code needs to be adjustable so that we can change the deceleration rate just by changing a value in a single control variable. I'm going to think about that tomorrow. You might like to think about it too, and then we can compare notes and try to turn it into functional code.
When I switched to point sources, I wanted to eliminate the proper acceleration and deceleration phases of each particle and replace them by constant frequency steps, one beep one step, the bar disappearing and reappearing further away if there is motion, and beeping at the same place if there is no motion. I thought there could be a stop and go button for us to push on the particle, and another one for inserting the rate of the acceleration we want to give. Pushing on the particle would of course automatically put it out of sync with the incoming light, so that synchronizing part of the software would have to be skipped during that time, but as soon as we would stop pushing, the particle should progressively synchronize its steps with that incoming light, one step at a time, and at the same rate it had accelerated. It means that it would decelerate a bit for a while since it would always be producing blueshift on the incoming light whatever the duration of the acceleration, and that it would accelerate again once the light from the full acceleration of the other particle would come in, what should produce the same kind of steps between the particles than their proper ones, but at a much lower frequency. From the particles' viewpoint, their proper steps would then be synchronized with the incoming light, but from ours, the steps between the two particles would not happen at the same time.

The way the second particle should react to the increasing doppler effect is the same as the way the first one had reacted to it's acceleration: it should accelerate at the same rate step by step, and decelerate to rest if the first particle had the time to do so.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 11/08/2017 18:08:59
I am having trouble understanding you original premise. Sure a program could be writen for anything but if the basic brick is faulty so will everything that follows be faulty.

Most of the new theories presented here suffer from fatal faults which are hard to point to because they're not presented in sufficient detail (and the same applies to some old established theories which can't be simulated without breaking the rules of the model, thereby revealing that they are not sound). In writing a program to run the model, it forces the theorist to supply or create all the missing pieces if they can. In this particular case we're about to hit a major problem that the speed of movement of the particles is so slow in relation to the speed of light that the Doppler shift probably isn't going to register - an idea that superficially looks as if it could have some connection to reality when looking at particles moving at relativistic speed may not look so viable when the particles are moving at ordinary speeds, and that will soon show up clearly. However, Le Rapteaux will doubtless still want to explore other possibilities which this software can be turned to (because he really wants particles to sit on the nodes of standing waves), so it's well worth continuing with, and the most important thing is to provide him with the tools that will enable him to continue with that without relying heavily on outside help, so that means learning to use JavaScript as an advanced calculator that can run little simulations to test key ideas.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 11/08/2017 23:07:46
By the way, I changed 1 "beep" per attosecond to 1 per femtosecond in the bit about light frequency a few posts ago. It's easy to make big errors when you aren't used to working with things on this scale, so much so, that I may have changed a correct value to a wrong one, and that means you should check my figures by working them out independently.

The big problem with this simulation is the massive difference in speed between light and the speed of the particles. To show the signals moving across the screen at a reasonable speed such that you can see what they're doing, it may be impossible to see any movement of the particles within any reasonable length of time. It also seems to me that it will be impossible for the particles to detect any change in the frequency of cycles in the signal (the beeps), so they won't know how to react to receiving them unless you give them a clock, and that clock would have to cycle at a similar rate to the light signal. Even then, in order to show the particle moving at all, we might need to enlarge it considerably, shifting the other particle a long way off the screen. Let's just work out exactly what we're up against.

Suppose we put our particles 20cm apart on the screen, that would make 1mm of the screen represent one picometre (if the particle separation is 200 picometres). A bar representing the signal moving at c would take about 600 zeptoseconds to cross the space between them. If we were to use a granularity of 3 zeptoseconds for each new displayed frame, we'd see the bar move across the screen in 200 jumps of 1mm each, taking 8 seconds to do so if we update the display with a new snapshot of the action 25 times per second. A particle moving at 500m/s is moving at 500zm/zs, so every 3zs it will move 1.5am. For the particle to move 1mm (representing one picometre) across the screen we would have to wait seven and a half hours.

(Milli, micro, nano, pico, femto, atto, zepto.)

The frequency of the light I chose (near to the most energetic end of the visible spectrum) is 1 cycle per femtosecond, so with a granularity of 3zs for each displayed frame, the will give us one "beep" every 33,333 frames, and each will keep us waiting 22 minutes. These "beeps" are virtually impossible to perceive as bars going past for the particle - it's more like a ribbon going past them and gradually varying slightly in width.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 12/08/2017 14:02:41
How about simulating two cars exchanging sound waves then? We could build the software using that order of magnitude and add buttons to change the speed of the wave or the length of the steps later. What I want to study first is the way doppler effect from motion can become a cause for the same motion, and that principle should not depend on the kind of waves. If the software works for sound, then we could try to simulate real particles with it. In my example with sound, I usually put the cars one sound second away from one another, but to have the time to examine the motion, I think five seconds would be better. I never gave a frequency to sound, so how about 1 kilohertz to begin with? 5,000 wavelengths between the two cars, that should be precise enough. We could use the speeds cars usually have, or even try to exceed the speed of sound with them to see how the software would react. I think that, as your simulation of MMx shows, the cars would take more and more time to accelerate whatever the rate of acceleration we choose, which is similar to mass increase in the case of particles.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 13/08/2017 00:33:05
How about simulating two cars exchanging sound waves then? We could build the software using that order of magnitude and add buttons to change the speed of the wave or the length of the steps later. What I want to study first is the way doppler effect from motion can become a cause for the same motion, and that principle should not depend on the kind of waves.

There's no harm in doing that first. I've added a bit to my previous post though which you might find interesting, though it doesn't help get around the problem of the Doppler shift being insignificant. The only way to get around that is to give the particles their own clock, but fortunately a particle usually is a clock with a mechanism running at light speed, meaning that it can likely detect subtle differences in the arrival times of signals, though probably only over many cycles with the effect of a tiny desynchronisation adding up to significant effects over time. That means we may still be able to do some kind of simulation of these particles with realistic numbers and see how the Doppler shift may relate to their behaviour. It may also affect the pattern of standing waves if there's an interaction between the signals put out by both particles.

Quote
If the software works for sound, then we could try to simulate real particles with it. In my example with sound, I usually put the cars one sound second away from one another, but to have the time to examine the motion, I think five seconds would be better. I never gave a frequency to sound, so how about 1 kilohertz to begin with? 5,000 wavelengths between the two cars, that should be precise enough. We could use the speeds cars usually have, or even try to exceed the speed of sound with them to see how the software would react. I think that, as your simulation of MMx shows, the cars would take more and more time to accelerate whatever the rate of acceleration we choose, which is similar to mass increase in the case of particles.

We could continue using particles - we can simply accelerate the first one to a much higher speed than 500m/s to get it up to a speed where Doppler shift shows up on the screen. If we were starting with a car accelerated in an instant to 70mph and working with sound to control its behaviour, that would be similar to using light and a particle accelerated to 30,000,000m/s. Again though, I don't think this will map well to reality as that kind of acceleration would break any bond. With that speed of travel, we can use a granularity of 12zs with the screen showing light cross between the particles in two seconds and particle A being nudged to a speed that would take it 20 seconds to cross to the other particle if it didn't get slowed by its interactions with the signal from B. That would allow you to explore all the same ideas while keeping particles more in mind.
Title: Re: How can I write a computer simulation to test my theory
Post by: 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. 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? You said previously: 

ęI think we can make the initial acceleration of A instant, so the first bit of maths programming we need to write is going to be to handle the deceleration as A interacts with the signal from B, and that code needs to be adjustable so that we can change the deceleration rate just by changing a value in a single control variable.Ľ

To me, a deceleration is like an acceleration, so both phases have to work the same. It would be too complicated to simulate, but the first particle has to be accelerated by an outside molecule, so that the doppler effect from the atoms of that molecule would interfere with the doppler effect produced by the accelerated atom on the light from the atom it is bonded to. For the first atom to move, the external doppler effect should thus be more important than the internal one. There may also be thresholds under which no motion from the first atom would be transferred to the other atom, as it is the case for the electronic quantum states. The first step the first atom would make should thus depend on the progressive approach of an external atom, but it is not necessary to simulate that atom, just the resulting acceleration, and that acceleration has to be executed step by step to produce the time shifted wave like motion I am expecting the two atoms to execute during constant motion.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 14/08/2017 00:45:10
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>
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 14/08/2017 16:51:22
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper 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>
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux 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

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 18/08/2017 02:25:29
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 19/08/2017 21:12:23
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.

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 20/08/2017 02:27:42
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>
Title: Re: How can I write a computer simulation to test my theory
Post by: 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.

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.
Title: Re: How can I write a computer simulation to test my theory
Post by: phyti on 21/08/2017 18:03:51
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: 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?
Title: Re: How can I write a computer simulation to test my theory
Post by: phyti on 21/08/2017 19:14:03
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux 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)
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 22/08/2017 00:48:57
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 22/08/2017 19:47:24
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.

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 23/08/2017 00:29:47
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux 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?
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 25/08/2017 02:54:06
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>
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux 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.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 27/08/2017 01:06:10
-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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 27/08/2017 23:07:07
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.

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 28/08/2017 02:35:10
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.

Quote
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.

Quote
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.

Quote
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>
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 28/08/2017 20:22:37
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.

Quote
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.


Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 29/08/2017 00:49:14
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.

Quote
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.

Quote
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.

Quote
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 29/08/2017 19:53:21
Quote
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.

Quote
(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.

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 29/08/2017 22:39:32
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 30/08/2017 18:50:23
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.

Quote
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 30/08/2017 23:41:45
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 (http://www.magicschoolbook.com/science/Lorentz.htm)]
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 31/08/2017 14:02:48
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 06/09/2017 00:14:38
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 07/09/2017 21:40:04
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>
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 09/09/2017 23:50:12
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 10/09/2017 22:59:23
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>
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 11/09/2017 00:49:09
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?
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 12/09/2017 03:37:18
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 20/10/2017 19:16:22
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>

Quote from: DAC
Quote from: Inchworm
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 21/10/2017 01:08:56
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.

Quote
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.]
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 21/10/2017 20:54:36
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.



Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 21/10/2017 23:55:25
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.

Quote
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?

Quote
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.
Title: Re: How can I write a computer simulation to test my theory
Post by: phyti on 23/10/2017 15:44:44
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 m0 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!
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 24/10/2017 15:56:30
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.

Quote
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.

Quote from: David
Quote
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. During the time the red shifted light from that second particle will hit 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.
 
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 24/12/2017 23:18:44
Hi everybody,

It took a while, but I finally succeeded to build a simulation that accounts for acceleration between two inline particles, and I also succeeded to apply it to four particles where the light they exchange also travels sideways to the motion. Here is the result:
Quantized constant acceleration (http://lumiere.shost.ca/Quantized constant acceleration/Quantized constant acceleration.html)
Acceleration with four particles (http://lumiere.shost.ca/Acceleration with four particles/Acceleration with four particles.html)

I will comment later on.

Merry Christmas everyone.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 30/12/2017 22:34:30
Back to normal, I drank too much again! :0)

Simulating how light moves between two moving bodies is a lot easier than trying to imagine it. No need for complicated calculations either, just to find a way to move things at the right speed and in the right direction on the screen. To simulate acceleration between two inline particles, I had to find the way the speed of the first particle could increase. Since light is quantized, I had already hypothesized that, at the particles' scale, the speed had to be executed by steps, but I didn't find a way to simulate its increase. At first, I thought that we could use doppler effect and apply it on the light traveling between two particles. This way, moving a first particle would only mean moving the other one after a while. But doppler effect at the particles' scale proved too difficult to simulate, so I began to use the way David Cooper found to bypass the problem: he gave an energy to the steps, transferred this energy to the photon produced at the same time by the particle during its step, and transferred this energy again to the other particle when the photon was hitting it.  Here is that original simulation again. (http://lumiere.shost.ca/Acceleration with two particles/Acceleration with two particles.html)

As we can see, if we increase the speed of the red particle many times in a row, that speed drastically decreases when the light from the other particle strikes it back. I don't like that behavior, so I looked for a restriction in the way speed would increase. Open the four particles' simulation again and have a look at the explanations that I added at the bottom of the page. Acceleration with four particles (http://lumiere.shost.ca/Acceleration with four particles/Acceleration with four particles.html)
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 31/12/2017 22:05:01
I started writing a four particle version of the program but haven't had time to get very far with it, but it doesn't look as if you need it now - your latest program shows that you're very capable, and you can take it in any direction you want to explore. I still plan to finish my program, but it may be a while before I'm able to get back to it, and I might switch away from JavaScript to use a more comfortable (and more powerful) programming environment with proper graphics capability - JavaScript always makes me feel ill and I really can't face using it again at the moment.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 17/04/2018 22:25:25
Hi everybody,

I'm actually trying to make a simulation to test the equivalence principle, and I fell on a an unexpected information about that principle on PF (https://www.physicsforums.com/threads/time-dilation-vs-the-equivalence-principle.944438/page-2#post-5976102). It seems that accelerating two clocks at g on the two ends of a spaceship is not the same as putting those two clocks at the same vertical distance from one another on earth. In his message, Janus says that the upper clock on earth suffers less than g whereas the front clock on the ship suffers the same g the rear one suffers. Data shows that he is right for the clock on earth, but if the front clock on the ship doesn't suffer the same contraction than the rear one, it should also suffer a different g. Unfortunately, the thread has been closed, so I can't discuss my point there. We don't need a simulation to understand that, due to the limited of light, the contraction of the rear clock will happen before the one of the front clock, but it's hard to imagine why its acceleration should go down, so my simulation should help.
Title: Re: How can I write a computer simulation to test my theory
Post by: Colin2B on 18/04/2018 03:06:04
I fell on a an unexpected information about that principle on PF (https://www.physicsforums.com/threads/time-dilation-vs-the-equivalence-principle.944438/page-2#post-5976102). It seems that accelerating two clocks at g on the two ends of a spaceship is not the same as putting those two clocks at the same vertical distance from one another on earth.
This really isnít unexpected, but very well known.
The gravitational field in Einsteinís equivalence analogy is a uniform field and not a planetary gravitational field.
If you think about it, the lines of force in the rocket/elevator are parallel whereas on a planet they slope inwards towards the bottom leading to tidal forces. This means that g does not vary with hight in the rocket, but does on a planet.
The good news is that in a small volume on the earthís surface you can consider the field to be uniform. For example, when dropping a ball off a tower we donít tend to consider the difference in g between the top and bottom.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 20/04/2018 20:59:03
Hi Collin,

I meant unexpected for me of course, not because I didn't know about it, but because I didn't think about it. The simulation I am about to make concerns two clocks at different heights in an accelerating spaceship, but I cannot consider that height as a small volume for the clocks on earth if I want to compare the two kinds of acceleration. If I would simulate a falling ball on earth for instance, g would have to increase while the ball is falling, so what I have to do is calculate g at that height on earth, and accelerate my spaceship at the same rate the ball would accelerate. Theoretically, the result should be the same as with GR, and that's what I also got in the beginning with my simulation of the twins paradox, but when I started to consider that the speed had to come from a previous acceleration, I realized that contraction necessarily had to happen at that moment, and that's what happened when I let the first particle move before the second one while it was accelerated.  (http://lumiere.shost.ca/Acceleration%20with%20two%20particles/Acceleration%20with%20two%20particles.html)

Letting the first particle contract the distance between the two particles at its own pace gave a lot more important contraction than SR, so important that time got contracted instead of getting dilated. I then applied the same reasoning to a simulation of the MM experiment, (http://lumiere.shost.ca/Acceleration%20with%20four%20particles/Acceleration%20with%20four%20particles.html) and I got a null result while letting the vertical arm contract at it's own rate too. In fact, there is always a speed at which a given contraction gives a null result, so if there is no logical flaw in my simulations, the SR case where the vertical arm doesn't have to contract is only one of them. For the same speed, the horizontal arm could very well be more or less contracted, and the vertical one could always contract (or stretch) to give a null result.

There is no way to observe length contraction anyway, it's only an ad hoc assumption, so it can be anything as long as the null result is respected, but what about time dilation? In the original experiment, time dilation was also an assumption since it came from the assumption that the vertical arm would not contract, but contrary to contraction, it was assumed that it could be observed. To me, the only way to observe it would be to make a twins paradox experiment with real clocks, which hasn't been done yet, but if my simulation is right, we might as well get time contraction instead of time dilation.

But time contraction contradicts the result of the muon experiment, which is like half a twins paradox experiment where the two clocks haven't been synchronized at the beginning. If I had to simulate it, I would put two light clocks at a certain distance from one another without having previously synchronized them, and accelerate one towards the other. I would know which clock has been accelerated so I would know which one to move on the screen. The same way, we know that the muon is moving simply because we know it had to be accelerated towards the earth to get its speed. If I let that muon contract the same way I do with my particles though, it will still be time contracted instead of being time dilated, which should exceed its lack of synchronization with the clock on earth since muons are a lot more precise clocks that atoms. I still think that contraction during acceleration is interesting though, and especially since it came from simulating a principle that explains motion and mass, so I will go on with my simulation of the equivalence principle in case it would be interesting too.

If you have time, you can use your knowledge of relativity to improve my simulation of contraction. Maybe there is a way for the steps to be restricted during acceleration for instance. As I say on my page, I already had to restrict the way the speed of the first particle had to increase for the simulation to be possible, and I chose a simple way, so there might be a more precise one.