[Bored chemist]

OK, these are those nice clocks you find in thought experiments.
You can synchronise them however you like, including the button on the top.
If they are next to each other  then here's an amusing way to do it.
Turn one of the clocks upside down.
Press its button down on the button of the other clock.
Since both presses are the same event they are necessarily synchronised exactly.

Try doing that with three clocks, but you've also got the problem that the buttons probably won't "fire" simultaneously, so you're really going to have to smash the clocks together hard to minimise the error.

It's a thought experiment we don't worry about irrelevant issues like whether my reflexes are good enough to press two buttons in a tenth of a second or what.

Then stop obsessing about it - the reason I spelt out a reasonable method was to attempt to ward off any ridiculous diversions of the kind that have subsequently been taken.

Because the two clocks are next to each other it's perfectly simple to synchronise them. Relativity doesn't have any problems with "at the same time" for things that are "in the same place".

You're repeating what I've already said.

Now, do you see that my "awful" synchronisation method is (at the time when I'm synchronising them)  actually mathematically perfect?
You can see how no observer anywhere in the universe, regardless of their speed, acceleration of local gravity will ever see the two clocks -just after I push both buttons in the same place and at the same time- as being anything other than synchronised?

That's not the part of the synchronisation process that I'm calling awful. The awful part is when you move one of them somewhere else and it's movement slows it and leads to its timing lagging by a different amount depending on how quickly you relocated it.

That's why I choose to set the clocks running at zero in the same place and at the same time.
From the point of view of nearly everybody else in the universe, your "synchronised clocks" are ( or at least may be) never  in step because they are separate in space.
With my approach, once we have two clocks that at least start out  together we can run the experiment where we know how far out of synch the clocks are (because we can calculate it from the way in which we moved one of them).
And we can minimise that change.

There are better methods where you don't have to worry about extra errors creeping in from the way you accelerate and decelerate your moving clock, plus complications from little wanders off a straight path vertically and horizontally. You can simply send a flash of light.

We can make it as small as we like (by moving them a  short distance and/ or slowly).

Which you don't need to do as you still have to make a correction, so you might as well make a big correction and move the clock quickly.

And then we have two nearly synchronised clocks  which we can set off a flash lamp in front of and look at the delay.

And at the end of it all, when you time the delay, you get the answer c because you have synchronised clocks with the same time difference between them as with any other valid method so that they will assert the speed is c even if it's actually close to 0 or 2c.

"Try doing that with three clocks, "
As far as I can tell, the only thing you do with the 3rd clock (the one in the middle) is use it to tell you when to sync the other two.
It serves no purpose.
So, I will save myself the trouble of using 3 clocks- one of which does nothing- by just using two.
Also, if you consider an ant sat on one of the two "moving" clocks in your scenario, he sees almost exactly the scenario I use.
He sees the other clock being carried off into the distance.
However there's an important difference.
From his perspective you never synchronise the clocks.
The way I do it, everyone agrees that, when I push the two buttons the two events are simultaneous (because I use one to push the other, so it's a single event and a lack of simultaneity would require a violation of causality)

"but you've also got the problem that the buttons probably won't "fire" simultaneously,"
No, that's why I made it clear that this was a thought experiment with ideal clocks.

"Then stop obsessing about it "

I'm not. You are the one who is going on about the mechanics of pushing two buttons.

"- the reason I spelt out a reasonable method was to attempt to ward off any ridiculous diversions of the kind that have subsequently been taken."
My ant disagrees with your idea of "reasonable".
From his point of view, your "reasonable" method never actually makes the clocks read the same time.

"You're repeating what I've already said."
Well, yes and no.
I keep on pointing out that you can't meaningfully sync two clocks unless they are together- because otherwise, just about everybody else in the universe will never see the two clocks reading the same time.
 And you keep saying that you can synchronise them when they are far apart- which is "true" from one unusual point of view- you have to be half way between them.
And then you say this method - which everybody in the universe except you agrees doesn't actually make the clocks tell the same time- is better than mine where everybody does agree that they (initially) say the same time.
That's an odd use of "better".

On the subject of repeating what someone said, I cited the "2 clocks on a jet plane" fairly early in this thread. And then you post "Imagine a light clock aligned with the direction you're moving it in. If you move this clock at c, the clock will stop clicking throughout the time you're moving it because the light would have to travel faster than c in order to complete a circuit (and thereby to tick). All clocks are limited in the same way, slowed to the same extent by their movement through space."

Well, yes, I know that moving clocks makes them run slow. That's why I cited the most famous demonstration of the fact.

Why did you bother to raise it?

"That's not the part of the synchronisation process that I'm calling awful. The awful part is when you move one of them somewhere else and it's movement slows it and leads to its timing lagging by a different amount depending on how quickly you relocated it."
Well, two points there.
The synchronisation process happens with the clocks stationary (and next to each-other) which is the only way you can do it in order that everyone agrees that they are in sync.
So the " part of the synchronisation process that I'm calling awful" isn't part of the synchronisation process .

So there's the second phase where we move a clock.
"The awful part is when you move one of them somewhere else and it's movement slows it and leads to its timing lagging by a different amount depending on how quickly you relocated it."
And the bit that you steadfastly ignore is that you can easily make that error as small as you like.
Why is it that you can say "lagging by a different amount depending on how quickly you relocated it." without realising that, precisely by changing how quickly you relocate it, you can change the lag?

Why not change it to make it as near to zero as you like?
Why not change it, measure the apparent 1 way speed of light, and then extrapolate to the lag that you would get if you moved the clock at zero speed?

Also re "You can simply send a flash of light."
OK, you send a flash of light from the "middle" to start two clocks, then you send a second flash to stop them..
Either you send the second flash from the same place as you send the first- in which case you don't learn anything, or you move  between setting off the 2 flashes.
But if you move, time is distorted for you- so you no longer know "when" you are setting off the 2nd flash.
If, from this new position you looked at the 2 clocks, they would no longer be synchronised. The one near you would seem to be running fast compared to the one further away.

You have called this "better".
Do you see why I don't agree?

[dutch]

And the bit that you steadfastly ignore is that you can easily make that error as small as you like.

No... this is where you go wrong. This depends on the value of ε used and the total desynchronization for a given ε is proportional to the distance x.

If you get two clocks closer together the maximum amount of time the clocks can be out of sync by must decrease for a particular ε but then so does the total round trip time a light beam needs to go from point A to point B (to preserve the two-way speed of light). Regardless of the ε used the clocks go out of sync depending on distance x. You can see this in the Lorentz Transformation below:

t' = γ (t - v x /c²)

Decreasing x by factor a but then decreasing t by factor a preserves the velocity  x/t = v = (a x) / (a t). It doesn't matter that the total desynchronization gets smaller as x gets smaller because x gets smaller proportionally. Remember we are measuring a velocity.

You can't measure the one-way speed of light.

1) Using light to synchronize would defeat the purpose of using something else to measure the one-way speed of light (forcing a two-way measurement because you cheated when you used light).

2) Even going a micron or a nano meter in one direction gets clocks out of sync in proportion to the distance meaning you need to re-synchronize the clocks via some synchronization convention. This defeats the purpose of performing a one-way measurement. How much the clocks are out of sync depends on ε and is bounded by the verifiable two-way speed of light c.

