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. Once the red shifted light from that second particle will have reached it, it will stop resisting to make its step, so it will have time to make a longer one, thus to increase its speed. That's quite different from the acceleration we observe at our scale, but it doesn't mean that we are on a wrong path.
 
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:
Acceleration with two particles (http://motionsimulations.com/Acceleration with two particles)
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://motionsimulations.com/Acceleration with two particles)

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://motionsimulations.com/Acceleration with two particles)

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.






Title: Re: How can I write a computer simulation to test my theory
Post by: Colin2B on 21/06/2018 13:26:44
Happy to have a look at your simulations, but I find the blue on black text hard to read on ipad.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 21/06/2018 13:49:38
Happy to see you here again. :0) I had the same feeling about the colors in the beginning, and then it faded out rapidly. It is nice for the simulations, but unusual for the text. Maybe I should put two different background colors, one for the text and one for the simulations. I'll see what I can do.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 22/06/2018 12:53:05
Hi Collin,

I changed the colors. Tell me if you can read the text more easily.
Title: Re: How can I write a computer simulation to test my theory
Post by: Colin2B on 27/06/2018 15:25:16
Yes much easier to read.
Looking at the twin link I notice you use a horizontal clock. This is similar to the train thought experiment and because the front mirror is moving away from the light and the rear wall towards you are getting an uneven duty cycle - like mark/space or tick/tock ratio) which is probably why most scenarios use a vertical clock.
Pity you had to adjust the timings, but fun thing to do.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 27/06/2018 17:03:16
Yes, it is fun, but more importantly, it permits us to observe more closely the way motion might be executed at the particles' scale. To simulate motion on the screen, we have to move the clock by discrete steps, and we have to move light this way too, so we always get offset collisions between light and mirrors whenever we start moving the clock, which doesn't happen for the clock at rest. David wants me to correct the imprecision by calculating back, but I keep thinking that nature wouldn't do that, and that it would instead let some information escape from the system and be used for another purpose than producing constant motion. Yes, I'm studying the way light may be used by particles to produce motion instead of particles only producing light for us. Here is a simulation  (http://motionsimulations.com/Acceleration%20with%20two%20particles)that shows two bonded particles exchanging light. To start the simulation, hit the "Accelerate red particle" button. Then look at the display showing the speed of each particle increasing each time the photon strikes them. It's relativity applied to particles: it takes time for the blue particle to accelerate because information can't travel faster than c, and it also takes time for the red particle to accelerate another time because it has to wait for the photon to be back. It's quantized acceleration where the two particles start to move by quantum steps once the red one starts to suffer a force.

Now hit the "Stop the acceleration" button and look at the speed display again. It doesn't increase anymore, but the photon is still traveling between the two particles and is still telling them what to do, reason why they are still moving. The particles emit a photon when they receive one, they simultaneously make a step forward, and that photon simply carries between them the doppler effect from their respective relative speeds. The system naturally contracts during acceleration because the blue particle always accelerates late, so I let it contract and added it to the display. At the rate it is contracting though, light takes less and less time to make its roundtrip, reason why we get time contraction instead of time dilation on the display. To check how those two effects would affect the Micholson/Morley experiment, I then made a simulation of it using four particles as an interferometer (http://lumiere.shost.ca/Acceleration%20with%20four%20particles/Acceleration%20with%20four%20particles.html) while letting things contract at their own rate, and as you can see, it also gives a null result. Surprising isn't it?
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 27/06/2018 19:36:23
David wants me to correct the imprecision by calculating back, but I keep thinking that nature wouldn't do that

Nature doesn't need to calculate back because collisions in nature are reacted to as soon as they happen rather than waiting for slow-witted programs to detect the collision first before the particles are allowed to react - nature doesn't allow such delays so the reactions are always immediate. That's why you should calculate back to work out the actual times of collisions instead of forcing them all to wait to take place on widely-spaced timer ticks - there's nothing natural about the way you're doing things.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 27/06/2018 22:47:10
Weird things happen at the quantum scale; we have to use probabilities because things do not always happen the same way. There is two ways to consider that precision problem: either things are absolutely precise and we can predict anything if we know everything, or things are not absolutely precise and we can't predict them with absolute precision even if we know everything. The second way means that chance exists, the first means that it doesn't exist. These two thinking are so far from one another that they are irreconcilable: once we've chosen our way, we can't change it. There is no possible compromise, it's either one, or the other, we can't stand in between. I see chance everywhere and you don't. You want chance to be erased from our life and I want to make a tool out of it. You want to control things and I want to set them free. Maybe reality is in between, but our mind is visibly not. People say they are agnostic because they can't chose a side, not because they can stand in between: there is simply no place in between. Either god exists and he knows everything since the beginning, either he doesn't exist and we are stuck with chance till the end of times. Religions tried to add a bit of chance in their concept and called it free will, but it doesn't pass the ramp: free will is only a way to keep the questioning sheep in the herd. They also pray their god for chance, but it doesn't pass the ramp either: if god knows everything and he is perfectly precise, he doesn't need to change them.

You need things to be perfectly precise for your AGI to work and I don't, and you can't let down your ideas just because I don't agree with you, and me neither. We're stuck on two parallel roads and there is no crossover. Go on building your AGI and we'll see what happens. I'll go on trying to simulate motion the way I think, and we'll see what happens too. Maybe we'll find a way to reconcile our ideas later on. Meanwhile, thanks to you, we are two to fight that bunch of miscreant relativists. :0)
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 28/06/2018 19:32:24
Weird things happen at the quantum scale; we have to use probabilities because things do not always happen the same way. There is two ways to consider that precision problem: either things are absolutely precise and we can predict anything if we know everything, or things are not absolutely precise and we can't predict them with absolute precision even if we know everything. The second way means that chance exists, the first means that it doesn't exist.

The issue has nothing to do with probabilities of things on a quantum scale. The issue is entirely down to the program's clock ticks which you're requiring all collisions to coincide with, but collisions rarely coincide with the clock ticks of your program because they work to a much finer resolution (which some people think is infinite, but it's certainly so fine that we can't yet measure the length of the shortest tick of nature). To make a simulation accurately mirror reality, you have to go for as much precision as you can in calculating the times of collisions.

