[Le Repteux (OP)]

The important part was: "That means the final part has to be used as the mechanism for length contraction, dictating the shapes of particles in the same way it dictates the shapes of orbits." If you want a simulation to explain the cause length contraction, it has to include the mechanism of length contraction and not simply apply a length-contraction formula to generate it. The whole point is that you would need to provide correct length contraction without a formula for it, making it appear out of other mechanisms that are already accepted in physics.

For the moment, I have to take for granted that the contraction happening at the components' scale during acceleration would slow down the rate of the contraction I get at the particles' one. I could make a simplified simulation to test that possibility, but I need to solve the problem of reversing the contraction first. I didn't succeed to add the relativistic equation to my simulation on opposite acceleration yet, so the suspense is still running. :0)

[Le Repteux (OP)]

The suspense is off, and I got some good news.

To observe the way the acceleration between the components would affect the acceleration between the particles, I added that feature to my first simulation on acceleration between two particles. As expected, the rate of contraction due to a particle accelerating before the other began to decrease, but after a while, the distance stopped contracting and began stretching instead. In that simulation, the contraction produced at one scale was used to decrease the one produced at the other scale and vice-versa, so that when contraction switched to stretching at both scales, stretching was all of a sudden used to increase stretching. I wished that the rate of contraction would only have gotten smaller and smaller with time, thus getting closer and closer to 1, because this way, reversing the acceleration wouldn't have changed anything, but it didn't, and I didn't find how it could naturally do that, so I decided to switch to another idea I had during the time I was trying this out.
      
This time, the distance between the particles doesn't contract because the first particle accelerates before the second one, but only because it makes its step before the second one. The particles make a step when the photon strikes them, then wait until it is back before making another one. If acceleration is on, the length of the step increases, otherwise it stays the same. They make an instant step on the screen because it is easier to program, but in reality, they should move at constant speed until the photon strikes them. That's why, if we observe the action in slow motion, the photon seems to be left behind by the red particle, and why it seems to leave the green one before it has made its step. In reality, a photon starts to be emitted when an incoming one strikes a particle, and it is being emitted all along the step the particle makes. It is thus shortened by the motion of the red particle towards the green one, and stretched by the motion of the green particle away from the red one. I will try to simulate the whole photon later on, but meanwhile, we may consider that the yellow dot is only its front end.
      
The rest of the explanation is on the simulation's page.

[David Cooper]

You should add a read-out of the speed too. What speed are they collectively doing at the point when when the red particle switches over to being ahead of the green one (on average)? Is that them reaching c?

[Le Repteux (OP)]

I'll add the speed of the system to the display, meanwhile here is my answer to your question. At the moment the red particle would step at the place where the green one is, it would have effectively reached the speed of the photon, but it can't do so if two particles cannot be at the same place at the same time. Before getting there though, it has to overcome the increasing resistance. While its step increases in length, it produces more and more blueshift on the light from the green one, so it resists more and more to its acceleration and it takes more and more force to accelerate it. I'm only studying the case where the particles are held inline, but if they were free to rotate around one another, then they would sometimes be traveling sideways to the motion, and the acceleration would only affect the steps between their components. The resistance would get down a bit during that time, because there would be no more blueshift from the other particle to overcome, but just a tiny bit since there is a lot more resistance at the scale of the components than at the scale of the particles. With the steps as a mechanism for mass, that tiny mass difference is precisely what we call the loss of mass due to bonding.

[Le Repteux (OP)]

Happy new year everybody!

I'm slow, but I finally succeeded to do what I needed to do with that new way to move my particles. I first added the speed of the system to my simulation with two particles, then I added that new kind of steps to my simulation on opposite accelerations and to my simulation with four particles. The system doesn't contract in the direction of motion anymore, so reversing the acceleration is no problem, but the time does, and it still contradicts SR. As expected though, the vertical arm of my simulation with four particles also contracts, so the vertical and the horizontal light clocks still stay on sync all the time, and the result of the MM experiment is respected. The result of the twins paradox mind experiment is not though: it would simply be the contrary. More explanations on the simulations pages. Have fun and give me some feedback! :0)

[David Cooper]

Happy new year everybody!

HNY 2U2.

Thanks for adding the speed to the first of those programs - it makes it a lot easier to understand. Your second link's program has a display problem (on my machine, at least) with the numbers being written on top of or through the text, so I can't make them out. Your third link is to the same program again instead of to the 4 particle program that you intended to link to.

[Le Repteux (OP)]

Hi David,

I corrected the link and changed the display. I hope its ok for you now. I tried it on three browsers (edge, chrome and firefox) and it looks fine.

[David Cooper]

I corrected the link and changed the display. I hope its ok for you now. I tried it on three browsers (edge, chrome and firefox) and it looks fine.

That's better - it works now. I don't understand this time contraction thing that you're doing though. How are you going to get the cycle times to increase for higher speeds of travel when you have them going down instead?

[WarnerGet]