3) Slowly transporting clocks in two directions from a central point IS equivalent to measuring the two-way speed of light and does not measure the one-way speed of light. This assumes a certain ε.

[Bored chemist]

No... this is where you go wrong.

Well, I'm copying it from David's post.
I did try to clarify this earlier, but it was ignored.

[Bored chemist]

OK, so which of these is true?

But speed between clock positions does not affect the difference in reading on the moved clock.

the only issue is how much, with faster speeds of movement pushing them out of sync by more.

[David Cooper]

"Try doing that with three clocks, "
As far as I can tell, the only thing you do with the 3rd clock (the one in the middle) is use it to tell you when to sync the other two.
It serves no purpose.

The three clocks are all set to zero. The point of using 3 clocks is to contrast two synchronisation methods - your method uses the middle clock and one of the clocks taken away from it. The alternative method which I was showing you was to take two of the clocks away from the middle one in opposite directions at the same speed and you can do away with the middle clock. With the second method there is no adjustment needed afterwards, but the real purpose of it is to show you that the end result is the same as you get from sending a signal at the speed of light from the middle to the two outer locations and use that to synchronise the clocks. I was trying to show you the equivalence of all the methods and the reason they fail to allow you to determine the one-way speed of light relative to the clocks.

"Then stop obsessing about it "

I'm not. You are the one who is going on about the mechanics of pushing two buttons.

The history of events is written this thread and it shows that you are the one obsessing by fixating on little details and taking diversions. If I add little details to avoid attacks from people who want to fasten on any imagined errors that result from incomplete description, you don't need to fixate on those details - you are free to stick to the main path and ignore anything that you consider superfluous.

I keep on pointing out that you can't meaningfully sync two clocks unless they are together- because otherwise, just about everybody else in the universe will never see the two clocks reading the same time.

There are two kinds of synchronisation involved in this discussion. Synchronisation of clocks at a single location doesn't lead to disputes about whether or not they're synchronised other than for nitpickers who want to obsess about details as to how this is done, and if I make a suggestion en passent about how I would synchronise them in this situation (by using one button rather than three), that isn't an invitation for anyone to take a ruddy great diversion over that issue by suggesting I should use a more primitive, less acccurate method for doing it and then attack me for sparking off their ridiculous diversion.

And you keep saying that you can synchronise them when they are far apart- which is "true" from one unusual point of view- you have to be half way between them.

And this synchronisation is the second type where you synchronise clocks at a distance. This is equivalent to synchronising them together and then moving them apart, which means you do not have a superior method but are merely proposing a less accurate one.

And then you say this method - which everybody in the universe except you agrees doesn't actually make the clocks tell the same time- is better than mine where everybody does agree that they (initially) say the same time.
That's an odd use of "better".