What you're doing is like looking at a race and insisting that all the runners cross the finish line on a multiple of a whole second while you run the collision detection routine at the end of each second, so in a 100m race you will determine that a few runners complete it in exactly ten seconds (and share the gold medal) while all the rest of the runners take exactly 11 seconds. If someone then complains that you're missing important detail because your timer isn't handling tenths or hundredths of seconds, your reply is that nature is imprecise and there's no point in calculating back from the collision detections (of the runners being at or beyond the finish line) because to represent reality you need to be imprecise.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 30/06/2018 18:36:36
It's not exactly what I have in mind. What I mean is that even if we divide the second in trillionth of a second, there will always be a certain imprecision. I succeeded to reduce the imprecision of my twins paradox's simulation by increasing the precision of the steps a bit, so I know that, if their precision was absolute, it would give the exact expected result: at the end, the moving clock would display exactly half the time the clock at rest displays, and it would stop exactly where it started. That observation is enough to show people that light doesn't have to travel at the same speed both ways for the moving twin to age less than the one at rest, what might convince some of them that LET is better at studying relativity. But I want more, I want to study motion at the particles' scale, and for that, I need to discover as precisely as possible how a photon strikes a particle. A photon has a certain dimension, and a step too, and they have to coincide otherwise some energy will be lost. The way my simulation on acceleration (http://motionsimulation.com/Acceleration%20with%20two%20particles) is actually built, it is not the photon that has a dimension but the steps it makes to execute its motion. Those steps are one unit long, and a particle's step is a fraction of that length, but the distance between the particles is 200 units, so in the beginning, the photon travels 200 units before striking a particle, and the particle travel 200 fractions of units during that time, which are of course theoretically executed by its components' steps.

Ideally, the photon should have a dimension, a beginning and an end, and its energy should follow a sinusoidal curve, which would then force the particle to produce a sinusoidal step made from smaller steps of changing lengths, which would emit a sinusoidal photon, and so on. That photon should fill the space between the particles so that its front end strikes a particle at the moment its middle leaves the other one, and vice-versa the other way around. Half of a photon would then be traveling right while another half would be traveling left. It's easy to imagine the synchronicity between the particles' steps and the photon when no motion is involved, but it is less easy to imagine the steps producing the sinusoidal photon and the photon producing the sinusoidal steps in return. However, we can approximate it using your simulation with ten photons (http://motionsimulations.com/Acceleration%20with%20ten%20photons): we just have to nudge the red particle five times to the right before the first blue bar hits the yellow particle, wait for that first bar to hit the yellow particle, and nudge the red one again five times to the left each time one of the five blue bars hits the yellow particle. We can then see the red particle's speed getting up to .05 while the yellow one is getting down to 0 and vice versa (By the way, do you know why the speed gets down to -3.469446951953614e-18 instead of 0?). That simulation could be improved to make the steps sinusoidal, and the photon would also get sinusoidal.

A natural phenomenon shows up in that simulation without us even having to program it: doppler effect. The distance between the bars inevitably shortens a bit when the red particle moves in the direction of the bars it emits, and it stretches back when the yellow particle moves in the opposite direction of the bars it emits, thus showing that doppler effect is not relative to the other particle, but to space or ether, or even to light since it is with regard to ether or space that light travels. My simulations show very clearly that bodies do not move with regard to other bodies, but with regard to ether, another reason for the SR guys not to use simulations to teach relativity or to study it. It is with regard to the light from the other particle that my particles move, not with regard to the other particle, otherwise they would both move at the same time when one of them is accelerated and they don't.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 30/06/2018 21:33:09
The way my simulation on acceleration (http://lumiere.shost.ca/Acceleration%20with%20two%20particles/Acceleration%20with%20two%20particles.html) is actually built, it is not the photon that has a dimension but the steps it makes to execute its motion.

In the text on that simulation you suggest that you're trying to account for length contraction, but the amount of contraction you're getting is wrong, and we also know where length contraction comes from in any case (relativistic mass reduces acceleration and automatically imposes contraction), so if you want a simulation to reproduce it, you need to program it to produce it properly, and that means varying the amount of acceleration delivered depending on the initial speed of the thing being accelerated. Look up the rules of relativistic velocity addition and use that as a guide.

Quote
(By the way, do you know why the speed gets down to -3.469446951953614e-18 instead of 0?)

I couldn't get it to produce that value, but it's so close to 0 that it may be a tiny error produced by the accuracy limits of the FPU (floating-point unit [maths co-processor]).
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 01/07/2018 15:02:06
we also know where length contraction comes from in any case (relativistic mass increase reduces acceleration and automatically imposes contraction)
As you know, contrary to you, I explain mass increase with light taking more and more time to reach the particles because the middle of their sinusoidal step is approaching c. With the steps, it is light that moves the particles, so whenever they would reach c, light would not reach them anymore, and they would stop accelerating. But your comment about relativistic mass increase seems nevertheless pertinent: if I let the distance between the components contract the same way I let the distance between the particles contract, the steps made by the particles will also contract, which should slow down their contraction and their acceleration a bit. I had already begun making a simulation of two inline light clocks located at the two ends of an accelerating spaceship to study the equivalence principle, and I was lacking stimulation to finish it. Thanks to you, I now have two reasons to do so!

Quote
I couldn't get it to produce that value, but it's so close to 0 that it may be a tiny error produced by the accuracy limits of the FPU (floating-point unit [maths co-processor]).
I was about to correct the error with code, because it complicates the reading of the display, is there a better way?
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 01/07/2018 21:49:29
if I let the distance between the components contract the same way I let the distance between the particles contract, the steps made by the particles will also contract, which should slow down their contraction and their acceleration a bit.

One important thing is to adjust the amount of acceleration delivered depending on the current speed of the thing being accelerated (though I'm not sure how the numbers would need to be crunched when decelerating it). The other thing I'd want to do is give each object its own time so that its speed of movement can adjust its speed of functionality - matter may be continually sending signals out at a rate related to that speed of functionality in order to detect what other matter around it is up to, because if one lot of matter meets another that's travelled a long way to meet it, neither will accelerate unless they can detect and react to each other in some way, so you'll never have anything travel between them unless they're continually testing their surrounds.

Quote
I was about to correct the error with code, because it complicates the reading of the display, is there a better way?

If it's the kind of error that I think it is, the cure is to correct it with extra code. Each value could be compared with a rounded up or down version of the same value, then you'd subtract one from the other and look at the size of the bit that's left over - if it's a tiny value, the rounded up or down version of the number can be used as it's more likely to be the correct value. JavaScript has an instruction for rounding a number, but it would be worth googling to see if there's a more efficient way of rounding it to just a few significant digits to get rid of most of the unnecessary ones and remove clutter from the screen.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 02/07/2018 16:10:07
One important thing is to adjust the amount of acceleration delivered depending on the current speed of the thing being accelerated (though I'm not sure how the numbers would need to be crunched when decelerating it).
Another important thing is to keep in mind that whatever we do for contraction to coincide with SR's ad hoc assumption, if particles (and components) really need to stay synchronized during motion, then as shows my simulation with four particles, the MM experiment would always give a null result whatever the contraction and whatever the time light takes to make its round-trip. If such a simulation had been available to Michelson, things might have turned out differently. If I would let the contraction happen during acceleration in the Twins Paradox simulation for instance, the traveling twin would age more than the one at rest instead of aging less, which means that there is always a possible in-between contraction rate where, for the same speed, the two Twins would age the same. For those who are skeptical, have a look at that one for a speed of .7027c and a contraction of .5 . (http://motionsimulations.com/Twins even)

Quote
The other thing I'd want to do is give each object its own time so that its speed of movement can adjust its speed of functionality - matter may be continually sending signals out at a rate related to that speed of functionality in order to detect what other matter around it is up to, because if one lot of matter meets another that's traveled a long way to meet it, neither will accelerate unless they can detect and react to each other in some way, so you'll never have anything travel between them unless they're continually testing their surrounds.
That's precisely what I want to observe while replacing the particles by two light clocks in my simulation on acceleration.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 02/07/2018 22:34:30
Another important thing is to keep in mind that whatever we do for contraction to coincide with SR's ad hoc assumption,

Which ad hoc assumption? It was an accusation made by Einstein aimed at LET, and yet length contraction is required to account for relativistic mass and the inability for anything to go faster than c - Einstein didn't realise that this was what drove the length contraction.

Quote
the MM experiment would always give a null result whatever the contraction and whatever the time light takes to make its round-trip.

Any other amount of length contraction would remove the null result.

Quote
If such a simulation had been available to Michelson, things might have turned out differently.

Michelson understood fine what was happening (after length contraction was proposed as an explanation), though none of them realised what drove the length contraction.

Quote
If I would let the contraction happen during acceleration in the Twins Paradox simulation for instance, the traveling twin would age more than the one at rest instead of aging less, which means that there is always a possible in-between contraction rate where, for the same speed, the two Twins would age the same.

If the contraction was different from the kind that actually applies, the absolute frame would be identified, and the speed of functionality could be faster or slower than it is for many objects, though it's also possible that the matter they're made of would become unstable due to the different functionality speeds for cycles aligned with the direction of movement of an object and aligned across that direction - we don't know how matter would behave in such a case as it never has to.

Quote
For those who are skeptical, have a look at that one for a speed of .7027c and a contraction of .5 . (http://scoundrels)

I'll have a look at that once you've fixed the link., but that's the wrong speed for that amount of length contraction.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 02/07/2018 22:41:09
If the contraction was different from the kind that actually applies,

Place the particles one particle length apart.  Then run the simulation.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 02/07/2018 23:30:15
If the contraction was different from the kind that actually applies,

Place the particles one particle length apart.  Then run the simulation.

How long is a point particle? It has no length. How long is a spread-out particle? It varies, depending on how much it's been length contracted.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 02/07/2018 23:33:19
If the contraction was different from the kind that actually applies,

Place the particles one particle length apart.  Then run the simulation.

How long is a point particle? It has no length. How long is a spread-out particle? It varies, depending on how much it's been length contracted.
For the existing simulation you could just use the dots the size they are, to notice the observable difference. Although not precise in size it would show us a difference.  There will be no angled light path. It will look like three photons adjoined travelling parallel with each other.

I drew you a picture of what I said


* lithclock.jpg (19.8 kB . 1146x766 - viewed 576 times)


Use 1 pixel spacing between particles , that should work.   It should create a wave if  you do it right .

Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 03/07/2018 15:00:49
I'll have a look at that once you've fixed the link., but that's the wrong speed for that amount of length contraction.
Link fixed. Either it's the wrong speed, or it's the wrong contraction, but the two clock nevertheless show the same time. I made that simulation after having realized that too much contraction produced time contraction instead of time dilation, so I knew there were combinations of speed and contraction for the two Twins to age the same.

If the contraction was different from the kind that actually applies, the absolute frame would be identified,
Not if the reason for contraction is the necessity for the particles to stay on sync. Take a look at my simulation with four particles again. (http://lumiere.shost.ca/Acceleration%20with%20four%20particles/Acceleration%20with%20four%20particles.html) I first let the horizontal distance contract at its own rate, then I simply let the vertical one contract so that the two photons keep arriving on sync at the top left red particle. This way, the two arms stay on sync all the time whatever the speed or the contraction rate.

Any other amount of length contraction would remove the null result.
Not if the particles would move so as to stay on sync.

Which ad hoc assumption? It was an accusation made by Einstein aimed at LET, and yet length contraction is required to account for relativistic mass and the inability for anything to go faster than c - Einstein didn't realize that this was what drove the length contraction.
Length contraction is the ad hoc assumption I was talking about, and it is still so because it can't be observed. I don't understand what you mean while saying that contraction is required to account for relativistic mass, so maybe I missed your explanation. Can you elaborate a bit please?
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 03/07/2018 15:14:22
If the contraction was different from the kind that actually applies,
Place the particles one particle length apart. Then run the simulation.
In this simulation on acceleration (http://motionsimulations.com/Acceleration%20with%20two%20particles), accelerate the red particle, wait till the particles get about one particle away from one another, then stop the acceleration.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 03/07/2018 15:19:35
If the contraction was different from the kind that actually applies,
Place the particles one particle length apart. Then run the simulation.
In this simulation on acceleration (http://lumiere.shost.ca/Acceleration%20with%20two%20particles/Acceleration%20with%20two%20particles.html), accelerate the red particle, wait till the particles get about one particle away from one another, then stop the acceleration.

Cool , well made.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 03/07/2018 16:58:05
Thanks! Did you understand why the distance between the particles was contracting?
Title: Re: How can I write a computer simulation to test my theory
Post by: phyti on 03/07/2018 17:32:20
Le Repteux;
Quote
There is no way to observe length contraction anyway, it's only an ad hoc assumption,
----
Stanford U. has an accelerator SLAC that has run experiments with electrons for years, and report length contraction indirectly from the increased electric field intensity. Lorentz developed a theory of deformable em fields and Heaviside developed a similar idea for magnetic fields, both in the 1880's, and before Relativity theory was published. It was another case of a phenomenon waiting for an application (like the computer chip).
---
Quote
At the rate it is contracting though, light takes less and less time to make its roundtrip, reason why we get time contraction instead of time dilation on the display.

That is a red flag, something is wrong. All clocks are moving, so the question is, which one  loses the most time.
Your length contraction is also wrong. For a speed of .20, it should be approx. (.98).
The expression is 1/gamma=sqrt(1-v^2).
-----
Quote
As you know, contrary to you, I explain mass increase with light taking more and more time to reach the particles
----
The idea of relativistic mass increase is now obsolete, since the explanation is time dilation. The successive application of a fixed amount of energy produces less acceleration since the closing speed decreases. If the object was a carbon atom with atomic # 6, the # of nucleons does not change, but the kinetic energy increases as  speed.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 03/07/2018 19:25:43
Hi Phyti, welcome in the simulator! :0)

Stanford U. has an accelerator SLAC that has run experiments with electrons for years, and report length contraction indirectly from the increased electric field intensity.
Indirect observation don't count as an observation. Dark matter is also an indirect observation, but it may still happen that the theory is wrong. When we are unable to observe an hypothetical phenomenon, we shouldn't take it for granted. We do have a direct observation for time dilation though, the muon experiment, but as my simulation of the Michelson-Morley experiment (http://lumiere.shost.ca/Acceleration%20with%20four%20particles/Acceleration%20with%20four%20particles.html) shows, if we let the particles on both arms move freely so that the two photons hit the top-left red particle on sync, no difference between the timings is observed.

That is a red flag, something is wrong. All clocks are moving, so the question is, which one  loses the most time.
Your length contraction is also wrong. For a speed of .20, it should be approx. (.98).
The expression is 1/gamma=sqrt(1-v^2).
Something is wrong only if we take SR for granted. If not, then a simulation is as good as any math to discover the truth, and better than math at showing how things could move. In case you didn't notice, in all my simulations with inline particles, it takes time for the information to travel between the particles, so if the system is accelerated, one of the particles always move before the other, which is precisely why the distance between the particles contracts. There is no need to program it, it is intrinsic to the limited speed of the information.

The idea of relativistic mass increase is now obsolete, since the explanation is time dilation. The successive application of a fixed amount of energy produces less acceleration since the closing speed decreases. If the object was a carbon atom with atomic # 6, the # of nucleons does not change, but the kinetic energy increases as speed.
That's the next simulation I am about to make. As I was telling David, I will take my simulation on acceleration (http://motionsimulations.com/Acceleration%20with%20two%20particles), and I will replace the two particles by two light clocks. Since it is a simulation, we'll be able to see what it changes.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 03/07/2018 21:52:28
Thanks! Did you understand why the distance between the particles was contracting?
Yes, one dot was accelerating where one was constant in velocity.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 03/07/2018 22:11:34
Not if the reason for contraction is the necessity for the particles to stay on sync.

There's only one viable contraction for any specific speed - any variation away from that will lead to MMX failing to give the null result that it always provides.

Quote
then I simply let the vertical one contract so that the two photons keep arriving on sync at the top left red particle. This way, the two arms stay on sync all the time whatever the speed or the contraction rate.

That maintains the null result, but the clocks then tick too quickly, so again you're not simulating the real universe.

Quote
I don't understand what you mean while saying that contraction is required to account for relativistic mass, so maybe I missed your explanation. Can you elaborate a bit please?

Think about a planet with a moon orbiting it in what appears to be a circular orbit, as observed by someone co-moving with this system. If the planet's actually moving through space at a speed just a fraction under the speed of light though, the moon's speed through space will vary, taking ages to overtake the planet in the forwards direction and much less time to be overtaken by the planet during the other half of the orbit - it cannot be allowed to overtake the planet at a speed higher than c, so how is this restricted? As the moon begins to go more in a forward direction (towards the direction the planet is moving in), its speed slows down relative to the planet at the same time as it moves faster through space. Where does the missing energy go? The moon's mass goes up - that's where relativistic mass comes in. And when the moon comes back round the other half of its orbit, the relativistic mass comes down again. This automatically leads to an elliptical orbit conforming with the rules of length contraction. The same will happen to an electron's "orbit", leading to length contracted atoms, and this in turn leads to atoms sitting closer together in their direction of travel.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 03/07/2018 22:23:44
so if the system is accelerated, one of the particles always move before the other, which is precisely why the distance between the particles contracts. There is no need to program it, it is intrinsic to the limited speed of the information.

It isn't sufficient to produce contraction - it needs to be the right amount of contraction. It also needs to be the same regardless of which particle you accelerate, meaning that if you accelerate one away from the other, you still need to produce contraction rather than extension. I think your approach will be incapable of producing correct length contraction because it isn't simulating the cause of length contraction. If you were to start with two co-moving bonded particles sitting the wrong distance apart, your simulation would also need to be able to correct their separation (or produce an oscillation which produces correct average separation).
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 03/07/2018 22:28:16
so if the system is accelerated, one of the particles always move before the other, which is precisely why the distance between the particles contracts. There is no need to program it, it is intrinsic to the limited speed of the information.

It isn't sufficient to produce contraction - it needs to be the right amount of contraction. It also needs to be the same regardless of which particle you accelerate, meaning that if you accelerate one away from the other, you still need to produce contraction rather than extension. I think your approach will be incapable of producing correct length contraction because it isn't simulating the cause of length contraction. If you were to start with two co-moving bonded particles sitting the wrong distance apart, your simulation would also need to be able to correct their separation (or produce an oscillation which produces correct average separation).
Sir you do realise that length contraction and expansion is just simply a distance change the light travels as opposed to anything mystical ?

In reality a timing dilation of synchronization.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 03/07/2018 22:34:53

* expansion.jpg (66.2 kB . 1146x766 - viewed 512 times)

Basic engineering , consider a cam and piston , compression and decompression.

The earths timing is ~0.288 mile/s  ~1000mph
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 03/07/2018 23:04:14
length contraction and expansion is just simply a distance change the light travels as opposed to anything mystical

It isn't - it's a physical reduction in length. If you rotate a disc, you can fit more material into the circumference than pi would normally allow you to. Imagine a circle with a hundred space ships parked around the perimeter, the front of each touching the back of the one ahead. Then have them all move past the circle at 0.866c in such a way that for a moment they are all in the same places they were parked in earlier. Their speed of travel has halved their length, so you can actually have 200 space ships move past the circle on tangents to it and all fit in the same space around it as the 100 ships did when parked there. It is not a synchronisation issue masking their length, but physical contraction reducing it, the result being that all the moving 200 can fit in the space of the stationary 100 without any overlap.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 03/07/2018 23:13:50
length contraction and expansion is just simply a distance change the light travels as opposed to anything mystical

It isn't - it's a physical reduction in length. If you rotate a disc, you can fit more material into the circumference than pi would normally allow you to. Imagine a circle with a hundred space ships parked around the perimeter, the front of each touching the back of the one ahead. Then have them all move past the circle at 0.866c in such a way that for a moment they are all in the same places they were parked in earlier. Their speed of travel has halved their length, so you can actually have 200 space ships move past the circle on tangents to it and all fit in the same space around it as the 100 ships did when parked there. It is not a synchronisation issue masking their length, but physical contraction reducing it, the result being that all the moving 200 can fit in the space of the stationary 100 without any overlap.
That is wrong sir, if we had a circular formation  and rotated it, the formation will expand because of the centrifuge, just like the Earths equator does?
I see the disk expands or contracts , not the objects.  The disk expanding making it appear the object contracts.

Added - Let me add a very important key factor why an object in motion does not and cannot physically contract in length . 

key point - The rear of the object would need to be travelling faster than the front of the object for a length contraction.

So in light of the new information, we should look at, where we are going wrong in our interpretation of length contraction. Are we to ignore basic physical facts for something mystical instead?



Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 04/07/2018 19:10:27
That is wrong sir, if we had a circular formation  and rotated it, the formation will expand because of the centrifuge, just like the Earths equator does?

Make a disc lightyears in diameter and rotate it. The centrifugal force can be so small that the edge will contract and try to crush inwards on the disc.

Quote
key point - The rear of the object would need to be travelling faster than the front of the object for a length contraction.

During the acceleration, that's exactly what happens.

Quote
So in light of the new information, we should look at, where we are going wrong in our interpretation of length contraction. Are we to ignore basic physical facts for something mystical instead?

There's nothing mystical about it. We can see particles have their life extended in particle accelerators due to the slowing of their functionality, and that life extension is exactly in accord with what it should be if there is length contraction. Without length contraction, they would live longer.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 04/07/2018 20:09:20
Make a disc lightyears in diameter and rotate it. The centrifugal force can be so small that the edge will contract and try to crush inwards on the disc.
That seems backwards David and contradictory, it can't have a centrifugal force and the edge inverting against  the direction of force?
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 04/07/2018 20:59:38
Make a disc lightyears in diameter and rotate it. The centrifugal force can be so small that the edge will contract and try to crush inwards on the disc.
That seems backwards David and contradictory, it can't have a centrifugal force and the edge inverting against  the direction of force?

Why not? The edge is moving, so it tries to contract. When a long rod tries to contract, it simply contracts and becomes shorter, but with a rotating disc the strongest contraction is round the circumference - if that shortens (or tries to shorten) it will squeeze in towards the centre, just like stretching a rubber band round a bottle.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 05/07/2018 08:06:41
Why not?

The reason is because the energy is being directed outwards as opposed to inwards. I see your reasoning but unless it is a vortex, I see no reason it can contract inverting, while the energy flows centrifugal in direction.  If anything the molecules are stretched of the disk ?

Consider a sphere in rotation , the y-axis contracts while the x-axis expands. 

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 05/07/2018 19:11:17
The reason is because the energy is being directed outwards as opposed to inwards. I see your reasoning but unless it is a vortex, I see no reason it can contract inverting, while the energy flows centrifugal in direction.  If anything the molecules are stretched of the disk ?

Consider a sphere in rotation , the y-axis contracts while the x-axis expands.

There are two forces involved - one trying to fling material outwards (technically it's merely a perceived force due to the material not being free to fly off in a straight line), and the other trying to crush inwards due to length contraction. Ordinarily the latter is too small to measure and the former is considerable, but if you make the disc really big, the length-contraction crushing inwards force could be stronger than the one trying to throw material outwards. The wider you make the disc, the less centrifugal force there is for the same speed of movement of the edge, so that force is tending towards zero as you go to bigger and bigger discs, whereas the length contraction of the edge is the same in all cases if the edge is moving at the same speed and doesn't diminish as we go to bigger discs.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 05/07/2018 19:17:12
The reason is because the energy is being directed outwards as opposed to inwards. I see your reasoning but unless it is a vortex, I see no reason it can contract inverting, while the energy flows centrifugal in direction.  If anything the molecules are stretched of the disk ?

Consider a sphere in rotation , the y-axis contracts while the x-axis expands.

There are two forces involved - one trying to fling material outwards (technically it's merely a perceived force due to the material not being free to fly off in a straight line), and the other trying to crush inwards due to length contraction. Ordinarily the latter is too small to measure and the former is considerable, but if you make the disc really big, the length-contraction crushing inwards force could be stronger than the one trying to throw material outwards. The wider you make the disc, the less centrifugal force there is for the same speed of movement of the edge, so that force is tending towards zero as you go to bigger and bigger discs, whereas the length contraction of the edge is the same in all cases if the edge is moving at the same speed and doesn't diminish as we go to bigger discs.
I sort of see what you are saying, as if a force spirals inwards?
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 05/07/2018 19:44:34
I sort of see what you are saying, as if a force spirals inwards?

Just picture a rubber band stretched round a bottle - in trying to shorten itself, it presses inwards. The length-contraction further in is less and less until it reaches zero at the centre, but none of the contraction is inwards - what you have going inwards is a crushing pressure which is resisted by the material further in, so that material pushes back and it's under a constant stress. With length contraction in a straight rod moving along end first, the contraction isn't resisted, so the length simply shortens and there is no stress on the material. Length contraction is only involved where the material sits closer together without stress (or tries to) - it is not about compression, but in the case of a rotating disc it produces compression, and the inability of the material to sit closer together leads to the material round the edge feeling stretched.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 05/07/2018 19:56:56
I sort of see what you are saying, as if a force spirals inwards?

Just picture a rubber band stretched round a bottle - in trying to shorten itself, it presses inwards. The length-contraction further in is less and less until it reaches zero at the centre, but none of the contraction is inwards - what you have going inwards is a crushing pressure which is resisted by the material further in, so that material pushes back and it's under a constant stress. With length contraction in a straight rod moving along end first, the contraction isn't resisted, so the length simply shortens and there is no stress on the material. Length contraction is only involved where the material sits closer together without stress (or tries to) - it is not about compression, but in the case of a rotating disc it produces compression, and the inability of the material to sit closer together leads to the material round the edge feeling stretched.
Ok, I can see a ''picture ''.
Title: Re: How can I write a computer simulation to test my theory
Post by: phyti on 06/07/2018 15:41:49
Something is wrong only if we take SR for granted. If not, then a simulation is as good as any math to discover the truth, and better than math at showing how things could move. In case you didn't notice, in all my simulations with inline particles, it takes time for the information to travel between the particles, so if the system is accelerated, one of the particles always move before the other, which is precisely why the distance between the particles contracts. There is no need to program it, it is intrinsic to the limited speed of the information.
All graphics on a computer are processed using math concepts.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 07/07/2018 14:10:52
If the planet's actually moving through space at a speed just a fraction under the speed of light though, the moon's speed through space will vary
Thanks for reiterating your description. I studied a similar orbital phenomenon about ten years ago before imagining my theory on mass: only the earth's center is going at the right speed on its orbit, one half of its surface is going too fast so that it should escape from the sun, and the other half is going too slow so that it should fall on it, what should also produce tides, but differently than by the book. As you can see, I was already trying to use motion to explain certain phenomenon. Now that I can use simulations, I tried to imagine what my two bonded inline particles would do at the place of your moon, and I found that they would react as if ether was suddenly accelerating or decelerating with regard to them. The photon would then take more and more time to make its round-trip for particles going upstream, and it would take less and less time for them going downstream. If I added a vertical arm to the system as in my simulation with four particles, and if I would let those particles move so that their photon stays on sync with the horizontal one, there would be no difference in the two timings, but the vertical arm would constantly be contracting and stretching while the horizontal one would not: it would be stretching when the horizontal photon would take more time, and contracting when it would take less time, which is not what my four particles do when they are accelerated, but it is similar to SR since its supporters pretend that only the horizontal arm would be contracted. Here is wiki about that: (https://en.wikipedia.org/wiki/Michelson%E2%80%93Morley_experiment#Length_contraction_and_Lorentz_transformation)
Quote from: Wiki
However, length contraction is only a special case of the more general relation, according to which the transverse length is larger than the longitudinal length by the ratio γ. This can be achieved in many ways.
...........
Poincaré (1905) demonstrated that only ϕ = 1 allows this transformation to form a group, so it is the only choice compatible with the principle of relativity, i.e. making the stationary aether undetectable. Given this, length contraction and time dilation obtain their exact relativistic values.
Ether is also undetectable in my simulation with four particles since it always gives a null result, and it still shows that those values can change, which means that it is still an ad hoc choice, and that math can't help.

This mind experiment of yours is about acceleration without a force, so let's study more closely how force develops between my accelerated particles. We know it is the photon that accelerates the second particle in my simulation on acceleration, so we can suspect it is also a photon that accelerates the first one, but it has to be an external one. To simulate such a force, I could make a simulation of two moving bonded particles hitting two others that would be at rest, and for external photons to show up between the two system, I could let the internal ones get away from the systems a bit, as if they would not completely be absorbed by the particles. This way, the two systems would interfere when they would get close enough from one another: the external photons would compete with the internal ones so as to keep the hitting particles at the right bonding distance, the distance between the particles and between the two systems would then contract a bit, so the particles would automatically resist to the change, which is precisely what force is about. After a while, the system at rest would begin moving away from the moving one, and the moving one would slow down a bit. That describes what is happening when particles get accelerated, and whatever the way they are accelerated since it is also some kind of light that is used in accelerators. Going through ether, your moon is also affected by light, but its intensity is a lot lower than the one the particles exchange. However, the intensity of the information that the moon and the earth exchange would be a lot higher if ever they would exchange any, so if that information could influence the steps between their particles, those steps might be able to explain their orbital motion.

That maintains the null result, but the clocks then tick too quickly, so again you're not simulating the real universe.
I'm simulating a physical mechanism whereas SR tenants don't even care to present any. When I tell them that contraction and dilation have to happen at acceleration, they stop listening since they need that acceleration doesn't affect the SR issue of the Twins mind experiment. The first time I ran my simulation on acceleration, I wasn't sure the distance was going to contract and it did. I know that it contracts too much, but I still think it's a good start. For the moment, I consider that the resistance we attribute to mass is caused by the time light takes between the particles, and that time is already part of the simulation as far as the particles are concerned, but not as far as the components are concerned, so I could introduce an equation to reduce the particles' acceleration progressively and pretend it is due to their components' mass, but I prefer to make a simulation of it and check if the contraction rate goes down significantly. If it does, then I will have a real mechanism to support an eventual equation. Such an equation would automatically affect both the time and the distance, dilating the contraction would automatically dilate the time, which is exactly what is needed to even SR numbers.

Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 07/07/2018 14:23:14
Ether is also undetectable
You could try two parallel copper plates a short distance apart with a positive current traversing through both plates in a vacuum. 

added - I drew it you


* doodle.png (39.82 kB . 3168x1772 - viewed 696 times)



Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 07/07/2018 14:33:25
What for? To show that ether is detectable? How?
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 07/07/2018 14:33:36
I improved it for you

 [ Invalid Attachment ]
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 07/07/2018 14:33:59
What for? To show that ether is detectable? How?
Observable if you get it right
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 07/07/2018 14:36:29
How?
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 07/07/2018 14:41:09
How?
Use a thermal detector or infra red or maybe even just a camera,  set the plates on a vice type structure so the ''jump'' gap can be altered.  Be careful though it might be dangerous lol.   Q.F.C Quantum field compression .


Added   ed87a7f75df442926fd8916deaeb9296.gif=Q
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 07/07/2018 14:53:08
I googled "Quantum field compression", and its all about data compression, nothing about detecting ether.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 07/07/2018 14:53:59
I googled "Quantum field compression", and its all about data compression, nothing about detecting ether.
I have not wrote the paper on the subject, it is new.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 07/07/2018 15:03:21
Then you need to explain what you mean, I can't figure it out.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 07/07/2018 16:06:07
Then you need to explain what you mean, I can't figure it out.
The parallel positives  will concave any positive in the ''sub'' space that exists between the plates whilst attracting any negative that exists in the ''sub'' space.   Compressing the positive energy to a central position between the plates.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 07/07/2018 18:43:43
and it still shows that those values can change, which means that it is still an ad hoc choice, and that math can't help.

The ticking rates of moving clocks show that the perpendicular arm of the MMX doesn't contract, and the arm aligned with the direction of travel must contract in accord with the two mathematical methods that we're using to calculate it. Anything that goes against that maths also goes against the results of experiments and therefore does not fit the real universe.

Quote
This mind experiment of yours is about acceleration without a force,

It involves a gravitational force (or a slowing of the speed of light in the presence of mass which can produce the same bending of courses as a curving of space).

Quote
When I tell them that contraction and dilation have to happen at acceleration, they stop listening since they need that acceleration doesn't affect the SR issue of the Twins mind experiment.

You hear different things from different people, but it's not surprising that many of them are confused because they're working with a magical model. Most say that the accelerations are important though - the twin who accelerates is normally the one who ages less. However, if you could accelerate the moving twin by applying a gravitational force such that he feels no acceleration while the stay-at-home twin feels acceleration instead by being tethered in position when the gravitational force is applied, it can be the twin who felt no acceleration who ages less.

Quote
The first time I ran my simulation on acceleration, I wasn't sure the distance was going to contract and it did. I know that it contracts too much, but I still think it's a good start.

It may not be a good start - it's more likely misleading you into thinking you've found something relevant. You have no mechanism for distinguishing between the behaviour of bonded particles and non-bonded ones. You don't have a mechanism for making two stationary bonded particles move from an incorrect separation to a correct one. With real bonded particles, there are forces of attraction and repulsion acting between them which fight each other and keep driving towards a compromise separation. Finding a chance contraction that doesn't match up to the real one is an indication that you have not found the right mechanism.

Quote
For the moment, I consider that the resistance we attribute to mass is caused by the time light takes between the particles,

How does that work if another pair of particles have twice the mass while light takes the same amount of time to travel between them? Mass is a measure of the amount of energy tied up in matter, which is no surprise as matter is made of energy - it can all be thought of as light. Light has directionality, and mass appears when light of different directionalities combines to form matter such that some of that directionality opposes the rest and creates resistance, reducing the speed of the knot of energy to less than c. With no resistance of this kind, all the energy goes in the same direction and you automatically have massless radiation instead of matter.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 09/07/2018 14:24:14
How does that work if another pair of particles have twice the mass while light takes the same amount of time to travel between them?
Good point! No need for more massive particles to explain the additivity of mass though. Two systems of two bonded particles resist twice as much as one system because twice as much particles resist to the change. Particles do wait for light to tell them to accelerate, but if there is two particles, we have to apply the force on both of them, so we have to apply twice the force. Resistance is easier to explain with doppler effect though: whenever we try to accelerate the first particle in my simulations on acceleration, it automatically produces blueshift on the light from the second one, and it is automatically forced to get back where it was, so an opposed force has to be applied on it to keep it there until the photon from the other particle is back with the information that it can stay there. If we stop applying the force though, it doesn't erase the redshift the second particle has imprinted on the photon it has already emitted backward to the first one, which is thus forced to move forward again when that light comes in, and so on for the second particle later on, which produces the constant motion that we can observe when we stop the acceleration.

Quote
Mass is a measure of the amount of energy tied up in matter, which is no surprise as matter is made of energy - it can all be thought of as light.
The relativists have no mechanism to explain mass since the Higgs' glue doesn't explain how particles can resist to acceleration and still move at constant speed during that time. I do have such a mechanism, and moreover, it explains that mass is due to c, so it is not far from explaining completely the mass-energy equivalence. I'll explain it again while trying to be more precise in my wording since it depends on a cascade of events which complicates the understanding. My two particles exchange light, and if we suddenly separate them for instance, the light that they were exchanging is no more absorbed by the particles so it escapes from the system. It is that same light that was previously justifying the loss of mass due to their bonding since it was precisely that light that was bonding them. We know that particles lose mass while bonding, so if we reverse the process, the closer they are, the more they are massive. In my theory, it is precisely the light that escapes from the steps between the closer components that produce the steps between the more distant particles, and that light is a lot weaker at the particles' scale than it was at the components' one because it has to travel a longer distance between the particles than between the components, so since it is no more available at the components' scale, and since the particles' resistance is automatically weaker than the components' one, the total resistance of the system gets down a bit.

You have no mechanism for distinguishing between the behaviour of bonded particles and non-bonded ones.
Yes I do. Non-bonded particles are made of bonded components that also execute small steps to stay on sync.

You don't have a mechanism for making two stationary bonded particles move from an incorrect separation to a correct one.
Yes I do. The light that particles exchange creates a standing wave between them, and they have to stay on the nodes of that standing wave, which is an integer number of wave length away from one another. If the medium is cool, they can stay farther without getting ionized by collisions, otherwise they must stay closer.

Finding a chance contraction that doesn't match up to the real one is an indication that you have not found the right mechanism.
As I said, dilation and contraction must happen at acceleration, and two bonded inline particles can certainly not accelerate at the same time, so at least between those particles, the system must contract the way it does. The fact that this kind of contraction does not produce the numbers expected by the experiments is irrelevant. We have the tool to find the truth behind the assumptions, so let's find it.

Most say that the accelerations are important though - the twin who accelerates is normally the one who ages less.
I keep repeating them that acceleration simply determines which twin is moving, and they can't agree because it directly contradicts the idea that motion is relative. If motion was always relative, the twins mind experiment would still contain a paradox.

Anything that goes against that maths also goes against the results of experiments and therefore does not fit the real universe.
A simulation simulates the real universe, so if it doesn't give the right numbers, we have to fin the bug, not discard it.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 09/07/2018 18:29:43
Then you need to explain what you mean, I can't figure it out.
The parallel positives  will concave any positive in the ''sub'' space that exists between the plates whilst attracting any negative that exists in the ''sub'' space.   Compressing the positive energy to a central position between the plates.
I still don't understand what you mean. Tell me first what you want to demonstrate.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 09/07/2018 18:49:57
Then you need to explain what you mean, I can't figure it out.
The parallel positives  will concave any positive in the ''sub'' space that exists between the plates whilst attracting any negative that exists in the ''sub'' space.   Compressing the positive energy to a central position between the plates.
I still don't understand what you mean. Tell me first what you want to demonstrate.

The experiment should demonstrate a binary spatial field exists between the two plates, showing negative energy exists, additionally  showing my N-field theory .

4a5e1be70bdbd1573dc3dce942130f9a.gif   = E^2


A sort of LIGO ...that hopefully will show ''space-time''

P.s Don't try this at home just in case .  :o
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 09/07/2018 22:00:01
My two particles exchange light, and if we suddenly separate them for instance, the light that they were exchanging is no more absorbed by the particles so it escapes from the system. It is that same light that was previously justifying the loss of mass due to their bonding since it was precisely that light that was bonding them.

I can't get that to add up. If that light is bonding them, but they only become bonded once that light has been lost, what is bonding them once they are actually bonded?

Quote
Non-bonded particles are made of bonded components that also execute small steps to stay on sync.

But what stops two non-bonded particles from being bonded particles when they get close together?

Quote
The light that particles exchange creates a standing wave between them, and they have to stay on the nodes of that standing wave, which is an integer number of wave length away from one another. If the medium is cool, they can stay farther without getting ionized by collisions, otherwise they must stay closer.

Is that in any of your simulations? For example, if you add a "spontaneous quantum leap" routine to move one of the particles to a different distance away from the other without changing it's speed through space, will it automatically move back over time to where it should be to restore the correct separation?

Quote
As I said, dilation and contraction must happen at acceleration, and two bonded inline particles can certainly not accelerate at the same time, so at least between those particles, the system must contract the way it does.

I can't remember where we got to, but do any of the simulations show a contraction when you move the leading particle away from the other or do they all produce length extension?

Quote
The fact that this kind of contraction does not produce the numbers expected by the experiments is irrelevant. We have the tool to find the truth behind the assumptions, so let's find it.

The failure to produce the right amount of contraction shows that the method is wrong - it isn't just a matter of debugging it. It's just a chance contraction. Correct contraction should result from a balance of forces.

Quote
I keep repeating them that acceleration simply determines which twin is moving, and they can't agree because it directly contradicts the idea that motion is relative. If motion was always relative, the twins mind experiment would still contain a paradox.

The accelerations reveal which twin moves more quickly through space on average than the other. Both may be moving.

Quote
A simulation simulates the real universe, so if it doesn't give the right numbers, we have to fin the bug, not discard it.

It isn't that simple. A simulation that creates rain by having a god urinate from a cloud may well water the flowers, but it is not a true simulation of the real universe.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 10/07/2018 10:52:28
Particles do wait for light to tell them to accelerate, but if there is two particles, we have to apply the force on both of them, so we have to apply twice the force.
Why apply force ?  Is it not best to let the particles do their own thing? 
Couplings will take a lot of time and energy to split, the information of the coupling is ''tight'' by entanglement, perhaps one particle always follows the lead particle by an unseen bond .  Imagine sending four particles at the same time, there is then no contraction to worry about, everything will be synchronized by the constant of light and the lead particle.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 10/07/2018 18:54:13
I can't get that to add up. If that light is bonding them, but they only become bonded once that light has been lost, what is bonding them once they are actually bonded?
The light that bonds the particles is the one that succeeded to escape from the bonding between the components. Light can only escape during acceleration, because it is then that the steps get out of sync a bit. Such an acceleration can be due to an external collision, but it is also due to the way the steps between the components are forced to justify the steps of the particle they are part of. The steps of the particles are sinusoidal, they are made of an acceleration followed by a deceleration, and the components' steps must follow that curve since a particle's step is  made of them. During one of the particle's step, its components' steps are thus forced to accelerate to a top speed and then decelerate to rest, so some light escapes from them, but that light isn't lost, it is used further away to accelerate the steps from the other particle's components, and vice-versa. That's what I want to simulate while replacing the particles by two light clocks in my simulation on acceleration, but your question made me realize that I can use your simulation with ten photons to simulate a sinusoidal wave. That's a tricky one, but talking about it evidently helps me to figure it out.

But what stops two non-bonded particles from being bonded particles when they get close together?
Speed, as with atoms in a plasma phase for instance.

Is that in any of your simulations? For example, if you add a "spontaneous quantum leap" routine to move one of the particles to a different distance away from the other without changing it's speed through space, will it automatically move back over time to where it should be to restore the correct separation?
We know that electrons spontaneously get back to a lower level of energy after having been bumped to a higher one, so if that spontaneity is due to quantum chance, then we can use it too for the steps. Notice that if a step suffers such a quantum leap, some light will automatically escape from it since it loses its synchronicity in the process.

I can't remember where we got to, but do any of the simulations show a contraction when you move the leading particle away from the other or do they all produce length extension?
There is only one way to pull two bonded particles away from one another: throw a third particle directly in between them at high speed. If it doesn't brake the bond between the particles, that kind of collision may produce a special kind of motion that we call a vibration, and with the steps as an explanation for motion, such a motion is inevitably made out of steps. Contrary to the steps that produce constant motion though, those steps are made in opposite directions, but as my simulation on acceleration shows, reversing the acceleration does not reverse the contraction, so they should also produce some, what should also affect the time light takes between the particles and between the components. Now, if the third particle hits at an angle at low speed, it could simply be deviated, and if it hits at high speed, it could simply brake the bond. What I mean is that if we can't imagine a way for the particles to pull one particle away without immediately affecting the other, then it may be because it is impossible for them to do so.

The failure to produce the right amount of contraction shows that the method is wrong - it isn't just a matter of debugging it. It's just a chance contraction. Correct contraction should result from a balance of forces.
The method can be wrong, but the logic can't. If we accelerate a firsts particle while its light takes some time to inform the second one that it has moved, then it will have the time to move towards that second one before it moves away, and it will also go on moving towards it during the time the light from that second one will be getting back. The way it moves towards that second one may be wrong though, and that's what I want to study while replacing my two particles by two light clocks. I gave the steps a mean constant speed during their acceleration whereas a step is always made of an acceleration followed by a deceleration, so I need to study that motion more closely. At the beginning, I thought that the particle would make only one step and then stop and wait for the photon to get back, but it didn't work so I let it travel during acceleration. What I could try now is permit the particle to execute its constant motion out of its precedent acceleration instead of its actual one, what should reduce the contraction a bit. I'll try that!

The accelerations reveal which twin moves more quickly through space on average than the other. Both may be moving.
Of course, but I always consider that the twin at rest is at rest with regard to space so that I'm not forced to use the reference frame principle interminable wording.

It isn't that simple. A simulation that creates rain by having a god urinate from a cloud may well water the flowers, but it is not a true simulation of the real universe.
A simulation is at least as good as math at representing the real universe, but as SR shows, the math doesn't need to be logical to give the right numbers, whereas a simulation has. We can't move things on a screen in a way that they can't use, but we can use bad logic to do so in words.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 10/07/2018 19:06:29
Particles do wait for light to tell them to accelerate, but if there is two particles, we have to apply the force on both of them, so we have to apply twice the force.
Why apply force ?  Is it not best to let the particles do their own thing? 
Couplings will take a lot of time and energy to split, the information of the coupling is ''tight'' by entanglement, perhaps one particle always follows the lead particle by an unseen bond .  Imagine sending four particles at the same time, there is then no contraction to worry about, everything will be synchronized by the constant of light and the lead particle.
Take a look at my doppler effect explanation hereafter and tell me if you understand something:
Quote
Resistance is easier to explain with doppler effect though: whenever we try to accelerate the first particle in my simulations on acceleration, it automatically produces blueshift on the light from the second one, and it is automatically forced to get back where it was, so an opposed force has to be applied on it to keep it there until the photon from the other particle is back with the information that it can stay there. If we stop applying the force though, it doesn't erase the redshift the second particle has imprinted on the photon it has already emitted backward to the first one, which is thus forced to move forward again when that light comes in, and so on for the second particle later on, which produces the constant motion that we can observe when we stop the acceleration.

Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 10/07/2018 19:40:12

Resistance is easier to explain with doppler effect though: whenever we try to accelerate the first particle in my simulations on acceleration, it automatically produces blueshift on the light from the second one, and it is automatically forced to get back where it was, so an opposed force has to be applied on it to keep it there until the photon from the other particle is back with the information that it can stay there. If we stop applying the force though, it doesn't erase the redshift the second particle has imprinted on the photon it has already emitted backward to the first one, which is thus forced to move forward again when that light comes in, and so on for the second particle later on, which produces the constant motion that we can observe when we stop the acceleration.

Could you elaborate more ?  I sort of understand





Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 10/07/2018 20:48:46
The light that bonds the particles is the one that succeeded to escape from the bonding between the components.

I can't follow the logic of that. If the light has escaped, it can have no further role in the bonding: it can't go on travelling to and fro between the particles to maintain the bond.

Quote
During one of the particle's step, its components' steps are thus forced to accelerate to a top speed and then decelerate to rest, so some light escapes from them, but that light isn't lost, it is used further away to accelerate the steps from the other particle's components, and vice-versa.

If it isn't actually lost, then it hasn't been released, so it isn't the energy released by the bond being formed.

Quote
But what stops two non-bonded particles from being bonded particles when they get close together?
Speed, as with atoms in a plasma phase for instance.

If it's just speed, then why don't two books bond together when you put them in a bookcase? Why don't the pages all bond together? All the atoms there are bouncing about with the same energy (some going faster than others depending on their mass, but there's no difference between bonded and unbonded ones). You haven't modelled bonding at all.

Quote
There is only one way to pull two bonded particles away from one another: throw a third particle directly in between them at high speed.

Picture an air molecule at rest with its two or three atoms aligned vertically. Another air molecule comes in from the left and it's lowest atom hits the highest of the atoms of the first molecule, sending it directly to the right. This kind of collision happens a lot in air without the bonds breaking. The atom that was hit will drag the other atoms in its molecule after it (and the molecule will spin).

Quote
but as my simulation on acceleration shows, reversing the acceleration does not reverse the contraction,

And yet it should, so what is it actually simulating? Compression?

Quote
The method can be wrong, but the logic can't. If we accelerate a firsts particle while its light takes some time to inform the second one that it has moved, then it will have the time to move towards that second one before it moves away, and it will also go on moving towards it during the time the light from that second one will be getting back.

That is what happens with compression, but it's temporary - it runs into a strengthening force opposing that movement as it gets closer to the other particle. You need to think carefully about the difference between length contraction and compression and make sure you're able to model both. Imagine a pair of particles moving at 0.866c to the left. The length contraction on those will be to half the rest separation. If you nudge the left-hand particle repeatedly until the pair are at rest, the length contraction will be completely gone by that time. If you continue to nudge the left-hand particle until the pair are moving at 0.866c to the right, the length contraction to half the rest length will have returned. If your model doesn't produce that pattern, it isn't modelling length contraction. Each nudge will lead to temporary compression, but the pair will find that compression "uncomfortable" and will re-establish correct separation. Before that correct separation is restored, there will be some vibration until that energy is radiated off as heat. Again, your simulation needs to handle all of that. What you actually have now is the start of a model of compression, but it soon goes wrong because you don't have any balance of forces playing out between the particles.

Quote
Of course, but I always consider that the twin at rest is at rest with regard to space so that I'm not forced to use the reference frame principle interminable wording.

Which means that your approach feels closer to the SR one than to LET. With LET, the "stationary" twin is almost certainly not stationary, so it makes no sense to avoid explaining the thought experiment with him moving. You should always consider at least two cases and use the word "if".
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 11/07/2018 22:29:01
Which means that your approach feels closer to the SR one than to LET. With LET, the "stationary" twin is almost certainly not stationary, so it makes no sense to avoid explaining the thought experiment with him moving. You should always consider at least two cases and use the word "if".
SR people already know that the twins are already moving with the earth when one of them starts to accelerate away from the other, and they also know that the accelerating twin will have to travel twice as fast getting back home if they change reference frames, so the only thing that really differentiates the twins is acceleration. If the twins were in space instead of on earth, without knowing which twin has accelerated, nobody could tell which one has gotten younger without looking at their clocks, and inversely, looking at their clocks would automatically tell us which one has accelerated, except maybe SR people that would probably still stick to the idea that motion has to stay relative whatever the logical problems it causes, and that would still try to explain it using the reference frame principle even if acceleration is involved, thus sweeping it under the rug again. Acceleration is simple to understand and determinant, and if we can't convince them to admit that, then I think it is useless to use a more complicated way like you do. They are experts at complicating things, and logic is not part of their vocabulary, so I prefer to hit the acceleration nail as often as I can. On the other hand, going through their complications like you do at least shows them that they can't win at that game either.

Quote from: Le Repteux
The light that bonds the particles is the one that succeeded to escape from the bonding between the components.
I can't follow the logic of that. If the light has escaped, it can have no further role in the bonding: it can't go on traveling to and fro between the particles to maintain the bond.
It escapes from the components' bonding because it is not constant, but not from the particles' bonding since it is. If I made a simulation with two light clocks representing my two particles for instance, if I would accelerate them for a while and then let them go, and if I gave all the steps a sinusoidal shape, the steps the mirrors would make with regard to one another would not be constant, while the steps the clocks themselves would make with regard to one another would be. The clocks would be executing constant length's sinusoidal steps and the mirrors' steps would have to follow them, thus getting longer and longer until the clock's sinusoidal step gets in its middle, and getting shorter and shorter until the same clock's sinusoidal step ends. Longer steps in the same time means faster speed, and a change in speed means acceleration, so the steps the mirrors would be executing would accelerate and decelerate at a sinusoidal rate, thus losing some light in the process, a light that would necessarily reach the other clock after a while, and that could certainly produce its sinusoidal step since it has escaped from such a step.

If it's just speed, then why don't two books bond together when you put them in a bookcase? Why don't the pages all bond together?
Because molecules don't get close enough for the bonding to take place. Take two metal plates, polish them, hold them together in void, and you will get a bonding between them. If you give them some speed towards one another instead of holding them, they will bounce back instead of bonding. I must admit that speed is not the only parameter though, the strength of the bond is determinant too. If the plates are charged for instance, you will get a bonding even if they don't touch.
 
Quote from: Le Repteux
  but as my simulation on acceleration shows, reversing the acceleration does not reverse the contraction,
And yet it should, so what is it actually simulating? Compression?
Thanks! It's about time I get that one. You're right, contraction should reverse until the particles get at rest on the screen, and it doesn't, so something is wrong with that simulation even if the idea that contraction happens at acceleration is right. Back to the drawing board!

Picture an air molecule at rest with its two or three atoms aligned vertically. Another air molecule comes in from the left and it's lowest atom hits the highest of the atoms of the first molecule, sending it directly to the right. This kind of collision happens a lot in air without the bonds breaking. The atom that was hit will drag the other atoms in its molecule after it (and the molecule will spin).
Rotation is different from constant motion, but I didn't simulate it yet, so I can only imagine it. In my simulation on acceleration, after having been accelerated a quantum bit, the first particle to suffer acceleration has to be held where it is while the photon makes its round trip, and it cannot be held in your example, so it should first get away from the second one and then get back where it was, what should produce a vibration. I have to solve my contraction problem before studying rotation though. I could use the SR equation and contract the system each time it accelerates a quantum bit, but I'm not in a hurry. I still hope to discover the underlying mechanism.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 11/07/2018 23:16:37
It escapes from the components' bonding because it is not constant, but not from the particles' bonding since it is.

If you're going to say the light is lost and that this lost light is related to the bonding energy reducing the total mass/energy of the bonded pair, you can't have the bonded pair keep hold of that energy in any way - it has to radiate off, and then your mechanism has to account for the bonding being maintained without that radiated energy.

Quote
Because molecules don't get close enough for the bonding to take place.

Yes they do - they wouldn't be able to conduct heat if the atoms weren't actively bumping into each other, and that bumping isn't enough to create bonds.

Quote
Take two metal plates, polish them, hold them together in void, and you will get a bonding between them.

That might be the case in a vacuum, but only because nothing's available to bond with any unbalanced atoms that are left looking for something to bond with until the plates come together.

Quote
If you give them some speed towards one another instead of holding them, they will bounce back instead of bonding.

In which case the same would work in air as in a vacuum with the air bouncing off without bonding due to speed. The reality is that bonding is more complicated than your model allows for.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 12/07/2018 12:18:39
Resistance is easier to explain with doppler effect though: whenever we try to accelerate the first particle in my simulations on acceleration, it automatically produces blueshift on the light from the second one, and it is automatically forced to get back where it was, so an opposed force has to be applied on it to keep it there until the photon from the other particle is back with the information that it can stay there. If we stop applying the force though, it doesn't erase the redshift the second particle has imprinted on the photon it has already emitted backward to the first one, which is thus forced to move forward again when that light comes in, and so on for the second particle later on, which produces the constant motion that we can observe when we stop the acceleration.
Could you elaborate more ?  I sort of understand
Ask me a question about the part you understand less.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 12/07/2018 13:14:10
whenever we try to accelerate the first particle in my simulations on acceleration, it automatically produces blueshift on the light from the second one,
I will start with this part, are you saying that when the observer tries to move away from the observer at rest, the observer at rest pulls back on the observer trying to accelerate away ?
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 13/07/2018 14:10:42
whenever we try to accelerate the first particle in my simulations on acceleration, it automatically produces blueshift on the light from the second one,
I will start with this part, are you saying that when the observer tries to move away from the observer at rest, the observer at rest pulls back on the observer trying to accelerate away ?
The first particle in my simulation is at the left, and it is accelerated towards the other particle which is at the right. Both particles are continuously exchanging a photon that carries the information on the distance it has traveled, which is the actual distance of the bond, and on the motion of the particle at the moment it was sending the photon, so whenever we try to move the left particle to the right, we have to move it against the force of the incoming photon which is actually trying to keep the right bonding distance while pushing it back to the left. The two forces are thus opposing to one another creating what we call mass. What you are describing happens when acceleration has stopped and particles are on constant motion, except that it is not the observer that pulls or pushes on the other observer like you said, but the light it sends towards it. The photon is emitted during a step, and a particle has already come to a rest when its photon reaches the other particle and vice-versa, which means that the two observers do not actually move at the same time even if they are on constant motion, which also means that when we see something moving, half of its atoms are at rest while the other half is actually making a step forward.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 13/07/2018 14:34:16
whenever we try to accelerate the first particle in my simulations on acceleration, it automatically produces blueshift on the light from the second one,
I will start with this part, are you saying that when the observer tries to move away from the observer at rest, the observer at rest pulls back on the observer trying to accelerate away ?
The first particle in my simulation is at the left, and it is accelerated towards the other particle which is at the right. Both particles are continuously exchanging a photon that carries the information on the distance it has traveled, which is the actual distance of the bond, and on the motion of the particle at the moment it was sending the photon, so whenever we try to move the left particle to the right, we have to move it against the force of the incoming photon which is actually trying to keep the right bonding distance while pushing it back to the left. The two forces are thus opposing to one another creating what we call mass. What you are describing happens when acceleration has stopped and particles are on constant motion, except that it is not the observer that pulls or pushes on the other observer like you said, but the light it sends towards it. The photon is emitted during a step, and a particle has already come to a rest when its photon reaches the other particle and vice-versa, which means that the two observer do not actually move at the same time even if they are on constant motion, which also means that when we see something moving, half of its atoms are at rest while the other half is actually making a step forward.

I have discussed this before  and you will find each particle only has 1/2 its measured mass.   Because of F^2 = m
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 13/07/2018 16:32:24
If you're going to say the light is lost and that this lost light is related to the bonding energy reducing the total mass/energy of the bonded pair, you can't have the bonded pair keep hold of that energy in any way - it has to radiate off, and then your mechanism has to account for the bonding being maintained without that radiated energy.
In my model, radiation happens only during acceleration, and acceleration adds energy to the bonding if it comes from an external collision, which is why that kind of light is spontaneously rejected outside any particles' system after a short while. However, if the acceleration is due to the steps between the components being forced to follow the sinusoidal steps between the particles they are part of, then the energy that is rejected outside the components' system is immediately absorbed by the particles' system later on.

Quote
Because molecules don't get close enough for the bonding to take place.
Yes they do - they wouldn't be able to conduct heat if the atoms weren't actively bumping into each other, and that bumping isn't enough to create bonds.
Heat can also prevent particles from bonding, but we're talking about molecules, which can bond through van der Waals forces depending on circumstances that visibly prevent molecules to bond pages of a book. These forces are weak so they are more elastic than atoms' ones, which is why molecules give rise to what we call physical waves instead of producing small steps when they are accelerated.

The reality is that bonding is more complicated than your model allows for.
Of course it is, but since light seems to be able to explain mass and motion while being exchanged between bonded particles, then I think it is worth studying how it can also explain bonding. Simulations are a good tool to study that kind of thing, and I bet scientists are unable to use them since it implies that relativity is wrong, so we have a head start on them. Simulations cannot simulate all what nature accounts for, but they still can give us a good insight on what it does.
Title: Re: How can I write a computer simulation to test my theory
Post by: opportunity on 13/07/2018 16:38:55
Computers cant test what you are not able to test, right...we the people who program, right?

What are you looking to confirm, right? Maybe deny?
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 13/07/2018 16:58:17
I have discussed this before  and you will find each particle only has 1/2 its measured mass.   Because of F^2 = m
When I said half of the particles were moving, I was describing constant motion, where the particles are making constant steps at different moments, but it is different when they get accelerated, which is what determines their mass. When we accelerate a particle, it opposes to the light from the other particle, so some mass comes front its resistance to move towards it, but the main part comes from the resistance its components oppose to the light they exchange, because that light is a lot more energetic than the one the particles exchange, so it is a bit more complicated than just considering that half of the total mass is measured. Half of the mass comes from the components, and a bit less than half comes from the other particle because, particles being farther away from one another than the components, the light they exchange loses much more intensity with distance than the light the components exchange.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 13/07/2018 17:06:13
Computers cant test what you are not able to test, right...we the people who program, right?

What are you looking to confirm, right? Maybe deny?
Hi Opportunity, welcome aboard!

I'm studying the way light moves between moving bonded particles, and simulations are a nice tool to do so. Math can also do that, but we have to imagine the motion instead of seeing it, which is impossible to do when motion gets a bit complicated. Here is the link to my simulations (http://lumiere.shost.ca/), try them out and tell me your feeling.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 14/07/2018 15:44:26
I have discussed this before  and you will find each particle only has 1/2 its measured mass.   Because of F^2 = m
When I said half of the particles were moving, I was describing constant motion, where the particles are making constant steps at different moments, but it is different when they get accelerated, which is what determines their mass. When we accelerate a particle, it opposes to the light from the other particle, so some mass comes front its resistance to move towards it, but the main part comes from the resistance its components oppose to the light they exchange, because that light is a lot more energetic than the one the particles exchange, so it is a bit more complicated than just considering that half of the total mass is measured. Half of the mass comes from the components, and a bit less than half comes from the other particle because, particles being farther away from one another than the components, the light they exchange loses much more intensity with distance than the light the components exchange.

What actually happens is that when a particle is traversing towards another particle, it inverts the spatial EM field that is relatively traversing towards the oncoming particle.   Imagine two lights that were aligned vertically, one pointing up and one pointing down.  Each light being a different wattage,  now the more powerful light will invert the other light although you would not see this by eye.

Added- Well , actually we do see this in colour and EQL's .


* Ab.jpg (199.53 kB . 2524x1880 - viewed 586 times)

In relation is field density and field convergence , but hopefully you get the points.  In the diagram the inverted light flows ''backwards'' and ''forwards'' at the same time .

Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 18/07/2018 16:06:34
And yet it should, so what is it actually simulating? Compression?
I'm actually working on that simulation. I'll be back in a few days.


Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 18/07/2018 16:41:05
What actually happens is that when a particle is traversing towards another particle, it inverts the spatial EM field that is relatively traversing towards the oncoming particle.   Imagine two lights that were aligned vertically, one pointing up and one pointing down.  Each light being a different wattage,  now the more powerful light will invert the other light although you would not see this by eye.
Two synchronized sources of light create interference patterns like these ones
https://upload.wikimedia.org/wikipedia/commons/2/2c/Two_sources_interference.gif
The two lights interfere without their information being affected, and you seem to mean that it would. Is that so?
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 18/07/2018 18:30:06
What actually happens is that when a particle is traversing towards another particle, it inverts the spatial EM field that is relatively traversing towards the oncoming particle.   Imagine two lights that were aligned vertically, one pointing up and one pointing down.  Each light being a different wattage,  now the more powerful light will invert the other light although you would not see this by eye.
Two synchronized sources of light create interference patterns like these ones
https://upload.wikimedia.org/wikipedia/commons/2/2c/Two_sources_interference.gif
The two lights interfere without their information being affected, and you seem to mean that it would. Is that so?

Yes that is so, the information is not affected if I understand your question right.  A particle for example when it moves away from another particle can easily lose entanglement to the other particle.    The connection is field strength and is wide, but I don't think particles entangle the same information, not all particles are the same.  A beam of particles could soon be lost in space , dissipate without even being seen, its like holding a bunch of all the particles in your hand, some will easily scatter and be lost ,  they only need a direction to travel , you probably just think I am talking rubbish, I probably am .  :P

To add, do you think a handful of particles will lose more mass or keep more mass?

Or will the hand retain all the mass and none escapes ?  The hand covers the particles so none escape ?

Quote
In physics, a free particle is a particle that, in some sense, is not bound by an external force, or equivalently not in a region where its potential energy varies. In classical physics, this means the particle is present in a "field-free" space. In quantum mechanics, it means a region of uniform potential, usually set to zero in the region of interest since potential can be arbitrarily set to zero at any point (or surface in three dimensions) in space.

https://en.wikipedia.org/wiki/Free_particle



Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 18/07/2018 19:18:35
I'm just trying to understand your point in case it would help me to simulate motion. I still think that light drives the way motion is executed by the particles. At first, I thought that we could easily simulate doppler effect, but it turned out not to be that easy, so I'm trying to simplify the problem, and you seem to be complicating it. It is no use trying to complicate things at the beginning of a research, we got to stay simple and wait till people start to understand to start complicating them.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 18/07/2018 19:23:10
I'm just trying to understand your point in case it would help me to simulate motion. I still think that light drives the way motion is executed by the particles. At first, I thought that we could easily simulate doppler effect, but it turned out not to be that easy, so I'm trying to simplify the problem, and you seem to be complicating it. It is no use trying to complicate things at the beginning of a research, we got to stay simple and wait till people start to understand to start complicating them.

Of course , we have to stay simple,  light travels , we know this, it is like asking somebody call the shop when they are going, they have to travel a distance . Only science understands that things travel but are not really relative . Particles have no connection concerning entanglement.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 18/07/2018 19:57:45
The main difference between my theory and others is that I consider light as a motion producer whereas all others only consider it as an information carrier. It is certainly an information carrier at our scale, but when we get down to particles, we discover that it could also move them. I might still be wrong, but it is certainly interesting to study that possibility. As you can see though, scientists are not easier to interest than laymen. :0)
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 18/07/2018 20:08:38
The main difference between my theory and others is that I consider light as a motion producer whereas all others only consider it as an information carrier. It is certainly an information carrier at our scale, but when we get down to particles, we discover that it could also move them. I might still be wrong, but it is certainly interesting to study that possibility. As you can see though, scientists are not easier to interest than laymen. :0)
Sometimes we can read to deep into the information, where others would just not see the information about light.  I think you may be forgetting that ,  science has detectors to see and observe  far better than a laymen.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 18/07/2018 20:25:15
You also have good detectors to observe information, and you can clearly observe that this information produces motion. Why would the information that we exchange produce motion while the one that particles exchange would not?
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 18/07/2018 20:39:52
You also have good detectors to observe information, and you can clearly observe that this information produces motion. Why would the information that we exchange produce motion while the one that particles exchange would not?
Because of different perspective ,  not even comparable and maybe because one particle has more mass and more force applying on the weaker particle.  The weaker particle oblivious to the force applied.
Anyway I am going go away sulk, it does not look like my other theory of prediction worked out to well at first glance.
Title: Re: How can I write a computer simulation to test my theory
Post by: Thebox on 19/07/2018 16:27:35
I have thought more on this subject, quite clearly a particle at absolute rest is not affected by the particle that is moving in the background, the forces would not act on the distant body ,  sort of ignored in respect to entanglement.  I suppose most people have ignorance towards an absolute rest frame where the back ground particle force can be ignored because of enthalpic properties that are created .  But science is like talking to a stone about an absolute reference frame that is independent of everything else.  Particles that keep their distance from enphalpic pressure, remain ignorant of enphalpic pressure. I don't think you are not accounting for this .  When a particle moves away from another particle but still close, the enphalpic pressure is released. 
I have you just give you some more light on the subject, if you listen you might hear and learn something new.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 09/08/2018 20:25:25
That is what happens with compression, but it's temporary - it runs into a strengthening force opposing that movement as it gets closer to the other particle. You need to think carefully about the difference between length contraction and compression and make sure you're able to model both. Imagine a pair of particles moving at 0.866c to the left. The length contraction on those will be to half the rest separation. If you nudge the left-hand particle repeatedly until the pair are at rest, the length contraction will be completely gone by that time. If you continue to nudge the left-hand particle until the pair are moving at 0.866c to the right, the length contraction to half the rest length will have returned. If your model doesn't produce that pattern, it isn't modelling length contraction. Each nudge will lead to temporary compression, but the pair will find that compression "uncomfortable" and will re-establish correct separation. Before that correct separation is restored, there will be some vibration until that energy is radiated off as heat. Again, your simulation needs to handle all of that. What you actually have now is the start of a model of compression, but it soon goes wrong because you don't have any balance of forces playing out between the particles.
I can't find the flaw in my simulation on opposite accelerations (http://www.motionsimulations.com/Acceleration%20in%20opposite%20directions)' logic, so I get back analyzing SR, because I think we must not take it for granted when we analyze contraction. In the twins mind experiment for instance, the traveling twin must start getting younger and getting contracted at the beginning of his acceleration since it is there that he begins getting speed, and the theory predicts that he must stay younger when he loses all his speed at the end, so why wouldn't he stay contracted since he got contracted the same way he got younger? Just because it looks weird? To me, time dilation is as weird as length contraction. The only difference is that contraction is considered not to be observable. It may not be observable for real particles, but it is certainly observable in a simulation.

The speed my particles get comes from their steps, they are virtually walking in space. Changing the length of their steps changes their speed, so whenever we try to change their length during acceleration to lower the contraction rate, we automatically lower their speed so the contraction rate stays the same. SR adapts the contraction rate to the speed so that the two arms of the MM experiment stay tuned, but they have almost no data to back them up. The muon experiment is a one way measure on a particle that is almost as fast as light, so it is as biased as any one way measure of light, and we didn't yet send a clock for a round trip in deep space to check if it really ages less than the one at rest. All we have is a round trip made by fast particles in an accelerator to check if their decay rate is the same as when they are slow, but we don't even know why they decay, so we can't even simulate it. I simply don't trust experiments that I cannot simulate.

Now about compression: in my simulations, if we start accelerating a particle and let it go before the light from the acceleration of the other particle is back, it should immediately get back to its previous position, which is similar to compression, but if we keep exerting a force on it instead, it should increase its speed each time a photon from the other particle would strike it. Saying that, I realize that it never moves backward one step when we stop the acceleration and it should, so I could correct that, but it wouldn't change the contraction rate, it would only induce a small vibration between the particles as soon as we would stop accelerating them. 
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 09/08/2018 21:36:01
In the twins mind experiment for instance, the traveling twin must start getting younger and getting contracted at the beginning of his acceleration since it is there that he begins getting speed,

In LET, he may be slowing down when he starts his journey rather than speeding up, so he will age more quickly during the first leg of the trip, but it will then be a short trip and he will age much more slowly on the longer return leg, ending up "younger" than his twin (although in reality he remains the same age and has merely "weathered" less due to slowed overall functionality).

In SR (which consists of a set of broken models, none of which function correctly), he travels a shorter path through time and is physically younger than his twin when they next meet, but you can't simulate that without using Minkowski Spacetime, and even if you do that, you can't get rid of the event-meshing failures without going to a block universe model where all events exist eternally and nothing was ever caused by anything.

Quote
and the theory predicts that he must stay younger when he loses all his speed at the end, so why wouldn't he stay contracted since he got contracted the same way he got younger?

Once he's back co-moving with his twin, his rate of ageing will be the same as his twin's. He doesn't stay the same age forever at the end of the trip, and he doesn't remain more contracted than his twin.

Quote
To me, time dilation is as weird as length contraction. The only difference is that contraction is considered not to be observable. It may not be observable for real particles, but it is certainly observable in a simulation.

Contraction is observable and MM measures it happening. In principle, if we could accelerate large objects to relativistic speeds, we'd be able to measure them as being shortened (although it could be us that's actually shortened while they have uncontracted).

Quote
The muon experiment is a one way measure on a particle that is almost as fast as light, so it is as biased as any one way measure of light, and we didn't yet send a clock for a round trip in deep space to check if it really ages less than the one at rest. All we have is a round trip made by fast particles in an accelerator to check if their decay rate is the same as when they are slow, but we don't even know why they decay, so we can't even simulate it. I simply don't trust experiments that I cannot simulate.

They've sent atomic clocks round the Earth in planes and satellites, and they see time "slowing" in them (meaning that the clocks run slow) due to their speed of movement, although they always get this in combination with them speeding up due to the reduction in gravity, which means they haven't separate out the two effects to demonstrate them individually. However, they have done the experiment with gravity differences alone, running clocks at different heights, so they know that this part of the slowing works as predicted, and that makes it easy to subtract that effect out from the aeroplane/satellite experiments and leave just the slowing caused by speed of movement. It's all been well tested and backs the theories.

Quote
Now about compression: in my simulations, if we start accelerating a particle and let it go before the light from the acceleration of the other particle is back, it should immediately get back to its previous position, which is similar to compression, but if we keep exerting a force on it instead, it should increase its speed each time a photon from the other particle would strike it. Saying that, I realize that it never moves backward one step when we stop the acceleration and it should, so I could correct that, but it wouldn't change the contraction rate, it would only induce a small vibration between the particles as soon as we would stop accelerating them.

If you have a problem getting contraction and compressions right, it means the model's wrong. You're trying to do something complex with a model that's too simple to do what you want it to. Particles actively maintain their separation to each other, moving closer together if they're too far apart and moving further apart if they're too close together, but you don't have any of that, and until you do, you'll get behaviour that doesn't fit the real universe. These continual adjustments that particles need to make will depend on communications being sent back and forth at the speed of light, but it isn't as simple as having them play football with photons.

If you nudge the right particle to the right, it must accelerate the left particle if they are tied together with a bond, but if they aren't, it should simply leave it behind. The model needs to include the option to bond particles to each other, and I have no idea how that bonding occurs. How does an electron tie itself to two atoms while being more strongly a part of one than the other? Maybe it doesn't - maybe it belongs to both atoms and switches between them quadrillions of times per second. Whatever's going on though, it's a complex mess, and unless you have ideas about the mechanisms that might be involved in this, you can't expect to be able to simulate anything of that kind. Just pinging a photon to and fro was never going to hack it. You need a much more complex model, and you need a better programming environment if you're going to have any hope of creating such a model through an approach of trial and error. It can take years to program a complex model even if you start out with a detailed knowledge of what the model is, but to approach a solution experimentally were you have to keep rewriting code thousands of times requires AGI to write the code for you - life's simply too short otherwise.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 11/08/2018 16:45:20
ending up "younger" than his twin (although in reality he remains the same age and has merely "weathered" less due to slowed overall functionality).
Are you only saying that to conquer the relativists that may read the thread, or do you really think that getting weathered is different than aging more?

Once he's back co-moving with his twin, his rate of ageing will be the same as his twin's. He doesn't stay the same age forever at the end of the trip, and he doesn't remain more contracted than his twin.
Right, but it took again some time before I realize it, so it means that I was again blinded by my automatic resistance to change, which is probably increased by my understanding getting slower with age. It's a chance for me that your language is so clear and that you don't mind repeating things. :0)

Particles actively maintain their separation to each other, moving closer together if they're too far apart and moving further apart if they're too close together, but you don't have any of that
I think that what you are describing is vibration, and I just said that I could easily add it to my simulations if I wanted, but that it wouldn't resolve the contraction problem, which is that it doesn't reverse when I reverse the acceleration while it should. There is probably a flaw in my logic, and it must be quite subtle otherwise you would have spotted it.

The model needs to include the option to bond particles to each other, and I have no idea how that bonding occurs.
I chose to include motion as a constraint to reduce the possibilities, and I got that doppler effect alone could explain both mass and motion. Of course I may be wrong, but the principle is so easy to understand that it's hard to believe that it is completely wrong. With doppler effect, bonding can be a standing wave issue where particles have to move to stay on the nodes. Maybe the problem comes from simulating only inline particles, and always accelerating the left one to the right and the right one to the left, because whenever the particles would get sideways to the acceleration, they would both be accelerated in the same direction at the same time, and in fact, they should be more often at an angle to the acceleration than inline. As you already pointed out, if we accelerate one of the particles sideways, it will start rotating away from the other instead of getting closer, so if during the acceleration, the two particles would ever get away half the time and get closer the other half, there would be no contracting nor stretching overall, but there would still be acceleration. I think it would work as if each particle would alternatively be pushed and pulled towards and away from the other particle. It wouldn't produce any contraction, but it would produce speed, and if we would stop the acceleration after a while, the photon would still take less time to make its round trip than when the system was at rest, so there would still be some time dilation even if there is no contraction. If we would let the system contract just the right amount though, it would automatically produce the right time dilation, but as I usually say in this case, we need to find the underlying mechanism, not to add an SR equation to the simulation.

You need a much more complex model
Of course, but I think that the principle must stay simple. Evolution of species may very well be complex for instance, but the mutation/selection principle is still simple.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 11/08/2018 21:03:48
Are you only saying that to conquer the relativists that may read the thread, or do you really think that getting weathered is different than aging more?

"Ageing" is ambiguous. It can either refer to the amount of time that someone has been around for or to the amount of "weathering" they've been exposed to, and by that I mean the amount of wear and tear due to the rate at which they function. Slowed functionality leads to less ageing (weathering) but not to less ageing (exposure to time). The shorter paths through time that are supposed to be available through SR and GR are just an figment of the imagination that comes out of a warped mathematical abstraction which produces a model that doesn't function rationally.

Quote
I think that what you are describing is vibration, and I just said that I could easily add it to my simulations if I wanted, but that it wouldn't resolve the contraction problem, which is that it doesn't reverse when I reverse the acceleration while it should. There is probably a flaw in my logic, and it must be quite subtle otherwise you would have spotted it.

If you simulated the forces that enable vibration, the separation between particles as you accelerate them would continually adjust back to the most "comfortable" separation where the forces are balanced properly. That will eliminate all the false contraction that your model generates, and then it will allow you to introduce real length contraction when you model those forces correctly.

Quote
I chose to include motion as a constraint to reduce the possibilities, and I got that doppler effect alone could explain both mass and motion. Of course I may be wrong, but the principle is so easy to understand that it's hard to believe that it is completely wrong. With doppler effect, bonding can be a standing wave issue where particles have to move to stay on the nodes.

What you need to do then is run a simulation where you have the particles behave like they do in the real universe, and then try to match your standing waves up to them. If standing waves are part of the real mechanism for maintaining particle separation distances, you need to have that acting to adjust the positions of the particles, but you don't appear to have modelled that yet.

Quote
It wouldn't produce any contraction, but it would produce speed, and if we would stop the acceleration after a while, the photon would still take less time to make its round trip than when the system was at rest, so there would still be some time dilation even if there is no contraction. If we would let the system contract just the right amount though, it would automatically produce the right time dilation, but as I usually say in this case, we need to find the underlying mechanism, not to add an SR equation to the simulation.

There's no need to take anything from SR. LET has everything you need (and there's nothing particularly special about LET - it's just a corrected version of the older aether theory that MMX was testing). If you're going to produce proper length contraction, you have to adjust all accelerations to take into account relativistic mass (because not all the energy added translates into speed of the particle being accelerated - the extra energy has to carry its own mass along for the ride too). When you do that, everything should fall neatly into place.

Quote
I think that the principle must stay simple. Evolution of species may very well be complex for instance, but the mutation/selection principle is still simple.

It can stay simple, but so far you're been trying to use aspects of compression to try to recreate length contraction, and that won't work because the particles should always try to remove that compression and get back to a comfortable separation. Length contraction comes out of changes in the comfortable separation distances.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 12/08/2018 19:56:13
It can stay simple, but so far you're been trying to use aspects of compression to try to recreate length contraction, and that won't work because the particles should always try to remove that compression and get back to a comfortable separation. Length contraction comes out of changes in the comfortable separation distances.
If we accelerate one end of a spring, it will contract during acceleration, and then spring away from us at the end while also oscillating. It will oscillate because the inertia of the front end will stretch the middle of the spring before the force reaches the rear one and pulls it ahead, the same as if we would have pulled the two ends both at a time. With a spring, an important part of the acceleration's energy is absorbed by a vibration phenomenon when acceleration stops, and it happens because the whole spring stretches back, whereas in my simulations, only the last step produces a vibration because it is the only one to stretch back. It is so because the motion of light is independent from the motion of massive particles, whereas the motion of a spring precisely depends on them. Moreover, with the standing wave principle as a cause for bonding, if we compress two particles until they jump to another node, they will stay there until something else happens. That's what happens too when an electron is bumped to another energy state: it stays there until something happens, and if nothing happens, it spontaneously gets back to its minimum energy state after a while, which means that something probably happens without us being able to observe it. At our scale, it is matter that transmits the information that moves bodies, whereas at the scale of the particles, the information has to travel through void, so it has to rely on some kind of light.

If you're going to produce proper length contraction, you have to adjust all accelerations to take into account relativistic mass (because not all the energy added translates into speed of the particle being accelerated - the extra energy has to carry its own mass along for the ride too).
Then I would have to find a simulable mechanism for relativistic mass too, because using any equation would be cheating. On the other hand, if we had to accelerate a ship instead of a particle, we would have to eject a mass that has also increased due to speed, and if I had to simulate it, I don't think it would change the rate of acceleration on the screen, so it would be useless. Which means that when we accelerate particles with an accelerator, it is because the particles' speed gets as fast as our device that we can't accelerate them more, which is similar to why the particles shouldn't get faster than the photons in my simulations. They actually do, but only because I didn't care for that. When particles get as fast as the photons, they should simply stop accelerating even if the force increases. That's what happens to the constant steps of my simulations, but if they were sinusoidal, then they would be faster in the middle than at the ends, and the particles would then have to wait for the middle of the photons to reach them whenever the middle of their steps would be approaching the speed of light. Since it is the time the photons take to make a round trip that determines the resistance the particles oppose to their steps being accelerated, increasing that time automatically increases their resistance, thus their mass. In particles' accelerators, it is also light that accelerates the particles, so the two phenomenon interfere, but the light the particles' components exchange is a lot more energetic than the one the accelerator produces, so that the mass increase of the particles is mainly due to the steps the components execute with regard to one another.

If standing waves are part of the real mechanism for maintaining particle separation distances, you need to have that acting to adjust the positions of the particles, but you don't appear to have modeled that yet.
Keeping the particles on sync while they are being accelerated is precisely what a standing wave would do. Ivanhov and late Lafresnière (http://www.rhythmodynamics.com/Gabriel_LaFreniere/sa_plane.htm) have already studied the standing wave model, and Ivanhov even thinks that, on that precise point, our two theories work the same.

If you simulated the forces that enable vibration, the separation between particles as you accelerate them would continually adjust back to the most "comfortable" separation where the forces are balanced properly. That will eliminate all the false contraction that your model generates, and then it will allow you to introduce real length contraction when you model those forces correctly.
If we hit the "nudge both together" button five times as fast as we can in your simulation with ten photons (http://www.motionsimulations.com/Acceleration%20with%20ten%20photons), we get a vibration, and I could do the same with my simulations, which means that light can produce a vibration even if it has no mass providing we nudge the particles both at a time. If we nudge only one, then we only get motion in one direction.

"Ageing" is ambiguous. It can either refer to the amount of time that someone has been around for or to the amount of "weathering" they've been exposed to, and by that I mean the amount of wear and tear due to the rate at which they function. Slowed functionality leads to less ageing (weathering) but not to less ageing (exposure to time).
To me, weathering faster is the same as ageing faster since both are directly related to the time light takes between my two particles. If light takes less time compared to the time it takes in an observer's similar light clock, then the particles age faster and weather faster than him, and the inverse if it takes more time.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 12/08/2018 22:56:45
If we accelerate one end of a spring, it will contract during acceleration, and then spring away from us at the end while also oscillating.

And if you accelerate the whole spring in one go, you avoid simulating the oscillations and the energy tied up in that which ends up being radiated off as heat. If you accelerate the whole spring, you don't get the compressions that can be mistaken for length contraction. What happens when you accelerate both of your particles from zero to relativistic speed at the same time? Do you get length contraction? No. That contraction has to come from a different mechanism which relates to "comfortable" separation.

Quote
Then I would have to find a simulable mechanism for relativistic mass too, because using any equation would be cheating.

If you want to do it without an equation, you need to simulate the energy and particles directly. What happens when you try to accelerate an object by hitting it with light? Energy is transferred, and if the light bounces back off the object rather than being absorbed, the frequency of the reflected light will be lower. No matter how many times you repeat this, and no matter how much of the light the object can absorb (and thereby carry all the added energy with it), it cannot go faster than c, or even reach c, and the reason for that is easy to explain. The light that hits the object is going at c. If it is to speed up the object, it can no longer move itself at c, so it must slow down to a speed lower than c which the object can speed up to. This applies to any energy that you add to the object - it has to drag itself along for the ride (maximum speed c), but to transfer any of that to the movement of the object, it has to slow down to less than c. This effect kicks in gradually as you accelerate an object, so initially it makes great gains in speed, but later on it becomes harder to increase it so quickly. That is the cause of length contraction - it causes an orbiting object to slow down relative to the thing it's orbiting when the object is moving fastest through space, and to speed up relative to the thing it's orbiting when the object is moving slowest through space.

If you imagine a stationary planet spinning round  with an object on the end of a long pole such that the object is moving at 0.86c. Now imagine the same system with the planet moving through space at 0.86c. The object will now be stationary relative to space when it is at one side of its orbit, and at the opposite side it will be moving at a speed lower than c rather than 2 x 0.86c. This adjustment of speed is the cause of length contraction - it is not possible for the object to move at 2 x 0.86c. The "orbit" automatically becomes length contracted to half that of the system where the planet is stationary. There is no need to look for any other mechanism for length contraction when we already have one that accounts for it and which must be acting. What we don't have is the full detail on how this applies to contraction of materials, but that's because we don't have a clear picture of how electrons move. What is certain though is that if an electron (or parts of a spread out fuzz of electron) move forward relative to a fast moving nucleus, they must obey the rules of relativistic velocity addition and go more slowly relative to the nucleus in the forward direction than they do when moving aft. This will necessarily length-contract the distribution of their "fuzz". You can't simulate length contraction on that scale though without modelling the movements of such parts of "fundamental" particles, and that means guessing their nature (because science has yet to pin their nature down) and then simulating the entirely hypothetical model that comes out of that guess.

Quote
Since it is the time the photons take to make a round trip that determines the resistance the particles oppose to their steps being accelerated,

What happens if you only accelerate one particle? No resistance? No mass? The resistance comes from the directionality of the energy tied up in matter - if it was all trying to go in the same direction, the whole thing would become radiation moving at c. It can only be matter because some of the energy tied up in it is trying to go in a different direction. The resistance to acceleration comes from that component of energy that is going in the opposite direction from the one you're trying to accelerate it in. The mass is the total energy in the matter, and if it's all moving in the same direction it will be moving at c as radiation and will officially have no mass, but the mass is really still there - we just stop calling it mass.

[quoteKeeping the particles on sync while they are being accelerated is precisely what a standing wave would do. Ivanhov and late Lafresnière (http://www.rhythmodynamics.com/Gabriel_LaFreniere/sa_plane.htm) have already studied the standing wave model, and Ivanhov even thinks that, on that precise point, our two theories work the same.[/quote]

I'm open to that possibility, but I haven't read up on it enough to see how it would work, but it should be an interesting thing to write a simulation for if it looks viable - this would keep adjusting the particles to the correct "comfortable" separation (or at least to oscillate around it).

Quote
If we hit the "nudge both together" button five times as fast as we can in your simulation with ten photons (http://www.motionsimulations.com/Acceleration%20with%20ten%20photons), we get a vibration, and I could do the same with my simulations, which means that light can produce a vibration even if it has no mass providing we nudge the particles both at a time. If we nudge only one, then we only get motion in one direction.

It isn't good enough just to get a vibration out of a simulation - it needs to be the right kind of vibration if it is going to maintain correct average particle separation.

Quote
To me, weathering faster is the same as ageing faster since both are directly related to the time light takes between my two particles. If light takes less time compared to the time it takes in an observer's similar light clock, then the particles age faster and weather faster than him, and the inverse if it takes more time.

Correct, but the other meaning of age refers to the amount of time that has actually passed, and in that sense, both twins remain the same age no matter how much the physicists prod them around, so I used the word weathering to rule out that interpretation of ageing in order to avoid ambiguity.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 15/08/2018 16:43:42
Correct, but the other meaning of age refers to the amount of time that has actually passed, and in that sense, both twins remain the same age no matter how much the physicists prod them around, so I used the word weathering to rule out that interpretation of ageing in order to avoid ambiguity.
Sorry, I see no ambiguity. Of course, the time flows the same for people that are in the same reference frame, but the twins are not and we know which one is traveling, so there is no ambiguity, we know which one is getting younger. Maybe there is ambiguity when you're talking to SR people, but not to me. That's why I was asking you if it was the case.

It isn't good enough just to get a vibration out of a simulation - it needs to be the right kind of vibration if it is going to maintain correct average particle separation.
While executing their steps, the particles move to absorb doppler effect, so from their viewpoint, they are always at the right place at the right time whether they execute their steps in the same direction or in opposite ones as it is the case for vibrations. For them, the energy of the bond stays the same even if for us, they are not always at the same distance from one another on the screen. I still have a problem with the intensity of light not being the same both ways though, because it can take a lot more time for the photon to travel one way than the other, a phenomenon that the steps cannot account for since they only depend on frequency. We can rely on the particle behavior of a photon to consider that it doesn't lose energy with distance, but that leads to the weirdness of the diffraction data.

What happens if you only accelerate one particle? No resistance? No mass?
When we accelerate a particle on the screen, in reality, what we accelerate are its components, and the main part of the resistance is then due to the steps between those components refusing to get accelerated instantly, which is also because information takes time to make a round trip between them. The components are more massive, thus resist more to the acceleration, just because the light they exchange is more energetic than the one the particles exchange, and it is more energetic just because it loses a lot less intensity with distance due to the components being a lot closer to one another. I can't use frequency as the only cause for the increase of energy because I need that the light exchanged between the particles comes from the exchange of light between the components. This way, the light exchanged between the particles is a modulation of the light exchanged between the components, and the visible light is a modulation of the light exchanged between the particles, the modulation itself depending on the smaller steps having to accelerate and decelerate constantly to justify the sinusoidal shape of the longer ones they are part of, while any step that is accelerated necessarily let some light go by due to a temporary broken synchronism between the incoming light and the step.

The resistance comes from the directionality of the energy tied up in matter - if it was all trying to go in the same direction, the whole thing would become radiation moving at c. It can only be matter because some of the energy tied up in it is trying to go in a different direction. The resistance to acceleration comes from that component of energy that is going in the opposite direction from the one you're trying to accelerate it in. The mass is the total energy in the matter, and if it's all moving in the same direction it will be moving at c as radiation and will officially have no mass, but the mass is really still there - we just stop calling it mass.
Mass is measured while we try to give some speed to a body in a particular direction, and that's precisely the same definition with the steps, it is measured while we try to give some speed to the steps in a particular direction, a speed they get while increasing their length since their frequency has to stay the same for them to be able to get synchronized. That mechanism can be simulated, but I can't see how we could simulate what you say. You seem to be assimilating light to massive particles moving at c, and massive particles to light moving at less than c, whereas I simply assimilate particles to sources of light needing to stay synchronized. That principle means that light comes from the heart of matter, and that it migrates from the smaller to the larger particles until it gets to our scale. When we accelerate a body made of bonded particles, we accelerate all the infinitely small particles it is made of, they lose some light in the steps' process, and that light then accelerates all the larger particles it is also made of, until it gets at the scale of the molecules, from where it can only escape to bond macroscopic bodies.

Quote
Keeping the particles on sync while they are being accelerated is precisely what a standing wave would do. Ivanhov and late Lafresnière have already studied the standing wave model, and Ivanhov even thinks that, on that precise point, our two theories work the same.
I'm open to that possibility, but I haven't read up on it enough to see how it would work, but it should be an interesting thing to write a simulation for it if it looks viable - this would keep adjusting the particles to the correct "comfortable" separation (or at least to oscillate around it).
If the two theories really work the same, then we can consider that, in my simulations, the particles are located on the nodes of their standing wave.

If you imagine a stationary planet spinning round  with an object on the end of a long pole such that the object is moving at 0.86c. Now imagine the same system with the planet moving through space at 0.86c. The object will now be stationary relative to space when it is at one side of its orbit, and at the opposite side it will be moving at a speed lower than c rather than 2 x 0.86c. This adjustment of speed is the cause of length contraction - it is not possible for the object to move at 2 x 0.86c.
In a simulation with two particles, for the photon to be able to reach the leading particle all the time in the case of your example, the particle should wait for the photon when it goes up ether, which would effectively accelerate it backwards, an information that would be transmitted to the trailing one after a while. Again, the sinusoidal shape of the steps would have to be accounted for in the simulation, otherwise the deceleration would begin only when the particle would hit c. Curiously, that simulation would work as my simulation in opposite directions (http://www.motionsimulations.com/Acceleration%20in%20opposite%20directions) even if there is no inertial acceleration involved, so it would not produce contraction either if we consider that the system would be alternatively stretched or contracted depending on its direction with regard to the direction of the acceleration, it would only produce deceleration.

You can't simulate length contraction on that scale though without modelling the movements of such parts of "fundamental" particles, and that means guessing their nature (because science has yet to pin their nature down) and then simulating the entirely hypothetical model that comes out of that guess.
I can't simulate the motion of electrons using the steps between their components since they are considered not to carry any, so I can't use those steps to explain their mass either. Massive particles that carry no components is weird since they would have to be infinitely small while still being observable at our scale. Quantum physics has solved the problem by introducing virtual photons as a carrier of information between electrons and nucleus. I use photons too, but they produce real motion so they must be real even if we can't observe them directly. The light that we do observe is only their modulation when they escape from bonded systems during their acceleration.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 15/08/2018 19:09:45
Sorry, I see no ambiguity.

In LET, time flows at a constant rate for all things, but apparent time varies when functionality is slowed by movement (increasing round-trip communication times) or gravitational fields (causing a slowing of the speed of light and thereby again increasing round-trip communication times). The amount of apparent time that has passed for an object will determine how much ageing/weathering it has suffered (which is why one twin looks older than the other), while the amount of actual time that has passed for an object can be disguised by different weathering: the twins are the same actual age, but one has aged more in the weathering sense of the word.

Quote
While executing their steps, the particles move to absorb doppler effect, so from their viewpoint, they are always at the right place at the right time whether they execute their steps in the same direction or in opposite ones as it is the case for vibrations.

But the separations are wrong, so something in the model is wrong. To improve the model, you'll just have to keep changing things until it matches up to what real particles do, although that might take a century of work. It would speed things up if you started with a model that matches up to reality and then try to change some of the mechanisms to retain the correct behaviour, but with alternative explanations which may be superior to the original ones. It would certainly help if you could see the two models working side by side so that you'd know at a glance when your experimental model is failing to match up correctly so that you don't think you're producing useful kinds of contraction when a correct model would be removing contraction instead (while decelerating an object).

Quote
When we accelerate a particle on the screen, in reality, what we accelerate are its components, and the main part of the resistance is then due to the steps between those components refusing to get accelerated instantly, which is also because information takes time to make a round trip between them.

What happens if you accelerate all the components at once though? You should get no vibration generated in the object, so all the energy goes into acceleration of the object. No resistance? No mass? Because all the components can be accelerated simultaneously, the mechanism for resistance or mass has to apply to the acceleration of a single particle without any of your steps being involved.

Quote
Mass is measured while we try to give some speed to a body in a particular direction, and that's precisely the same definition with the steps, it is measured while we try to give some speed to the steps in a particular direction, a speed they get while increasing their length since their frequency has to stay the same for them to be able to get synchronized.

When are they ever synchronised? An object changing speed whenever it happens to be hit by a photon isn't really synchronisation. The frequencies should also be changing dynamically depending on the speed of the emitter and the relative speed of the photon to the target particle, and the perceived strength of the force being received will depend on the speed of the receiver (its rate of functionality). Unless you program all of that in, you can't usefully explore anything relating to relativity, and I'm not sure you can even shed any light on mass.

Quote
You seem to be assimilating light to massive particles moving at c, and massive particles to light moving at less than c,

No - there's a fundamental difference between the two cases: in the former case, all the energy is trying to move in the same direction, whereas in the latter case some of it is trying to move the opposite way, and that classes this conglomeration as matter - separate the components through decay and they all race off as radiation at c, but so long as they're tied together, they fight it out and move at >c.

Quote
If the two theories really work the same, then we can consider that, in my simulations, the particles are located on the nodes of their standing wave.

Where are the nodes? Where are the standing waves? Have you produced any? Have you got a simulation that displays them so that I can get some idea of where they are?

Quote
In a simulation with two particles, ...would effectively accelerate it backwards...

Incorrect models tend to produce incorrect results. The cure is to correct the model. Given that you think standing waves are the answer to getting correct particle separations, I think you should work on that first by showing that they exist in your model. Until you do that, there's no point in thinking about simulating length contraction with it.

Quote
I can't simulate the motion of electrons using the steps between their components since they are considered not to carry any, so I can't use those steps to explain their mass either.

And that's the big problem with modelling things that go beyond scientific understanding. All matter can decay into radiation (components), but we have no idea how the components are tied together to create the "fundamental" particles that are built out of them. All we can do is create speculative models, or models that fudge the issue and just apply rules without the full mechanism being simulated.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 16/08/2018 17:34:19
In LET, time flows at a constant rate for all things, but apparent time varies when functionality is slowed by movement (increasing round-trip communication times)
To me, time is only a measure of cyclic events with regard to one another, and if a traveling twin has aged 5 years less than his brother, it simply means that he has lived five years less than his brother, exactly like my younger brother that has not traveled. I googled for ether theory time flow and found nothing. Is there a paper that explains what you mean?

What happens if you accelerate all the components at once though? You should get no vibration generated in the object, so all the energy goes into acceleration of the object. No resistance? No mass? Because all the components can be accelerated simultaneously, the mechanism for resistance or mass has to apply to the acceleration of a single particle without any of your steps being involved.
Except for electrons, there is no single particle, everyone of them has components, and it is most improbable that the smallest of them could all get accelerated at the same time. With the steps, acceleration begins at the smallest scale and migrates to the larger ones.

When are they ever synchronised?
When particles are on constant motion, when no acceleration happens to them, they then go on making steps that are perfectly synchronized.

An object changing speed whenever it happens to be hit by a photon isn't really synchronisation.
The speed of the particles depends on the length of their steps, and during constant motion, that length stays constant, and the steps then dovetail the sinusoidal shape of the photons, in such a way that an observer on one of the particles would observe no doppler effect at all.

all the energy is trying to move in the same direction, whereas in the latter case some of it is trying to move the opposite way
The energy you're talking about, to what is it linked? What makes it turn around and move in the opposite direction?

Where are the nodes? Where are the standing waves? Have you produced any? Have you got a simulation that displays them so that I can get some idea of where they are?
Ivanov did. He tested how a moving standing wave would behave while placing two sound emitter/receiver at a few meters away from one another, and he measured the displacement of the nodes when it was windy. He observed that the standing wave was contracting whatever the direction of the wind, and he suggested that it would be the same for light, what would explain the relativistic contraction. Lafrenière comments this point on the page where I referred you (http://www.rhythmodynamics.com/Gabriel_LaFreniere/sa_plane.htm). I didn't remember about the contraction observation, but I think I might be able to use it directly in my simulation without having to simulate it. I could simply use the equation since it is the result of an experiment. If you take a look at the page, you will notice that some of the links to specific animations don't work. Ivanhov imported Lafrenière's pages when he died, and I think he couldn't handle those links. Maybe he still has them in his computer though. Thank's to you, I might have made a huge step here! :0)

Quote from: Le Repteux
I can't simulate the motion of electrons using the steps between their components since they are considered not to carry any, so I can't use those steps to explain their mass either.
And that's the big problem with modelling things that go beyond scientific understanding. All matter can decay into radiation (components), but we have no idea how the components are tied together to create the "fundamental" particles that are built out of them. All we can do is create speculative models, or models that fudge the issue and just apply rules without the full mechanism being simulated.
Without adding some restriction, there is too many possibilities. Adding bonding to motion is such a restriction, and it looks promising to me. It is certainly speculative, but then, how to progress without speculating? I'll check Ivanhov's contraction carefully to see if I can simply add it to my simulations. If I can, then I will have to change the way the particles behave during their acceleration.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 16/08/2018 23:02:32
Is there a paper that explains what you mean?

Not that I know of. Look at it this way though. Compare a moving light clock with a stationary one. The moving one ticks out less time. However, the light pulses have travelled the same distance through space, so how much time has passed for the photons? The amount of time that's passed for them is identical - the one in the moving clock has clearly not had its functionality slowed down. All the particles in the clock are ultimately made of waves that move about at c, so none of them have had their functionality slowed down either. The only things that can have slowed functionality are composite objects, but none of the fundamental components from which they're made are slowed at all. There is no such thing as slowing of time - there is only slowing of functionality, and that is restricted to composite items.

Quote
Except for electrons, there is no single particle, everyone of them has components, and it is most improbable that the smallest of them could all get accelerated at the same time. With the steps, acceleration begins at the smallest scale and migrates to the larger ones.

Lots of people call quarks fundamental too, but when antimatter meets matter, pouf! They all turn to radiation. Same thing happens when an electron meets a positron - instant conversion to components. Acceleration is just the result of a fight between different amounts of energy with different directionality - add some new energy in with westward directionality and the object will accelerate to the west (or decelerate if it was already moving east).

Quote
When particles are on constant motion, when no acceleration happens to them, they then go on making steps that are perfectly synchronized.

That doesn't really work though, because if you teleport one of them to increase or reduce the separation, they continue to be "synchronised", so it has no control over the distance between them.

Quote
The speed of the particles depends on the length of their steps, and during constant motion, that length stays constant, and the steps then dovetail the sinusoidal shape of the photons, in such a way that an observer on one of the particles would observe no doppler effect at all.

Change the separation though and they continue as if no change has been made - it just takes longer for them to take turns moving, and they move for a longer length of time on each move.

Quote
The energy you're talking about, to what is it linked? What makes it turn around and move in the opposite direction?

It's all tied up together in some way - all the energy that's in there is bound together such that it doesn't just break up and turn to radiation flying off at c in different directions.

Quote
Ivanov did. He tested how a moving standing wave would behave while placing two sound emitter/receiver at a few meters away from one another, and he measured the displacement of the nodes when it was windy. He observed that the standing wave was contracting whatever the direction of the wind, and he suggested that it would be the same for light, what would explain the relativistic contraction. Lafrenière comments this point on the page where I referred you (http://www.rhythmodynamics.com/Gabriel_LaFreniere/sa_plane.htm).

I was pressed for time and my computer was locking up, so I didn't click on the link at the time, though I also assumed that it was a page I'd seen before - Ivanov's done a lot of complex stuff that I need to spend time going through carefully. However, this isn't the page I was expecting - it may be easier for me to get into and understand the point now, because this looks a lot more inviting, so I'm going to put some time into exploring it, and I'll then think about how it can be built into your simulations (and about how it relates to LET). Most importantly though, this isn't photon ping-pong, but seems to involve two waves being sent out continuously and interacting, but where are they coming from if the particles are sitting at nodes between the two ends? Or are they? Anyway, I'm beginning to see a possible direction to take with these simulations, but I may need to think about it for a few weeks to let it all soak in. This stuff is missing from my model, and I need to add it. We can be sure that we're ultimately dealing with things made up of waves, so there must be something that can be done with this wave stuff that would produce a speculative model that fits the facts. I actually read something a few weeks ago that comes to mind now, and it was to do with quantum stuff being explained through classical physics - they had standing waves interacting with particles in some way too, and the thrust of what they were saying seemed to imply that the particle can have a definite position that can't be determined by us because we can only measure the wave, but that the underlying physics has no randomness at its core.

Quote
I didn't remember about the contraction observation, but I think I might be able to use it directly in my simulation without having to simulate it. I could simply use the equation since it is the result of an experiment. If you take a look at the page, you will notice that some of the links to specific animations don't work. Ivanhov imported Lafrenière's pages when he died, and I think he couldn't handle those links. Maybe he still has them in his computer though. Thank's to you, I might have made a huge step here! :0)

I'm glad you found this stuff - it may open some doors for me into an area I've avoided because I don't want to get bogged down in the complexities of small-scale physics, but I've seen something now which might just hook me in (because it may not be as time-consuming as I was expecting, and that means it might not get in the way of my work).
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 17/08/2018 20:35:32
However, the light pulses have traveled the same distance through space, so how much time has passed for the photons?
Time stops flowing for a light clock that gets at the speed of light with regard to ether, so a photon can't experiment time. The time a photon takes is not measured with regard to itself, it is measured with regard to a clock made out of matter, and the distance itself also needs to be delimited by matter. You seem to be assimilating matter to energy to light, and I can't, otherwise I couldn't simulate their interaction. If it is not to convince SR people more easily, then you probably have a more fundamental reason to do so. Do you?

Lots of people call quarks fundamental too, but when antimatter meets matter, pouf! They all turn to radiation. Same thing happens when an electron meets a positron - instant conversion to components.
I can't consider light as a component because I wouldn't be able to differentiate it from sources of light in my explanation. My massive particles are nothing more than bonded sources of light that divide into smaller bonded sources of light indefinitely, so if we could shut off the exchange of light between the quarks for instance, we might also suddenly see the light the atoms were already exchanging, but the components of the quarks would still go on exchanging some, so the whole mass of the system would not transform in to light, and it would never do if the microscopic universe is infinitely small. I wonder what an antistep could look like on the screen? :0)

Quote from: Le Repteux
    When particles are on constant motion, when no acceleration happens to them, they then go on making steps that are perfectly synchronized.
That doesn't really work though, because if you teleport one of them to increase or reduce the separation, they continue to be "synchronized", so it has no control over the distance between them.
Theoretically, electrons spontaneously get back to their minimum energy level when they get bumped to another one, and the same thing should happen to the steps: whenever they change nodes during an interaction, they should spontaneously get back to the better one. Of course, they get out of sync during the process, reason why some light escapes from the system, and it is the same for electrons, they do not radiate either when they stand at the right energy level, only when they get back from being bumped. That spontaneous behavior might more easily be studied with the steps than with the electron theory though: an electron cannot rely on its components to produce its behavior, whereas the steps can.

all the energy that's in there is bound together such that it doesn't just break up and turn to radiation flying off at c in different directions.
Suggesting that energy binds to energy doesn't explain why it may do so. That's what happens when we assimilate energy to mass without providing a real mechanism for mass, which is precisely why I prefer the small steps to the Higgs. With the small steps, the energy the particles exchange is just information, and it produces their motion the same way the information we exchange produces our own motion, in such a way that if some energy goes by the particles without producing their motion, it means that they didn't perceive it, exactly as when we didn't understand a comment even if we read it. To produce motion, matter and information must already be on the same wavelength.
 
I'm glad you found this stuff - it may open some doors for me into an area I've avoided because I don't want to get bogged down in the complexities of small-scale physics, but I've seen something now which might just hook me in (because it may not be as time-consuming as I was expecting, and that means it might not get in the way of my work).
Have fun! Lafresnière made a really nice job. Too bad he isn't here to discuss with us though. When I decided to contact him a few years ago, I waited for his response a few months before discovering he was dead. At that time, I didn't know about Ivanhov's work, but he did, so he would have known what I was trying to do. Of course, he is one of those stubborn LET fans. :0)
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 17/08/2018 22:19:52
Time stops flowing for a light clock that gets at the speed of light with regard to ether, so a photon can't experiment time. The time a photon takes is not measured with regard to itself, it is measured with regard to a clock made out of matter, and the distance itself also needs to be delimited by matter. You seem to be assimilating matter to energy to light, and I can't, otherwise I couldn't simulate their interaction. If it is not to convince SR people more easily, then you probably have a more fundamental reason to do so. Do you?

When light's moving at full speed, that movement is its entire functionality. By going slower, it's able to do other things than just move, so a different kind of functionality comes into play (such as interactions with things or being tied up in matter), but it always has full functionality when you add all the component functionalities together (ignoring the slowing caused by gravity, although even then it may still be functioning at full speed and just taking longer to fight its way through a given distance in space). A photon's functionality is the same in a stationary light clock as it is in a moving one - both are racing along at full speed, and that does not equate to being frozen and motionless. A photon travelling across the universe for billions of years runs (it is functioning and its movement is that function) for billions of years rather than the zero time that could be claimed for it. It is the other kind of functionality that is slowed by movement, because more functionality has to be handed over to movement through space. Previously when I've talked about movement slowing functionality, I have only been referring to one kind of functionality. The other kind of functionality is movement itself, and the amount of each kind of functionality displayed by an object is either 100% one, 100% the other, or a mixture of both, always adding up to 100%.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 18/08/2018 16:11:20
Light is the ultimate frontier. To study it directly, we would need a faster than light device and we don't. I thus decided not to study it and to simply consider the particles as sources of waves instead. I think that Lafresnière would like the way you consider light though, because his electron is made out of it even if it doesn't move at c.

At first, I thought I might be able to explain the particulate properties of light with the steps since they explain mass which belongs to particles, but I didn't succeed yet. At the particles' scale, light is studied for its energetic properties, not for its informative ones even if, at our scale, we use it constantly to measure speed and distance, an information that we then use to move properly. The idea that particles may also be able to measure speed and distance and to also use that information to move properly is new, and it restricts the way particles may be interacting, so I find it promising. Remains to find a convincing way to simulate it.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 21/08/2018 16:01:37
Some more thoughts.

On one of the first simulations I made, the left particle stopped moving after having been forced to make a step forward, and it made another one only when the photon from the step of the right particle was back. If the acceleration was stronger, then the step was simply stretching. I discarded that simulation when I realized that the longest step the particles could make was equal to the distance between them, which meant that the fastest the system could go was at half the speed of the photon. For the speed to get closer to c, the steps would have to bypass the other particle like our feet do when we walk, and I didn't study that possibility yet. Of course, that system wasn't generating any contraction at acceleration, and reversing the direction of acceleration meant contracting the steps so that they would get smaller each time the photon would strike a particle, which is closer to what we should be able to get in a simulation. In that system, it is the steps that stretch or contract depending on the direction of acceleration, not the distance between the particles, so I now realize that, in my last simulation, if the steps were contracting the same way the distance between the particles is contracting, the two contractions would interfere. Now if I would use an equation to simulate the contraction between the particles, I would also have to apply it to the steps, so the two contractions would also interfere. In fact, both the time dilation and the contraction would interfere.

The experiment Ivanhov made shows that contraction happens in a moving system that is bound by a standing wave, so he could have put a small motor on one of the sound emitters, and program it to move to get to the closest node, and it would have moved to stay on it when the speed of the wind would have changed. Since it works for real wind, it should also work for a simulated one, so moving the screen with regard to my particles instead of accelerating them should also contract the distance between them if the way my particles are bonded is similar to a standing wave. To simulate that, I could use two photons that would hit the two particles at the same time when they are at rest, and they would take more time to reach the particles when I would move the screen because they would have to travel more distance in a roundtrip.

That motion is easier to imagine if we move the screen sideways to the alignment of the particles though, so lets analyze this possibility first. As with the vertical arm of an MM experiment, the photons would be aimed at an angle and would take more time to reach the particles, so unless those particles would suffer time dilation, the distance between them would have to contract for them to stay on sync. That's what Ivanhof observed with sound, so he concluded that vertical contraction would also happen to particles, but sound doesn't produce time dilation inside the emitters the way light would do inside the particles otherwise he would also have observed a redshift of the two emitters, so he might be wrong about applying his observed vertical contraction to light because such a redshift would simply stretch the contraction.

Now, let's analyze the aligned system. Moving the screen to the left is similar to moving the particles to the right, and if we do so with an aligned system, a photon will take more time going right than going left, thus losing some time going right and recover some going left, but still taking more time overall than at rest, so it would also get out of sync overall unless the left particle also suffers time dilation, what it should effectively do, and at the same rate the system would do, so the synchronization should not be affected. Contraction is more difficult to imagine in this case, but we know that it reduces time dilation a bit for the MM experiment to give a null result, so it should not affect the timing either since it would be the same whether it would happen inside a particle or between two particles. Ivanhov showed that contraction happened to the nodes when the two waves of his sound standing wave had two different lengths, but he didn't account for the time dilation of his emitters, which should happen in the case of light whatever the alignment of the particles, so again, redshifting the two waves while speed increases should prevent my two inline particles to suffer any contraction of their standing wave.

Ivanhov made a few mistakes in his paper, but I still think he is right about light producing motion. His fundamental mistake is thinking he will be able to move two bonded EM oscillators the same way he moves macroscopic oscillators by simply varying the two wavelengths at will. He would need a faster than light device to synchronize that system and he doesn't have it.


 
 
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 16/09/2018 23:27:11
We're going to need to try to replicate LaFreniere's work to see if his standing waves actually stand up, but I've yet to find an explanation of exactly what he was doing to get them. Was he using a fourth dimension for the space fabric to vibrate in? His numbers are so good though that I have a hunch that he was on the right lines, and I also have high hopes for him just because he absolutely nailed all the points he made about LET, 100% - he really knew what he was talking about there (which is very rare), and the same likely applies to the rest of his claims.

If the space fabric is able to vibrate in a fourth dimension (available to the fabric but which we don't notice from the inside), it would have to be able to vibrate at very high speeds, but the more energy or mass you stick into a small space, the greater that sideways movement (within the 4th dimension) would need to be, and that would surely lead to delays to the action - I can even see a possibility there for length-contraction in that fourth dimension affecting this movement more and more as the energy density goes up, and to a corresponding slowing of the speed of light through the fabric there, which is all that's needed to account for gravity when all matter is made out of waves. This could lead to a complete mechanistic account of physics, and it depends squarely on the aether for that functionality. No one who is working without a vibrating space fabric is going to find this, so it would be no surprise if this route hasn't been adequately explored. LaFreniere's work was simply ignored by everyone on the basis that it involved an aether and must therefore be a nutter, and sadly you didn't discover his work during his lifetime. He may actually have been one of the greatest physicists of all time, but he got no recognition for his work.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 17/09/2018 16:01:32
We're going to need to try to replicate LaFreniere's work to see if his standing waves actually stand up, but I've yet to find an explanation of exactly what he was doing to get them. Was he using a fourth dimension for the space fabric to vibrate in?
I'm glad you like his work. It's close to my small steps. As I already said though, standing waves need two emitters and he only has one. He uses a round ring to produce convergent waves on water, and he puts many light sources in circle in his software to produce the same waves. Those waves meet at the center and become divergent, what produces a standing wave when they meet the convergent ones. His simulations are so beautiful and he is so convinced it's an electron that we tend to forget about the way he produces his convergent waves. I played with Delmotte's software (http://mildred.github.io/glafreniere/programmes/ws2Dv33b.rar) a bit. Its impressive and fun, but we can't move the sources individually, and we can't use doppler effect as a force carrier either, so as it is, I can't reproduce my small steps. I tried to find Delmotte or Marcotte on google without success. Lafrenière often talks about them, but he doesn't give us any link.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 17/09/2018 20:29:29
That's the big problem with his ideas - the waves would simply radiated outwards and not be replaced, so all his particles would evaporate, unless some way can be found to bounce the waves back (which could happen if energy is digital and there isn't enough of it to send onwards once it's spread out too much), but if you do that, you don't have any waves spreading far enough out to control interactions with other particles, or at least, not beyond a certain distance. If the particle accelerates, any bounced waves are going to miss the centre too, so how would it be maintained? (And the further out the waves go before bouncing back, the bigger that problem becomes.) However, if any significant amount of his work stands up (and he's very sure about his numbers), it may not be a coincidence. There must be some way of looking at this that will add up completely, and he may have been close to it. Some day, someone's going to make a leap of the imagination that will lead to the solution, and exploring this may be the route to get there. Also, anything that sparks off new ideas is useful, and I'm getting some from this.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 19/09/2018 18:43:20
When Lafrenière glorifies Ivanhov's wave, he is a lot closer to my small steps. I finally succeeded to open the coding of Delmotte's software. It's written in basic language and I know nothing about it. It's quite long too. I wanted to know how he codes his doppler effect but I'm afraid I won't be able without help. He gives his email address at the beginning of the page so I'll try to reach him. Here is the coding on a .pdf file.
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 19/09/2018 22:06:40
Code without comments through it to explain what it does is not intended to be understood, but it doesn't matter. I'd rather just write a new code and work out all the details for myself, but I don't have time to do anything that complex at the moment anyway. I really just want to test his phase shift finding.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 13/10/2018 21:04:18
@David Cooper

Good news, Delmotte answered me, bad news, he says he's gonna wait till he is retired to get back working on the standing wave project. He plans to modify his doppler effect algorithm so as to create solitons (https://en.wikipedia.org/wiki/Soliton) traveling in ether, what he finds quite difficult to do, but with the Holy Grail as a reward if he succeeds. For those who would like to reach him, his address is delmottephilippe@yahoo.fr

Now about my simulation on acceleration where contraction never reverses. As I said, if I accounted for the contraction suffered by the particles themselves while time and distance are also contracting between them, the two contraction levels would interfere. From the particles' viewpoint, there would be no observable time or length contraction, while there would be for an external particle that would not have suffered the same acceleration. Notice that, contrary to Relativity, this kind of contraction would be absolute since acceleration is absolute. It would thus also happen to rotating particles since rotation produces their acceleration towards one another, and to particles that are aligned perpendicularly to the acceleration if they need to stay synchronized, as it is the case for my simulation with four accelerated particles. (http://www.motionsimulations.com/Acceleration%20with%20four%20particles)

Since it is established that the universe works the same everywhere, let's admit that very distant particles suffer almost the same overall acceleration than laboratory ones, thus the same contraction. Then, since their light takes time to reach us, and if we consider that light doesn't change wavelengths while traveling, they should look redshifted since the particles we use as a reference in the lab had time to contract during that time, and that's precisely what distant galaxies show. Now, if we use doppler effect as a means to keep the particles on sync like I do in my simulations, then we get that they should accelerate towards one another to stay on sync since they would all appear redshifted to one another, and that's precisely what gravitation is about. Why try to stay on Relativity's footsteps when we expect so many huge leaps for the price of only one divergent small step? :0)

 

Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 13/10/2018 23:36:23
Good news, Delmotte answered me, bad news, he says he's gonna wait till he is retired to get back working on the standing wave project.

It's good news that he's still interested in it, and that he's still around. I'm not going to write any software for doing anything similar though until I've made better tools (namely AGI) - that's the quicker route to getting things done.

Quote
Now about my simulation on acceleration where contraction never reverses.

If you accelerate an object and it contracts, then decelerate it and it contracts further or fails to extend back towards the original length, it isn't behaving like the real universe, so don't build too much upon it.

I've been thinking a lot about gravity in relation to black holes over the last couple of months. If a black hole moves, any light that's trying to enter it from ahead will slow down and get stuck just outside the event horizon, but as the black hole's moving, that light may actually be pushed backwards through the aether, which adds a layer of complexity to its interactions with aether. Whatever it is that slows light in the presence of high concentrations of matter/energy (and which by doing so creates gravity), that slowing of the speed of light must be relative to that matter/energy rather than relative to the aether. Light is being slowed by a medium, and that medium is usually moving through the aether. That medium may be an extension of matter/energy that manifests itself in a similar form to dark matter - it's spread out far from the part of the matter that we can see directly. It must length-contract when the matter's moving. It cannot be an extension of waves from the matter in the middle where that matter's functionality is frozen - there is nothing coming out from a black hole to make things orbit it, so there has to be an extended part of the matter that's stuck in or at the edge of a black hole, this extended part never being sucked down there, but remaining far above, slowing light and doing so more strongly closer to the central part of that matter. Either that, or it's something displaced from the Aether, pushed aside by matter - something that sits in aether everywhere but which is pushed out and into higher concentrations when matter or energy is introduced, leading to a slowed speed of light where those higher concentrations are. I'm currently trying to work out how they could length-contract though if they aren't themselves moving along at the same speed as the matter, which leads me to think that they are more likely a dark part of the matter itself.
Title: Re: How can I write a computer simulation to test my theory
Post by: Le Repteux on 14/10/2018 16:11:08
If you accelerate an object and it contracts, then decelerate it and it contracts further or fails to extend back towards the original length, it isn't behaving like the real universe, so don't build too much upon it.
Unless I find a better way to simulate acceleration between my two particles, I need to rely on the one I got, and the idea that acceleration is absolute seems to support it, because it may mean that contraction also is. For the moment, I'm still studying the two ideas, but if I don't find a way to simulate the relativistic contraction, I might let it down. That contraction is needed to explain the MM experiment, and readers may not have noticed, but my simulation with four particles (http://www.motionsimulations.com/Acceleration%20with%20four%20particles) is such an experiment. It is a simulated interferometer that we can accelerate to give it speed, and while it contracts in the direction it is moving, it also contracts in the transverse direction for the vertical light to stay on sync with the horizontal one. No need for the relativistic contraction to explain the null result then. The contraction goes on at all scales, which means it is only observable between scales, and the speed is conserved even if the acceleration stops, which is what we observe.

there is nothing coming out from a black hole to make things orbit it,
It means that we can't simulate a black hole. I never believed in curved space precisely because of that. I prefer to think that particles exchange an information that we can't detect, the same way we can't detect our own motion through space even if, as in my simulations, particles must probably exchange some information to keep on moving. To me, that curved space stuff is illogical, but intelligent people succeed to believe in god, so why not in curved space? Some information has to tell space to curve, and nothing can escape from a black hole, so it simply couldn't curve its own space even if other bodies could. If black holes exist, they simply can't produce any gravitation. Curved space is a dead end idea, the same kind of dead end the idea of god creates: it prevents us from thinking. For the moment, nothing shows that our universe contains dead ends, on the contrary, all the discoveries we make finally exhibit unsuspected phenomenon. As religious ideas show, we can build any idea over a dead end one and it will always work, so what's their use apart providing us with a false security feeling?

That medium may be an extension of matter/energy that manifests itself in a similar form to dark matter - it's spread out far from the part of the matter that we can see directly.
Dark matter is a good example of an idea built over a dead end one. If matter can curve the space around it without sending any information, then why not invent an unobservable matter when space doesn't seem to curve the right way? There is no way to study the phenomenon anyway, so why hesitate? Need a bit of dark matter too to explain some divergent curved light? No problem, how much you need? Need it to explain miracles? Here you go, enjoy yourself!
Title: Re: How can I write a computer simulation to test my theory
Post by: David Cooper on 14/10/2018 21:11:48
If black holes exist, they simply can't produce any gravitation.

But they clearly do - the gravity waves from black holes merging have proved the case. They exist and their gravity is very powerful indeed.

Quote
Curved space is a dead end idea

It's an explanation generated by a broken theory, so we can be sure that it's wrong. The same facts can be accounted for without any curvature simply by having a slowing of the speed of light, eventually reaching zero at the event horizon of a black hole relative to the black hole.

Quote
Dark matter is a good example of an idea built over a dead end one. If matter can curve the space around it without sending any information, then why not invent an unobservable matter when space doesn't seem to curve the right way? There is no way to study the phenomenon anyway, so why hesitate? Need a bit of dark matter too to explain some divergent curved light? No problem, how much you need? Need it to explain miracles? Here you go, enjoy yourself!

Something slows light far out from the visible matter that we think is responsible, so how does it do that? There has to be something there that actively causes light to slow. I think there's a dark component of matter that does this job at all distances out from the visible part, but obviously with more of it closer to the visible part in the middle. This is quite in addition to the dark matter that may or may not exist in galaxies to cause the outer parts in some cases to orbit at a higher speed than material further in.