[Le Repteux (OP)]

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
Acceleration with four particles

I will comment later on.

Merry Christmas everyone.

[Le Repteux (OP)]

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.

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

[David Cooper]

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.

[Le Repteux (OP)]

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

[Colin2B]

I fell on a an unexpected information about that principle on PF. 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.

[Le Repteux (OP)]

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.

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

[Colin2B]

Happy to have a look at your simulations, but I find the blue on black text hard to read on ipad.

[Le Repteux (OP)]

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.

[Le Repteux (OP)]

Hi Collin,

I changed the colors. Tell me if you can read the text more easily.

[Colin2B]

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.

[Le Repteux (OP)]

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 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 while letting things contract at their own rate, and as you can see, it also gives a null result. Surprising isn't it?

[David Cooper]

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.

[Le Repteux (OP)]

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)

[David Cooper]

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.

[Le Repteux (OP)]

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

[David Cooper]

The way my simulation on acceleration 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.

(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]).

[Le Repteux (OP)]

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!

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?

[David Cooper]

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.

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.

[Le Repteux (OP)]

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 .

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.

[David Cooper]

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.

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.

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.

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.

For those who are skeptical, have a look at that one for a speed of .7027c and a contraction of .5 .

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.