Your method of synchronising clocks (the second kind where the aim is to have them synchronised and at a distance) is more clumsy and error-prone. Your initial synchronisation (of the first kind) doesn't last after you've started to move them apart, so it's nothing to boast about - you end up with the second kind of synchronisation where the clocks aren't necessarily synchronised any more, but you're also creating extra work for yourself because you have to cancel out an additional error which gives you a lot more work to do (and which you naively wanted to do by moving one clock extremely slowly which wouldn't completely remove the error).

On the subject of repeating what someone said, I cited the "2 clocks on a jet plane" fairly early in this thread. And then you post "Imagine a light clock aligned with the direction you're moving it in. If you move this clock at c, the clock will stop clicking throughout the time you're moving it because the light would have to travel faster than c in order to complete a circuit (and thereby to tick). All clocks are limited in the same way, slowed to the same extent by their movement through space."

Well, yes, I know that moving clocks makes them run slow. That's why I cited the most famous demonstration of the fact.

I must apologise to you for misreading a reply of yours that led to that - where you wrote "then don't" I read it as "they don't".

Why did you bother to raise it?

To illustrate the equivalence between moving the clocks out and sending a signal at the speed of light and show you the futility of your attempt to measure the one-way speed of light. That is the issue in question in this thread and I am trying to help you understand why what you think can be done can't.

"That's not the part of the synchronisation process that I'm calling awful. The awful part is when you move one of them somewhere else and it's movement slows it and leads to its timing lagging by a different amount depending on how quickly you relocated it."
Well, two points there.
The synchronisation process happens with the clocks stationary (and next to each-other) which is the only way you can do it in order that everyone agrees that they are in sync.
So the " part of the synchronisation process that I'm calling awful" isn't part of the synchronisation process .

You're using a synchronisation process which starts with synchronisation of two clocks at a single location and then moves on to a second step which changes that synchronisation to create a synchronisation at a distance (which is a different kind of synchronisation because it doesn't necessarily mean they are ticking at the same time any more). And the thing that makes it most awful is that you think it's a good idea to move one of the clocks really slowly in order to minimise the extra error that you're introducing instead of just moving it fast and making a bigger correction.

And the bit that you steadfastly ignore is that you can easily make that error as small as you like.
Why is it that you can say "lagging by a different amount depending on how quickly you relocated it." without realising that, precisely by changing how quickly you relocate it, you can change the lag?

I'm fully aware that you can change the degree of lag and have told you so, but why do you want to do that when it means taking ages to set up your clocks and still leaves you with an error anyway? It's as easy to correct for a big error as a small one, so just move your clock fast.

Why not change it to make it as near to zero as you like?
Why not change it, measure the apparent 1 way speed of light, and then extrapolate to the lag that you would get if you moved the clock at zero speed?

I don't care how you want to do it - that's entirely up to you. I just want you to see the equivalence of the different methods (which is the whole point of showing you them) in the hope that you'll understand that your synchronisation will be no different apart from having extra errors added to it which you will need to adjust for.

Also re "You can simply send a flash of light."
OK, you send a flash of light from the "middle" to start two clocks, then you send a second flash to stop them..
Either you send the second flash from the same place as you send the first- in which case you don't learn anything...

The whole point is that you can't learn anything about the one-way speed of light.

You have called this "better".
Do you see why I don't agree?

Yes - I can see why you don't agree, and it's because you're still not seeing the big picture. The error that you're getting in the second kind of synchronisation can be corrected for and there is nothing to gain from moving your clock slowly other than to minimise an error that you can't be bothered adjusting for. Because you actually can be bothered adjusting for it though (because you want to do things with precision), you might as well move the clock fast and save yourself a lot of time. And if you're just doing a thought experiment, if you move two clocks the same distance at c in opposite directions you can eliminate a lot of the maths. You then realise that you can't use your clocks to determine the one-way speed of light if you do that, but you also realise that this method of synchronisation is equivalent to yours and that your way of doing things won't be able to determine the one-way speed of light either. That is all I'm trying to help you see, and looking at these other approaches should help you to get your head around why the different methods are equivalent.

There is one major point on which I may have been wrong, and that's the idea that slower movement leads to less error if you're moving one clock away from another, so I will now think it through again right here and write as I do so. If I move a clock at c a distance d in one second, that clock will lag behind the other by one second because it will stop ticking for a whole second. If I move a clock at 0.5c the same distance d in two seconds, the clock will tick at 87% of its rest ticking rate throughout the move, so it will lag the other by 2x0.13 of a second which is 0.26 of a second. In both cases the clock has moved d, but the lag is not the same. The error that dutch is talking about clearly can't be about this kind of lag (which we can adjust for), so he must be talking about the error that remains after the correction for this lag has been made, and that error (which could be a negative lag for the moved clock) applies regardless of which synchronisation method is used.

[Bored chemist]