The wiki article is misleading. It says...It would assume that more matter is needed that what is present however, dark matter particles is not the only theory that is capable of explaining the strange phenomenon. I

[Le Repteux (OP)]

How are you going to get the cycle times to increase for higher speeds of travel when you have them going down instead?

As we can see, with this kind of steps, the time light takes between two horizontal particles contracts with speed instead of dilating, but for a light clock at our scale, the story is different. The light exchanged between two mirrors is not strong enough to bond them, so they cannot move by steps, but their atoms still could. With that kind of steps, time would at the same time be dilating at our scale and contracting at the scale of particles. I think that there is no problem with such a result as long as the result of the MM experiment would be the same, and I think it would. As I say in the explanations of my simulation with four particles, an interferometer is meant to measure a phase shift between two identical copies of the same photon (or the same photons' front), and the photons themselves cannot change phases while they are traveling between the mirrors, so if the atoms of the mirrors do not change either the phases of their steps, what they can't do if they are not accelerated, the photons should stay on sync with the steps all the time, and there should not be any phase shift at the end. As my simulation shows though, for the vertical photon to stay on sync with the horizontal one while speed increases, the system has to contract vertically, and if it did, the vertical arm of the interferometer would also contract, what seems to worsen the problem because with SR, it is the horizontal arm that contracts, but I think it doesn't. If the space between the mirrors was filled with a clear crystal for instance, a photon sent vertically through the crystal would follow the same path all the photons bonding its atoms would follow, and it would automatically be on sync with the steps all along the crystal since the photons bonding its atoms would be, so there would be no phase shift to observe at the mirrors. If the game the particles are playing is really synchronisation, the result of the MM experiment is not surprising.

[David Cooper]

The wiki article is misleading. It says...It would assume that more matter is needed that what is present however, dark matter particles is not the only theory that is capable of explaining the strange phenomenon. I

That looks incomplete, perhaps posted in error. Might it have been intended for a different thread?

[David Cooper]

As we can see, with this kind of steps, the time light takes between two horizontal particles contracts with speed instead of dilating, but for a light clock at our scale, the story is different. The light exchanged between two mirrors is not strong enough to bond them, so they cannot move by steps, but their atoms still could. With that kind of steps, time would at the same time be dilating at our scale and contracting at the scale of particles.

If the two mirrors are connected by a rod (or arm), there is a chain of particles all the way from one mirror to the other, so if the round trips for light between any two adjacent particles is going down, I can't see how the round-trip time can do anything other than go down for the trip between the mirrors too.

[Le Repteux (OP)]

That part of the mechanism is hard to imagine. In a solid, while half of the atoms would be making a step, the other half would be waiting for the photon from that step to come in before making theirs, so half the photons would be going one way while the other half would be going the other way later on. If we would send an independent photon through the solid, it would not have to produce any step, it would move directly to the mirror while the other photons would be going both ways, so unless the rod is only a few atoms long, I think that we can consider its motion as constant with regard to the motion of light, which means that the time it would take between the mirrors would be the same as with SR. It might take a simulation to be sure though, so if you think it's worth it, I'll make one.

[David Cooper]

It might take a simulation to be sure though, so if you think it's worth it, I'll make one.

I still can't picture it, but a drawing should be sufficient to illustrate things and wouldn't be so costly in time.

[Le Repteux (OP)]

Here is a drawing that shows how the atoms of a rod would execute their steps once the acceleration would have stopped. As we can see, the rod never shortens as much as a unique step does, and it is that length shortening that would shorten the roundtrip time of the photon between the atoms, so I think that the roundtrip time of a loose photon through the whole rod would be about the same as with SR.

Tige avec pas.png (29.52 kB . 914x495 - viewed 4081 times)

[David Cooper]

Okay, so you have each blue particle bonded to the red one to its right (let's call that a BR pair), but you should also have each red particle bonded to the blue particle to its right (which we can call an RB pair). Your simulation shows only the BR pair interactions. What would happen if you simulated the RB pair simulations instead?

[Le Repteux (OP)]

In this simulation, the blue atoms are moving towards the red ones and the red ones are moving away from the blue ones just because it is a blue atom that has been accelerated first. If we take the left blue atom away, it is the next red atom that will be accelerated first and once the last atom will have made its step, all the red atoms will be moving towards the blue ones and vice-versa. To simulate the way the acceleration progresses through the atoms, we can use four fingers, two from each hand, put them one inch apart from one another on a table, and move the left one one step to the right. After three steps, the four fingers are moving as in my drawing, the first and the third finger moving on sync, and the second and the fourth waiting for their turn. Now if we would send a photon back and forth through that system, its timing would be affected by the system's temporary contraction because there is only four atoms, but the more the atoms, the less the contraction, and the less the photon's timing would be affected. That timing discrepancy between scales looks like a statistical quantum effect where it is the inverse of randomness that would be involved. I still think that randomness could affect acceleration though. I think that a particle cannot know in advance the result of an acceleration the same way a specie does not know in advance how to adapt to a change in its environment. Species are forced to use random trials that we call mutations, so I think that particles could also be forced to use random steps before succeeding to adapt to the direction and the speed they are getting accelerated, a feature that would affect their resistance to acceleration, thus their mass.

[David Cooper]

Maybe I'm imagining a problem that isn't there. With particles jumping in the way you allow them to, they're able to move faster than c (and move infinitely fast), so you may indeed be able to reduce round-trip times for light moving between each pair of particles due to those jumps. It's clear though that you need better programming tools if you're going to make real progress with this, and I'm working on building some - I'm getting useful ideas just from seeing what you're trying to do.

[Le Repteux (OP)]

I let the particles make instantaneous steps on the screen only because it is easier to see the steps this way, and also because it is a lot easier to program, but in reality, those steps should have a sinusoidal shape driven by the components' steps: they should start at zero speed, increase to a top speed in the middle, and get back to zero speed at the end. I could have given them a mean speed instead of a sinusoidal one, but we wouldn't have seen them anymore.

It may effectively help to be able to build more precise simulations to show the sinusoidal steps, but if I compare them to the kite I invented, we probably don't need to be that precise in the beginning to get a model that works. Using a computer to design my kite only helped to refine the shape and to digitalize the templates' cutting operation. At the time, I didn't know how to handle "Autocad" anyway, but I would certainly have used it if I had known. It could also have been interesting to put the digital model in a wind tunnel simulator, but we didn't go that far. How is your programming software going? Is it close to be operational? When will we be able to give you some feedback about it? Aren't you anxious to get some?

[David Cooper]

I let the particles make instantaneous steps on the screen only because it is easier to see the steps this way, and also because it is a lot easier to program, but in reality, those steps should have a sinusoidal shape driven by the components' steps: they should start at zero speed, increase to a top speed in the middle, and get back to zero speed at the end. I could have given them a mean speed instead of a sinusoidal one, but we wouldn't have seen them anymore.

The biggest problem here is the inadequacy of the programming tools - it takes far too long to write code to do simple things. What's needed is an intelligent programming system with a built-in mathematician which can write most of the code for you, and that's exactly what I'm trying to build (by creating a system that can learn by itself and gradually become a mathematician).

How is your programming software going? Is it close to be operational? When will we be able to give you some feedback about it? Aren't you anxious to get some?

I have a rudimentary natural language programming capability (with a very limited vocabulary, but with the capacity to extend it to the whole of language without writing any more program code to handle it), but I've been stuck for a while with working out how to integrate it with graphics in order to produce a clear demo of it in action. I've ended up inventing a new way of doing graphics which involves defining 3D shapes in a way that ties in neatly with the requirements of machine vision. (I recently spent ten days straight staring at a toy squirrel while working out all the details of this system.) I now know how to produce virtual objects with the capability to stretch and move in natural ways governed by the laws of physics and capable of being controlled by applying virtual power to move joints in any directions that muscles make them do in the real animal/person, while each part of the body is acted on by proper laws of physics such that a fall or collision should send it spinning and sprawling in a completely realistic way. (One of the things I want to do with this is get the system to learn to make these things stand, walk, run and jump just by finding the best way to apply the minimum power to the available controls to achieve specific goals, and it should all transfer directly across into real-world robotics.) I still haven't done any work on handling waves (of any kind), so that's what I want to think about next - it may need a completely different system to handle the kinds of simulation that LaFrenière was working on because so much depends on waves of the medium rather than the content, and I'm still trying to visualise the right way of handling that.

My immediate priority is to get that demo up and running though so that people can see directly that the system works without having to study lots of data on a screen covered in numbers. The idea is that the user will be able to say to the computer (by typing words in), "Make a ball. Bigger. Make it red. Give it a pattern. Rotate it. Change the axis of rotation. Make another ball. Make it blue. Put it over the first ball. Move the red ball to the right. No - make it move continually to the right. When it goes off the side of the screen, make it come back in at the opposite side. Move the blue ball downwards. When it goes off the bottom of the screen, make it come back in at the top. Move the red ball more quickly. Rotate the blue ball. Opposite way. Faster. If they collide, make them bounce off each other and have the impact adjust their spin." Most of this is direct instruction, but the same kinds of instructions can be used to build programs. Some parts of this are already programs: "if the ball goes off the side of the screen, etc." - this becomes a program thread that continually checks to see if that condition is met. There are also program threads that repeat their action to keep something moving - these are different from single use instructions which might move an object once and then never have to act again. You may be able to imagine how this system will speed up the production of the kinds of simulation that you've been working on - the tedious stuff will all be done automatically for you and you won't have to spend most of your time fighting to get round the limitations of an unintelligent system. With natural language programming, you want to be able to point at a dot and say "that particle" or just say "the dot inside the circle" instead of having to know its name. The intelligent system should understand what the program is doing and not just run it blind, but for that you have to take it beyond natural language programming and towards AGI. I've had to redesign a lot of components in order to integrate the two things (NLP and AGI) in the most efficient way. All the instructions mentioned in this paragraph will be in the demo.