[Le Repteux (OP)]

Hi Everybody!

I asked David Cooper 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)

[David Cooper]

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.

[Le Repteux (OP)]

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
*/

[David Cooper]

I copied the java text

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

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

[Le Repteux (OP)]

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.

[David Cooper]

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.

[David Cooper]

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.

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.

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

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.

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.

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.

[Le Repteux (OP)]

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

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.

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.

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.

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.

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.

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.

[David Cooper]

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

[Le Repteux (OP)]

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!

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?

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.

[chris]

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";
?>

[David Cooper]

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.

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.

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.

[mrsmith2211]

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?

[Le Repteux (OP)]

Hi Mrsmith,

The model I want to simulate is described here. 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.

[Le Repteux (OP)]

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.

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.

[David Cooper]

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.

[David Cooper]

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.

[Le Repteux (OP)]

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.

[David Cooper]

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.

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.

[Le Repteux (OP)]

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.