" If I move a clock at 0.5c the same distance d in two seconds, the clock will tick at 87% of its rest ticking rate throughout the move, so it will lag the other by 2x0.13 of a second which is 0.26 of a second. In both cases the clock has moved d, but the lag is not the same."
Thanks.
Can you do that for a few more speeds and then plot a graph of "error in clock" vs speed of travel.
Then, we can extrapolate and see what the error is in the limit of zero speed.
If, as I suspect, it turns out to be zero then; for the very odd case of a very simple, slow, system, we can show that the error in the clock synchronisation is smaller than we need to worry about.
so that gives us two clocks that were synchronised and which now have a small, known phase shift. and which are separated in space which we can then use to time the arival of a flash of light as it gets to each of them.
To an arbitrary accuracy we then know the distance and the time (for this weirdly simple system.

Then we can show (fairly easily by the carts you have been putting before the horse) that it won't work in any more complex system- i.e. anywhere in the real world.

[dutch]

There is one major point on which I may have been wrong, and that's the idea that slower movement leads to less error if you're moving one clock away from another

Yes, that major point is you're assuming (without realizing it) Einstein Synchronization (ε =1/2). You can't assume Einstein Synchronization (speed of light is c in all directions) to prove the speed of light is c in all directions because that's the assumption of Einstein Synchronization. It's completely circular logic. This is especially true when there are other ε you could use which work perfectly fine and c isn't the same in all directions.

Slow clock transport (transporting a clock as slow as possible) is identical mathematically to light synchronization. Using light synchronization to measure the one-way speed of light is cheating (it's a two-way measurement)...therefore so is slow clock transportation. This is easily shown via careful analysis of a slow clock transport of a tiny light clock (light bouncing between two closely spaced mirrors).

[David Cooper]

Can you do that for a few more speeds and then plot a graph of "error in clock" vs speed of travel.
Then, we can extrapolate and see what the error is in the limit of zero speed.

I told you earlier that this lag tends to zero as you move the clock more slowly, but if you want a way of calculating it for different speeds, just use a calculator to work out the arcsine of the speed expressed in terms such that c = 1, 0.5c = 0.5, etc, (arcsine might be typed in as inv sin) then you need to work out the cosine of the result to get the rate at which the clock will tick while it's moving. You can multiply that by 100 to turn it into a percentage if that helps you understand the answer better.

If, as I suspect, it turns out to be zero then; for the very odd case of a very simple, slow, system, we can show that the error in the clock synchronisation is smaller than we need to worry about.

Yes, but it'll mean a very slow journey, and whatever speed you move the clock at, you might as well just make an adjustment to remove that lag error anyway. I go back to my system with three clocks - two of them are moved apart in opposite directions at the same speed. If they are moved extremely slowly, the amount they lag behind the middle clock will be small, and if we correct for the speed we moved the clocks out at we can eliminate that lag altogether, so we have three clocks ticking in sync with that lag completely gone. And yet they are not necessarily in sync, and it's a lot easier to explain why this should be the case if we stick to using my three clocks.

If the system is at rest and we move two of the clocks away from the middle one at the same speed in opposite directions, both are slowed. We can correct for that slowing and end up with all three clocks ticking in sync. But, what happens if the system is actually moving? If when we move the two clocks out, it's possible that the middle clock is actually moving throughout and that one of the clocks which we think we're moving away from it is actually at rest in space while we are "moving" it. The opposite clock will be moving twice as fast through space as the middle clock. What happens now is that the time dilation on the fastest moving clock is more than twice as severe as the time dilation acting on the middle clock, so we're warping the synchronisation and have one clock (the one that was stationary when we thought we were moving it) ticking ahead of the middle clock and the clock at the opposite end is ticking behind the middle clock and by a greater degree of lag. When we make the correction to the timings of the two clocks that we "moved" away from the central clock, what happens? We add the missing time back onto them, at which point we increase the lead in ticking of the clock that was already ahead of the middle clock, and we decrease the lag in ticking of the opposite end clock, and the result is that the clock that's ticking ahead of the middle clock is ahead by the same amount as the opposite end clock is ticking behind the middle clock.

No matter how slowly you move the clocks, this final error in the synchronisation will still occur and be the same size for all speeds of movement, which is why dutch says that the size of the error is proportionate to the distance the clocks are moved and not to the speed at which they are moved. He is talking about this residual error and has yet to grasp that we have been talking primarily about a greater error which can be cancelled out and which is bigger the faster you move the clocks. Most importantly though, there is no zero speed of movement for the clocks as that will not separate them, so you will have to move them at some non-zero speed, and no matter how low you make that speed, the same residual error will build up in the synchronisation.

[David Cooper]

There is one major point on which I may have been wrong, and that's the idea that slower movement leads to less error if you're moving one clock away from another

Yes, ...

No - I demonstrated that I had not been wrong on that point. Read carefully what I said in the post before this one in my latest reply to BC and then you'll hopefully be able to see that we're talking about two different kinds synchronisation error, the bigger of which comes into play when you only move one of the clocks and which is greater the faster you move that clock into place. So far, you appear to have missed the existence of this larger error.

[dutch]

No - I demonstrated that I had not been wrong on that point. Read carefully what I said in the post before this one in my latest reply to BC and then you'll hopefully be able to see that we're talking about two different kinds synchronisation error, the bigger of which comes into play when you only move one of the clocks and which is greater the faster you move that clock into place. So far, you appear to have missed the existence of this larger error.

Absolutely not. Slow clock transport and light synchronization are identical mathematically as I've said many times. I've actually shown the math on this more than once in this thread but nobody actually bothers with understanding the math I wrote...

Dependent on the original synchronization convention you may think clocks slowly transported are in sync and the total error relative to a light signal used to synchronize will be practically nil. You can even readjust for clocks transported at 50% light speed and resync because you are basing your measurement on your initial convention. This will allow for very accurate measurements of the one-way speed of light but alas ONLY based on your choice of convention. After choosing a convention time dilation doesn't add any error that can't be corrected for exactly (GPS does this all the time). To measure the one-way speed of light at all a convention must be chosen (to know the time dilation at all a convention must be chosen).

The "amount of error" is dependent on your initial synchronization convention. That original convention assumes a value for ε. I already gave links to all of this and quite a bit of math. All I get back is tons of text with no addressing the math.

He is talking about this residual error and has yet to grasp that we have been talking primarily about a greater error which can be cancelled out and which is bigger the faster you move the clocks.

No. You are not writing about a greater error. You can't even "know the error" the way you describe without assuming a convention. The assumed synchronization convention is not a residual error. It's NOT an error at all but rather a choice of convention done because either nothing more exists to find for this or we can't find it because it doesn't matter in any experiment we've ever done. In either case the one-way speed of light is based on convention used.

What exactly are we trying to measure here? The thing you keep calling a "residual error." Extra errors (which can be corrected for anyway when a convention is chosen) caused by crazy ways to transport clocks be damned. I do NOT care about them because the deeper problem is the assumed synchronization we already have. Everything after this is just piling gravy on the already fat chicken.

So far, you appear to have missed the existence of this larger error.

Perhaps maybe you missed the extra fat chicken.

[Bored chemist]

That's all very nice.
But can we go back to the system I described?
That way we can ignore (for the minute- we can get back to it later) David's point about "But, what happens if the system is actually moving? ".
We can ignore it because I'm sat here on the ground, looking at the clocks and, from my POV they are not moving.
I am not, for the minute, concerned about how it looks to someone flying past in a plane or whatever.

In that case, I can sync two clocks next to each-other.
I can move one of them away- as slowly as I like, in order to reduce the dime dilation it experiences.
And I can then have two clocks that I know are in synchrony, at least from my point of view- and I don't care about anyone else's (at least for the time being).
And I can use those two clocks and two video cameras to record the time at which the light from a flash bulb reaches them.
And I can measure the distance between the clocks (again, noting that I'm stationary WRT to them so Fitzgerald contraction doesn't enter into it).
I can measure the time it takes for a flash of light  to cover a known distance.
From my point of view in this idealised system.

Things will, of course, be different for someone flying past it at half C.
So what?
I'm interested in measuring it here, locally, where gravity is small and even so it has no significant effect (and, at a pinch I could correct for it, but it's easier to just make that correction very small). Round here the change in gravity- if I sent the light straight up- would be about 1 in 10^15 over a distance of 22.5 metres and that's far enough to get a reasonable measurement  with modern kit)
(Based on this)
https://en.wikipedia.org/wiki/Pound%E2%80%93Rebka_experiment
If I send the light out horizontally, the effect is much smaller- so I'm going to ignore it.


Where's the problem? I have numbered the steps so you can point out where the issue lies.

(1)  Because the clocks are started at the same time in the same place there is no argument about their synchronicity at that point.
(2) Because we move one of them slowly, the phase error on it is arbitrarily small.
So it will stay arbitrarily close to synchronised.

(3) I can measure the distance I move it- again, as slowly as I like.
(4) I can set the cameras to record the clock in the foreground and the flash in the background.
(5) I can analyse the  recordings.
(6) I can look record at the time on the clock when the flash arrives.
(7) I can calculate the speed as  distance divide by the time difference.


Which step is giving us the problem.
As far as I can tell it's (2).
But, if we move the clock slowly, any relativistic effects are small (as David helpfully did the calculations for - thanks for that).

At the least, we ought to be able to get  a good approximation to the 1 way speed of light.

(And if some passing spaceman doesn't agree- what of it? He and I won't even agree on the speed of the number 9 bus; why would we expect his assessment of the 1 way speed of light to be the same as mine?)

[David Cooper]

Absolutely not. Slow clock transport and light synchronization are identical mathematically as I've said many times. I've actually shown the math on this more than once in this thread but nobody actually bothers with understanding the math I wrote...

It's clear that you don't bother to read text carefully enough to understand what people are saying, so you end up arguing at cross-purposes with them. If you move a light clock at c, it stops ticking throughout the time you're moving it. If you move it at 0.5c it ticks at a slowed rate, 87% of its rest ticking rate - not 50%. At 0.5c it takes twice as long to move the clock into position, but it doesn't miss the same number of ticks while moving as a clock which is moved at c. In both cases there a large error has built up, but we can calculate what that error is (on the mistaken basis that the system is stationary - that's where your convention comes in) and correct for it, and it's only then that we have a remaining error that's proportional to the distance travelled (regardless of the speed the clock was moved). The rest of us have been talking about the error that varies with the speed the clock is moved and which we can correct for, although in making that correction, we naively assume that the system is stationary and therefore we set it up to measure the one-way speed of light as c.

The "amount of error" is dependent on your initial synchronization convention. That original convention assumes a value for ε. I already gave links to all of this and quite a bit of math. All I get back is tons of text with no addressing the math.

If you expect people to plough through your maths when you can't be bothered to read through our text to find out what we're actually saying, you're going to find yourself starting arguments all over the place with people who agree with you.

No. You are not writing about a greater error. You can't even "know the error" the way you describe without assuming a convention. The assumed synchronization convention is not a residual error. It's NOT an error at all but rather a choice of convention done because either nothing more exists to find for this or we can't find it because it doesn't matter in any experiment we've ever done. In either case the one-way speed of light is based on convention used.

It almost always is an error - the error is the result of your assumed synchronisation convention, and it's only not an error if the system happens to be at rest in space rather than moving. Of course, if you're doing SR and deny that there is an absolute frame, you can then deny that there's ever an error and call it an infinitely-thin chicken instead, but it's a good idea to start off explaining things in relation to an absolute frame before bringing in that kind of magical complication.

What exactly are we trying to measure here? The thing you keep calling a "residual error." Extra errors (which can be corrected for anyway when a convention is chosen) caused by crazy ways to transport clocks be damned. I do NOT care about them because the deeper problem is the assumed synchronization we already have. Everything after this is just piling gravy on the already fat chicken.

I don't care about crazy ways to transport clocks either, but BC needs to understand what happens with his chosen way of synchronising clocks, and he isn't going to be fobbed off with answers which only explain other methods.

[guest4091]

Absolutely not. Slow clock transport and light synchronization are identical mathematically

Assuming a Master clock, and 2 Slave clocks, wouldn't the loss of time for the s-clock in slow transport be equal to d/a[1-sqrt(1-a*a)]? d=distance, a=speed

[David Cooper]

That's all very nice.
But can we go back to the system I described?

The system you described is covered by my three clocks - your system only uses the middle clock and one of the clocks that is moved away from it.

That way we can ignore (for the minute- we can get back to it later) David's point about "But, what happens if the system is actually moving? ".
We can ignore it because I'm sat here on the ground, looking at the clocks and, from my POV they are not moving.
I am not, for the minute, concerned about how it looks to someone flying past in a plane or whatever.

I'm not concerned about what it looks like to other observers either, but about what the universe thinks of it. If you assume you aren't moving, your experiment will measure the speed of light from one clock to the other as c. If you assume you are moving at 50% the speed of light in the direction you're sending your flash of light, you will make a correction to one of your clocks to cancel out the error you think needs to be applied to it and then you will measure the speed of light to be 0.5c. You're trying to avoid making such a correction because you think the error can be so close to zero that it won't matter, but it's only going to be close to zero if the system's at rest.

I'm interested in measuring it here, locally, where gravity is small and even so it has no significant effect (and, at a pinch I could correct for it, but it's easier to just make that correction very small). Round here the change in gravity- if I sent the light straight up- would be about 1 in 10^15 over a distance of 22.5 metres and that's far enough to get a reasonable measurement  with modern kit)
(Based on this)
https://en.wikipedia.org/wiki/Pound%E2%80%93Rebka_experiment
If I send the light out horizontally, the effect is much smaller- so I'm going to ignore it.

You were talking earlier about doing the experiment horizontally on a flat Earth, so it is equivalent to doing it in deep space. Gravity needn't be considered.

Where's the problem? I have numbered the steps so you can point out where the issue lies.

The problem is that you're assuming that you're stationary and synchronising your clocks on that basis (and by that, I'm referring to synchronisation at a distance which is forced on your clocks as you move one away from the other).

(2) Because we move one of them slowly, the phase error on it is arbitrarily small.
So it will stay arbitrarily close to synchronised.

That's where you're going wrong, because the error is only tending to zero if the system is at rest in space. If the stationary clock is actually moving at high speed in the direction you move the other clock, the clock that you move will be moving faster than the "stationary" clock and the time dilation difference will tune your synchronisation in such a way that you end up measuring the speed of light as c regardless of its actual speed relative to the clocks.

I did actually make a mistake in my analysis though. When I had a moving central clock and my other two clocks were moving away from it, one of them was actually at rest during that process and the other was moving twice as fast as the middle clock. But it wouldn't actually be moving twice as fast as the middle clock because it would merely appear that way to an observer at rest with the middle clock, so it may not be undergoing a slowing of its ticking greater than twice the slowing of the middle clock. However, we certainly must have one of the end clocks ticking fastest while the opposite end clock is ticking slowest (during the phase where we're moving them apart), and that will certainly lead to one of the outer clocks lagging behind the middle clock and the middle clock lagging behind the other outer clock. If you are only using the middle clock and one of the outer clocks (while ignoring the other), how do you know which outer clock you're using? Are you using the one that's lagging behind the ticking of the middle clock or are you using the one that the middle clock is lagging behind? You should be able to see from this that there's a skew in the system which is caused by the movement of the system through space while you moved your clock, and that has tuned your synchronisation in such a way that you will measure the speed of light between your clocks as c.

[dutch]

Quote from: dutch on Today at 02:44:44
Absolutely not. Slow clock transport and light synchronization are identical mathematically
Assuming a Master clock, and 2 Slave clocks, wouldn't the loss of time for the s-clock in slow transport be equal to d/a[1-sqrt(1-a*a)]? d=distance, a=speed

Slow clock transport is the limit as a goes to zero. Given an initial synchronization convention (such as Einstein's where ε =1/2) then transporting the clock very slowly such that a/c ≈ 0 then the clocks remain synchronized in that convention.

You cannot know time dilation without the assumption of a synchronization convention.

t'/t = f'/f = (1 - v/c) / γ = γ / (1 + v/c) =  (1 - a/c)  / (1 + b/c)  γb/γa  where  v = (a + b) / (1 + a b /c²)
 
Time dilation could be :  τ = t / γ  or  τ = γ t   or  τ = γb/γa t  these are all different. Given a t, τ could be 0 to infinity even if v is arbitrarily small.

We CANNOT measure time dilation τ by any known means. What we can measure in a lab is observed time t' and our time t. We can only measure values locally. No matter what assumptions we make t' and t are symmetric.

Einstein assumes the form t'/t =  (1 - v/c) / γ   then he assumes c t = x  AKA light moves at c in both directions.

t'/t =  (1 - v/c) / γ   →   t' =  (t - v/c t) / γ  →  t' =  (t - v x/c²) / γ

I could assume the speed of light is c± = c / (1 ± κ)  where κ = 0  to 1

For example c- = ∞   and c+ = 1/2c  when κ = 1

Round trip speed would be:

t = 1/2 (x/c- + x/c+) = 1/2 (x/∞ + x/(1/2c)) = x/c    as expected. David keeps saying 0 to 2c (c+ = c - |v| and c- = c + |v|) which wouldn't work relative to the clocks in that reference frame.

There is no need to invoke a preferred frame here because all physics we've ever done allows us to pick any κ and ε we choose. We could choose ε = 1/2 and κ = 0 (like Einstein) or any other possible value we wish (we could even have that same new value for all reference frames; this works in GR without modification). LET uses all values where each frame uses a different κ and ε. Using all values this has the ability to match SR mathematically (but would require modification to GR at yet untested extremes).

In any case like I've shown many times we can't measure the one-way speed of light independent of a synchronization convention. Unless experiments prove otherwise there is no error as David keeps implying because we are free to choose any convention we wish. He's pushing his idea based on a preferred frame that could be true but cannot be verified/pinned down. I'm pushing against the idea that we should be pinned down to a certain ε when we can't verify it without using an arbitrary convention (no matter how useful the convention is). There is nothing magical about it. There is also no separating "larger" synchronization "errors" because we can't cut the Lorentz Transformation into pieces and treat those pieces separately without first assuming a convention. David is not understanding why the clock difference depends on distance. It has nothing to do with "errors" or time dilation but rather the plane of simultaneity chosen. We know the input to the equation t and the output t'. How we choose to arrange the right side of the equation so it "makes sense" to us depends on convention.

t2 = t1 + ε (t3 - t1)

https://en.wikipedia.org/wiki/One-way_speed_of_light

The above link explains how much of this works. There's no need to have

[Bored chemist]

but it's only going to be close to zero if the system's at rest.

Good.
You can stop there.
Because from my point of view, it is at rest.
"If you assume you are moving at 50% the speed of light in the direction you're sending your flash of light, "
From my perspective, I'm quite clearly not, so it would be an odd assumption.From my point of view, it's not an assumption, it's an observation.
As I said earlier, the Universe at large will certainly include things which are moving WRT me and their views on many things will differ from mine.

[David Cooper]

Unless experiments prove otherwise there is no error as David keeps implying because we are free to choose any convention we wish.

I have spoken of two errors, one of which is larger the faster you move one clock while not moving the other clock (which you assume to be at rest). That error is real and predictable, so it can be corrected for. Even if you move the clock extremely slowly, an error of that kind will remain - all you can do is decrease its size until it becomes small enough that you have less need to bother making a correction. In denying the existence of that error, you are only going to confuse people who can see that it must exist.

He's pushing his idea based on a preferred frame that could be true but cannot be verified/pinned down.

The whole business of trying to measure the one-way speed of light necessarily brings in the idea of an absolute frame if you imagine that light can travel relative to you at a speed other than c, so of course we have to explore this on that basis.

There is nothing magical about it.

If light is moving relative to you at c and you then accelerate towards the source of the light until you are moving at high speed towards it, the light can only still be moving relative to you at c if the universe runs on SR's magic. If we could determine the one-way speed of light and found it to be the same in both cases, then we would know that it does run on that kind of magic. The jury is still out on that though, because we can't determine the one-way speed of light to disprove SR directly.

David is not understanding why the clock difference depends on distance. It has nothing to do with "errors" or time dilation but rather the plane of simultaneity chosen.

One or other of us has certainly failed to understand this fully, and if it's me, I want to find that out.

If we assume that the middle of my three clocks is stationary and move the other two away from it very slowly so that the error (which you say doesn't exist) is minimised, we have three clocks ticking almost in sync. The outer two are certainly ticking in sync. What happens though if we decide that the middle clock is moving and we move the others so slowly that they're moving at almost the same speed while we relocate them? We now see these go past us because we are stationary, and we ought to see the front clock lag with its displayed time behind the other clocks  while the rear clock moves ahead of the others with its time. We can get a God's eye view of this by taking photographs with a special kind of video camera where the clocks move directly past the pixels and practically touch them (no lens needed - this is like making a contact print) - each pixel records light when its own clock tells it to, and all the pixel clocks are synchronised for the frame of reference that we're using.

Now, here's the problem. If the clocks are moving so slowly that there is no error of the second type creeping in (due to different time dilations applying to different clocks while they're being moved apart), they must stay in sync in BOTH frames. They cannot possibly be ticking simultaneously in both frames though, so how can they get out of sync in the absolute frame where we watch the system moving past us?

[David Cooper]

Now, here's the problem. If the clocks are moving so slowly that there is no error of the second type creeping in (due to different time dilations applying to different clocks while they're being moved apart), they must stay in sync in BOTH frames. They cannot possibly be ticking simultaneously in both frames though, so how can they get out of sync in the absolute frame where we watch the system moving past us?

The reality is that time dilation has a crucial role. There are a couple of ways of controlling things as the two outer clocks are moved away from the middle one. One way is to move them a measured distance at a measured speed, but if the system is moving, one of those clocks will take longer to complete the trip than the other (because relative to the middle clock, one of the moving clocks will be moving slower than the other for relativistic reasons), which means the other clock will be back to ticking at the same speed as the middle clock sooner, changing its tick rate before the other moving clock changes its tick rate to match. The other obvious way of controlling things is to move each clock for a set amount of its measured time at a fixed speed, and once its time hits the target, you stop moving it - this has the same result with the time dilation difference causing one clock to hit the target sooner. Either way, the time dilation has a key role in how the events pan out. The idea that time dilation can be excluded from this by moving the clocks at infinitely slow speed is a misuse of mathematics and would lead to the clocks ticking in sync in both frames of reference once separated.

[guest4091]

simultaneity
refer to graphic.
The left side represents the description of events by U, the rest frame by definition.
A moves parallel to U in the x direction at .6c. A chooses to synchronize two slave clocks to the master clock at x=0. One s-clock is located 1 unit distance ahead x=.8 (length contraction), and the other behind x=-.8 (not shown for clarity), Two light signals (blue) are  emitted at t=0, to start both clocks (events R1 and R2), and get a reading returned to A  (event D) at t=2g. Events R1 and R2 establish the axis of simultaneity for A,  represented by line 0-Ax. The red line transforms U-time to A-time, thus At for D is 2.00. Next A sends a signal to set the clocks to the current time t plus half the transit time1. The s-clocks are synchronized to the m-clock.

The right side represents the description of events by A.
Notice
1. the SR synch convention provides the correct value for x according to what A perceives, assuming a pseudo rest frame.
2. the event R1 and convention assigned (R1) both occur at the same distance Ux=2, which is Ax=1.6. I.e. it doesn't make any difference since the round trip time is the same for both.

The practicality of 3 or more clocks allows 1 expensive precision clock to maintain the efficiency of a system of common clocks for the masses. It's what is done every day in our world.   


https://app.box.com/s/umw5stjtqwoo7pqjv2h322psnwngetnb

[guest4091]

Bored chemist;

The lost time is
x/a[√(1-aa)-1]

(4) I can set the cameras to record the clock in the foreground and the flash in the background
(6) I can look record at the time on the clock when the flash arrives.
(7) I can calculate the speed as  distance divide by the time difference.

The light must return for you to be aware of a distant event.
If you are assuming a pseudo rest frame, you accept the path lengths are equal.
If you assume being in motion, and the path lengths are different, the synched clocks return the same reading, despite the fact the path sequence is reversed.

The fundamental problem is, you are present at the local events, emission and detection. You are not present at the distant reflection event. You can know where it occurred but not when.
Of course there are limits to what's practical vs ideal!