On 10/20/2021 12:29 AM, Townes Olson wrote:
> On Tuesday, October 19, 2021 at 7:51:57 PM UTC-7, Thomas 'PointedEars' Lahn wrote:

<grabbing popcorn>

Op 20-okt.-2021 om 17:00 schreef Michael Moroney:
> On 10/20/2021 12:29 AM, Townes Olson wrote:
>> On Tuesday, October 19, 2021 at 7:51:57 PM UTC-7, Thomas 'PointedEars'
>> Lahn wrote:
>
> <grabbing popcorn>

What an incredible waste of time that is. Good grief.

Dirk Vdm

On 10/20/2021 12:50 PM, Dirk Van de moortel wrote:
> Op 20-okt.-2021 om 17:00 schreef Michael Moroney:
>> On 10/20/2021 12:29 AM, Townes Olson wrote:
>>> On Tuesday, October 19, 2021 at 7:51:57 PM UTC-7, Thomas
>>> 'PointedEars' Lahn wrote:
>>
>> <grabbing popcorn>
>
> What an incredible waste of time that is. Good grief.
>
I am always up for a good old fashioned kꙩꙩkfight, even if this really
isn't a kꙩꙩkfight, but a clash of mega-egos instead.

Michael Moroney wrote:

> On 10/20/2021 12:50 PM, Dirk Van de moortel wrote:
>> Op 20-okt.-2021 om 17:00 schreef Michael Moroney:
>>> On 10/20/2021 12:29 AM, Townes Olson wrote:
>>>> On Tuesday, October 19, 2021 at 7:51:57 PM UTC-7, Thomas
>>>> 'PointedEars'
>>>> Lahn wrote:
>>>
>>> <grabbing popcorn>
>>
>> What an incredible waste of time that is. Good grief.
>>
> I am always up for a good old fashioned kꙩꙩkfight, even if this really
> isn't a kꙩꙩkfight, but a clash of mega-egos instead.

you still stupid lika door, both cases.

JanPB wrote:

> Yes, I have a German and Polish keyboards settings but I was referring
> to the situations where for whatever reason those options were not
> available. Some industrial display devices do not have the proper
> diacritics although the situation has improved a lot over the years.

ACK.

> I remember some years ago in Berlin the bus to, say, Steinstücken would
> show a big STEINSTUECKEN in front.

Whether that was due to technical limitations, negligence, or style is
impossible to say, though. Sometimes for uppercase umlaut letters this
decomposition is used for style, and because the diaeresis is harder to spot
(or may not be as easily understood by foreigners, which in a city like
Berlin is likely).

Similarly, the uppercase SZ („Eszett“) ligature („ẞ“) exists but is commonly
unknown/uncommon, and typically replaced with „SS“ (e.g. for headings in
tabloid newspapers); it is supposed to be replaced like that on forms in
places where Blockschrift (“block letters”, all-caps) are expected.
(And AISB, in Switzerland you will usually not find any Eszett, lowercase
or uppercase, but «ss» and «SS» instead.)

PointedEars
--
Heisenberg is out for a drive when he's stopped by a traffic cop.
The officer asks him "Do you know how fast you were going?"
Heisenberg replies "No, but I know where I am."
(from: WolframAlpha)

Townes Olson wrote:

> On Tuesday, October 19, 2021 at 7:51:57 PM UTC-7, Thomas 'PointedEars'
> Lahn wrote:
>> >> I have NEVER said that it is wrong.
>> > That is a lie, as shown by this verbatim quote:
>> >
>> >> LOL If you had any clue about translations, you would know that such a
>> >> translation [Stachel's] hardly reflects the original meaning.
>>
>> I did not write “[Stachel’s]”, and the implication that I referred to
>> that translation by what I said is yet another misconstruction on your
>> part.
>
> Again, that is a lie.

You are a hopeless case. I wrote:

,-<news:21246634.EfDdHjke4D@PointedEars.de>
|
| > Stachel's translation of Einstein's paper […]
|
| … is not the official translation, therefore quite irrelevant.
| The official translation can be found here instead:
|
| <https://einsteinpapers.press.princeton.edu/vol2-trans/154>

Nothing more, nothing less.

That I would have claimed that Stachel’s translation would be “wrong”
is YOUR FANTASY only.

And at this point I have to assume that your constant misconstructions
are intentional, merely a means for trolling (how unfortunately typical
for a Google Grouper); so EOD for me.

PointedEars
--
«Nec fasces, nec opes, sola artis sceptra perennant.»
(“Neither high office nor power, only the scepters of science survive.”)

—Tycho Brahe, astronomer (1546-1601): inscription at Hven

On Thursday, October 21, 2021 at 2:01:53 PM UTC-7, Thomas 'PointedEars' Lahn wrote:
> I wrote:
> | > Stachel's translation of Einstein's paper […]
> |
> | … is not the official translation, therefore quite irrelevant.
> | The official translation can be found here instead:
> | <https://einsteinpapers.press.princeton.edu/vol2-trans/154>

But in the part of my message that you snipped (which was everything after the first five words) I gave the verbatim quote from the CPAE translation and contrasted it with Stachel's translation (specifically his use of run/runs) mentioned by Ricardo, confirming that, contrary to what Jan had said, Einstein actually did describe the transitivity of synchronization... which Jan immediately agreed. And in response to this clear and simple correction you began ranting about the "official" CPAE translation, utterly oblivious to the fact that I had just quoted the CPAE translation and contrasted it with the Stachel translation *in that very message*. You had also posted a reply to Ricardo telling him that the Stachel translation was a "re-wording" of what Einstein wrote, and that Ricardo must immediately stop referring to it and adopt the "official" CPAE translation, even though both of those translations equally well confirm Ricardo's point, which is that Einstein did indeed describe the transitivity of synchronization in his 1905 paper.. The side question about "run" versus "is" doesn't negate his point either way.

Look, here is the actual sequence of comments:

Jan:
> I don't see any mention of transitivity in Einstein's 1905 paper...

Ricardo:
> Einstein: pg 127 in Stachel ed - Einstein's Miraculous Year
> 2. If the clock at A runs synchronously with the clock at B as well as
> with the clock at C, then the clocks at B and C also run synchronously
> relative to each other.

Jan:
> But Einstein himself did not say this, he just said we assume this definition
> is free of contradictions...

Townes:
> Stachel's translation of Einstein's paper actually *does* say that, talking about
> "running", etc. A better translation in Einstein's collected papers [the CPAE translation!]
> says "2. If the clock in A is synchronous with the clock in B as well as with the clock in C,
> then the clocks in B and C are also synchronous relative to each other."

At *this* point you responded idiotically by snipping all but the first five words of my post:

> | > Stachel's translation of Einstein's paper […]
> |
> | … is not the official translation, therefore quite irrelevant.
> | The official translation can be found here instead:
> | <https://einsteinpapers.press.princeton.edu/vol2-trans/154>

Then another Tom chided you for claiming there is such a thing as an "official" translation, and you replied "Yet another person who can't read".

> That I would have claimed that Stachel’s translation would be “wrong”
> is YOUR FANTASY only.

That is obviously not true: If you didn't think there was anything wrong with the Stachel translation, why on earth were you torturing Ricardo about his use of the Stachel translation, and demanding that he immediately cease quoting it and switch to the CPAE translation? You told him the Stachel version was a "re-wording" (as if the CPAE was not also a re-wording!). Likewise, when I finally got you to compare the Stachel/Google and CPAE translations (along with the Methuen and Miller) with Einstein's original German, noting that they differ only in the former using "run/runs", you said that was not a correct translation of Einstein's sentence ("LOL, such translations hardly convey the meaning"), using läuft and laufen, due to the umlaut, etc., etc.

Look, if you now agree that you are not (and never were) in any position to say there is anything wrong with the Stachel translation, and that Ricardo was correct all along when he said that Einstein's 1905 paper describes the transitivity of synchronization, then that's great. So your entire "contribution" to the discussion was misguided and pointless.

On Thursday, October 21, 2021 at 2:01:46 PM UTC-7, Thomas 'PointedEars' Lahn wrote:
> JanPB wrote:
>
> > Yes, I have a German and Polish keyboards settings but I was referring
> > to the situations where for whatever reason those options were not
> > available. Some industrial display devices do not have the proper
> > diacritics although the situation has improved a lot over the years.
>
> ACK.
>
> > I remember some years ago in Berlin the bus to, say, Steinstücken would
> > show a big STEINSTUECKEN in front.
>
> Whether that was due to technical limitations, negligence, or style is
> impossible to say, though. Sometimes for uppercase umlaut letters this
> decomposition is used for style, and because the diaeresis is harder to spot
> (or may not be as easily understood by foreigners, which in a city like
> Berlin is likely).

Some styles of the old Fraktur typeface have a tiny "e" above the letter
instead of the dot pair. Obviously not much used today except in odd
things like the critical edition of Mozart's letters a few years ago.

> Similarly, the uppercase SZ („Eszett“) ligature („ẞ“) exists but is commonly
> unknown/uncommon, and typically replaced with „SS“ (e.g. for headings in
> tabloid newspapers); it is supposed to be replaced like that on forms in
> places where Blockschrift (“block letters”, all-caps) are expected.
> (And AISB, in Switzerland you will usually not find any Eszett, lowercase
> or uppercase, but «ss» and «SS» instead.)

Just got back from Switzerland a week ago, it's one of my secret vices :-)

--
Jan

JanPB wrote:

>> Similarly, the uppercase SZ („Eszett“) ligature („ẞ“) exists but is
>> commonly unknown/uncommon, and typically replaced with „SS“ (e.g. for
>> headings in tabloid newspapers); it is supposed to be replaced like
>> that on forms in places where Blockschrift (“block letters”, all-caps)
>> are expected.
>> (And AISB, in Switzerland you will usually not find any Eszett,
>> lowercase or uppercase, but «ss» and «SS» instead.)
>
> Just got back from Switzerland a week ago, it's one of my secret vices

shithole country, ran by imbeciles. They don't understand tensors, nor
you does. Their fake money causes right now death in billions around the
world. Such liberal capitalist fake money countries, may not even exists.

On Friday, October 22, 2021 at 5:59:03 AM UTC-7, Rique Pazo wrote:
> JanPB wrote:
>
> >> Similarly, the uppercase SZ („Eszett“) ligature („ẞ“) exists but is
> >> commonly unknown/uncommon, and typically replaced with „SS“ (e.g. for
> >> headings in tabloid newspapers); it is supposed to be replaced like
> >> that on forms in places where Blockschrift (“block letters”, all-caps)
> >> are expected.
> >> (And AISB, in Switzerland you will usually not find any Eszett,
> >> lowercase or uppercase, but «ss» and «SS» instead.)
> >
> > Just got back from Switzerland a week ago, it's one of my secret vices
> shithole country, ran by imbeciles. They don't understand tensors, nor
> you does. Their fake money causes right now death in billions around the
> world. Such liberal capitalist fake money countries, may not even exists.

They do have a paraglider on their 50 CHF note so it can't be that bad.

BTW, what's up with you and tensors? You keep bringing them up as
if it was something hallowed or something.

--
Jan

Gamma sameness for clocks would keep them the same.

On October 14, tjrob137 wrote:
> Here are three techniques he described to synchronize clock C2 to clock
> C1. In all cases both clocks must be at rest in a single inertial frame
> F, and all light pulses are in vacuum.
> A) Repeatedly send a light pulse from C1 to C2, where it is
> reflected back to C1. Set C2 so at the reflection it
> displays a value that is midway between the values on C1 when
> it was emitted and received.
> B) Place a pulsed light source at rest in F at the midpoint
> between C1 and C2, able to send light pulses to both
> clocks. Set C2 so it displays the same value as C1 when
> they receive a given pulse.
> C) Measure the distance in F between C1 and C2, call it D. Let
> C1 emit light pulses to C2, and set C2 so when it receives a
> pulse it displays a value that is the emission value on C1
> plus D/c.

(C) subsumes (A) and (B), as D must be known in all cases.

--
Rich

On 10/22/21 7:10 PM, RichD wrote:
> On October 14, tjrob137 wrote:
>> Here are three techniques he described to synchronize clock C2 to
>> clock C1. In all cases both clocks must be at rest in a single
>> inertial frame F, and all light pulses are in vacuum. A)
>> Repeatedly send a light pulse from C1 to C2, where it is reflected
>> back to C1. Set C2 so at the reflection it displays a value that is
>> midway between the values on C1 when it was emitted and received.
>> B) Place a pulsed light source at rest in F at the midpoint between
>> C1 and C2, able to send light pulses to both clocks. Set C2 so it
>> displays the same value as C1 when they receive a given pulse. C)
>> Measure the distance in F between C1 and C2, call it D. Let C1 emit
>> light pulses to C2, and set C2 so when it receives a pulse it
>> displays a value that is the emission value on C1 plus D/c.
>
> (C) subsumes (A) and (B), as D must be known in all cases.

No. methods A and B do not require knowing the distance between the
clocks C1 and C2. Method B require one to be able to determine the
midpoint between them, but the value of the distance is not needed.

Tom Roberts

On October 14, tjrob137 wrote:
> Here are three techniques he described to synchronize clock C2 to clock
> C1. In all cases both clocks must be at rest in a single inertial frame
> F, and all light pulses are in vacuum.
> A) Repeatedly send a light pulse from C1 to C2, where it is
> reflected back to C1. Set C2 so at the reflection it
> displays a value that is midway between the values on C1 when
> it was emitted and received.
> B) Place a pulsed light source at rest in F at the midpoint
> between C1 and C2, able to send light pulses to both
> clocks. Set C2 so it displays the same value as C1 when
> they receive a given pulse.
> C) Measure the distance in F between C1 and C2, call it D. Let
> C1 emit light pulses to C2, and set C2 so when it receives a
> pulse it displays a value that is the emission value on C1
> plus D/c.

Method (C) is brain-dead for a discussion of fundamentals, because it relies on the proposition that light invariably propagates at the speed c in terms of inertial coordinates, which we could know only by measuring the speed, which already requires inertially synchronized clocks. Method (A) really isn't a direct method, per se, it's a statement of an implicit attribute of inertially synchronized clocks, which can be turned into an effective method in various ways, as was explained early in this thread, including a specific direct method (other than trial and error). Method (B), as explained previously, is the only sensible conceptual method, since it involves nothing other than spatial measurement (to determine the mid-point) and inertial isotropy, of the signal, which can be assured by symmetry, although it need not be light signals, e.g., we could use identical bullets from identical guns or sound waves in a solid rod, or etc. Inertial isotropy is part of the definition of inertia--based coordinate systems, so it is stipulated as a characteristic of inertial synchronization.

On October 23, tjrob137 wrote:
>>> Here are three techniques he described to synchronize clock C2 to
>>> clock C1.
>>> A) Repeatedly send a light pulse from C1 to C2, where it is reflected
>>> back to C1. Set C2 so at the reflection it displays a value that is
>>> midway between the values on C1 when it was emitted and received.
>>> B) Place a pulsed light source at rest in F at the midpoint between
>>> C1 and C2, able to send light pulses to both clocks. Set C2 so it
>>> displays the same value as C1 when they receive a given pulse. C)
>>> Measure the distance in F between C1 and C2, call it D. Let C1 emit
>>> light pulses to C2, and set C2 so when it receives a pulse it
>>> displays a value that is the emission value on C1 plus D/c.
>
>> (C) subsumes (A) and (B), as D must be known in all cases.
>
> No. methods A and B do not require knowing the distance between the
> clocks C1 and C2. Method B require one to be able to determine the
> midpoint between them, but the value of the distance is not needed.

In method (A), upon receiving the reflected pulse, C1 sends the midway
value to C2, via radio. C2 receives this message after a transmission time
delay. He then sets his clock to.... ?

He needs to know this delay, which he calculates as D/c.
Hence he needs to know D.

--
Rich

On Saturday, October 23, 2021 at 4:21:00 PM UTC-7, RichD wrote:
> On October 23, tjrob137 wrote:
> >>> Here are three techniques he described to synchronize clock C2 to
> >>> clock C1.
> >>> A) Repeatedly send a light pulse from C1 to C2, where it is reflected
> >>> back to C1. Set C2 so at the reflection it displays a value that is
> >>> midway between the values on C1 when it was emitted and received.
> >>> B) Place a pulsed light source at rest in F at the midpoint between
> >>> C1 and C2, able to send light pulses to both clocks. Set C2 so it
> >>> displays the same value as C1 when they receive a given pulse. C)
> >>> Measure the distance in F between C1 and C2, call it D. Let C1 emit
> >>> light pulses to C2, and set C2 so when it receives a pulse it
> >>> displays a value that is the emission value on C1 plus D/c.
> >
> >> (C) subsumes (A) and (B), as D must be known in all cases.
> >
> > No. methods A and B do not require knowing the distance between the
> > clocks C1 and C2. Method B require one to be able to determine the
> > midpoint between them, but the value of the distance is not needed.
> In method (A), upon receiving the reflected pulse, C1 sends the midway
> value to C2, via radio. C2 receives this message after a transmission time
> delay. He then sets his clock to.... ?
>
> He needs to know this delay, which he calculates as D/c.
> Hence he needs to know D.
>
> --
> Rich
This is not how the method works, it is much smarter than that:

When C2 receives the signal from C1 it resets itself (to zero)
When the reflected signal comes back to C!, C1 simply halves his elapsed time. C1 and C2 are now synchronized.

On Sunday, 24 October 2021 at 02:47:06 UTC+2, Dono. wrote:
> On Saturday, October 23, 2021 at 4:21:00 PM UTC-7, RichD wrote:
> > On October 23, tjrob137 wrote:
> > >>> Here are three techniques he described to synchronize clock C2 to
> > >>> clock C1.
> > >>> A) Repeatedly send a light pulse from C1 to C2, where it is reflected
> > >>> back to C1. Set C2 so at the reflection it displays a value that is
> > >>> midway between the values on C1 when it was emitted and received.
> > >>> B) Place a pulsed light source at rest in F at the midpoint between
> > >>> C1 and C2, able to send light pulses to both clocks. Set C2 so it
> > >>> displays the same value as C1 when they receive a given pulse. C)
> > >>> Measure the distance in F between C1 and C2, call it D. Let C1 emit
> > >>> light pulses to C2, and set C2 so when it receives a pulse it
> > >>> displays a value that is the emission value on C1 plus D/c.
> > >
> > >> (C) subsumes (A) and (B), as D must be known in all cases.
> > >
> > > No. methods A and B do not require knowing the distance between the
> > > clocks C1 and C2. Method B require one to be able to determine the
> > > midpoint between them, but the value of the distance is not needed.
> > In method (A), upon receiving the reflected pulse, C1 sends the midway
> > value to C2, via radio. C2 receives this message after a transmission time
> > delay. He then sets his clock to.... ?
> >
> > He needs to know this delay, which he calculates as D/c.
> > Hence he needs to know D.
> >
> > --
> > Rich
> This is not how the method works, it is much smarter than that:
>
> When C2 receives the signal from C1 it resets itself (to zero)
> When the reflected signal comes back to C!, C1 simply halves his elapsed time. C1 and C2 are now synchronized.

In the meantime in the real world, however, GPS clocks
keep measuring t'=t, just like all serious clocks always did.

On Sunday, 24 October 2021 at 07:53:08 UTC+2, maluw...@gmail.com wrote:

> In the meantime in the real world, however, GPS clocks
> keep measuring t'=t, just like all serious clocks always did.

Who pays you to spam every single fucking thread with that
just retarded broken record??

Eat shit and die, you and your employer.

*Plonk*

Julio

On Sunday, 24 October 2021 at 10:27:13 UTC+2, ju...@diegidio.name wrote:
> On Sunday, 24 October 2021 at 07:53:08 UTC+2, maluw...@gmail.com wrote:
>
> > In the meantime in the real world, however, GPS clocks
> > keep measuring t'=t, just like all serious clocks always did.
> Who pays you to spam every single fucking thread with that
> just retarded broken record??

Nobody, I just like it.

On 10/23/21 6:20 PM, RichD wrote:
> On October 23, tjrob137 wrote:
>>>> Here are three techniques he described to synchronize clock C2
>>>> to clock C1. A) Repeatedly send a light pulse from C1 to C2,
>>>> where it is reflected back to C1. Set C2 so at the reflection
>>>> it displays a value that is midway between the values on C1
>>>> when it was emitted and received. B) Place a pulsed light
>>>> source at rest in F at the midpoint between C1 and C2, able to
>>>> send light pulses to both clocks. Set C2 so it displays the
>>>> same value as C1 when they receive a given pulse. C) Measure
>>>> the distance in F between C1 and C2, call it D. Let C1 emit
>>>> light pulses to C2, and set C2 so when it receives a pulse it
>>>> displays a value that is the emission value on C1 plus D/c.
>>
>>> (C) subsumes (A) and (B), as D must be known in all cases.
>>
>> No. methods A and B do not require knowing the distance between the
>> clocks C1 and C2. Method B require one to be able to determine the
>> midpoint between them, but the value of the distance is not
>> needed.
>
> In method (A), upon receiving the reflected pulse, C1 sends the
> midway value to C2, via radio. C2 receives this message after a
> transmission time delay. He then sets his clock to.... ? He needs
> to know this delay, which he calculates as D/c. Hence he needs to
> know D.

That's just a stupid way of doing it. It's easy to design method A so D
is not needed:

For one specific light pulse, C1 records the time on C1 the pulse is
sent, call it X. When C2 reflects the pulse it records the time on
C2, call it Y. When C1 receives the reflection it records the time on
C1, call it Z, C1 then sends the value (X+Z)/2 to C2 by any convenient
means -- that is the value C2 should have had at the reflection in order
to be synchronized with C1. When C2 receives this message, C2 adds
(X+Z)/2-Y as an offset to C2. C2, of course, is running throughout, and
after this addition is synchronized with C1.

As C1 is repeatedly sending light pulses, this can be checked using
successive pulses, and/or the offsets from multiple pulses can be
averaged to reduce errors.

The value of D is not needed. Both clocks must be able to identify
individual light pulses, but that is easy to arrange by making the
interval between pulses large enough, or by including identification in
the pulse.

Tom Roberts

On Sunday, October 24, 2021 at 8:21:59 AM UTC-7, tjrob137 wrote:
> On 10/23/21 6:20 PM, RichD wrote:
> > On October 23, tjrob137 wrote:
> >>>> Here are three techniques he described to synchronize clock C2
> >>>> to clock C1. A) Repeatedly send a light pulse from C1 to C2,
> >>>> where it is reflected back to C1. Set C2 so at the reflection
> >>>> it displays a value that is midway between the values on C1
> >>>> when it was emitted and received. B) Place a pulsed light
> >>>> source at rest in F at the midpoint between C1 and C2, able to
> >>>> send light pulses to both clocks. Set C2 so it displays the
> >>>> same value as C1 when they receive a given pulse. C) Measure
> >>>> the distance in F between C1 and C2, call it D. Let C1 emit
> >>>> light pulses to C2, and set C2 so when it receives a pulse it
> >>>> displays a value that is the emission value on C1 plus D/c.
> >>
> >>> (C) subsumes (A) and (B), as D must be known in all cases.
> >>
> >> No. methods A and B do not require knowing the distance between the
> >> clocks C1 and C2. Method B require one to be able to determine the
> >> midpoint between them, but the value of the distance is not
> >> needed.
> >
> > In method (A), upon receiving the reflected pulse, C1 sends the
> > midway value to C2, via radio. C2 receives this message after a
> > transmission time delay. He then sets his clock to.... ? He needs
> > to know this delay, which he calculates as D/c. Hence he needs to
> > know D.
> That's just a stupid way of doing it. It's easy to design method A so D
> is not needed:
>
> For one specific light pulse, C1 records the time on C1 the pulse is
> sent, call it X. When C2 reflects the pulse it records the time on
> C2, call it Y. When C1 receives the reflection it records the time on
> C1, call it Z, C1 then sends the value (X+Z)/2 to C2 by any convenient
> means -- that is the value C2 should have had at the reflection in order
> to be synchronized with C1. When C2 receives this message, C2 adds
> (X+Z)/2-Y as an offset to C2. C2, of course, is running throughout, and
> after this addition is synchronized with C1.
>
> As C1 is repeatedly sending light pulses, this can be checked using
> successive pulses, and/or the offsets from multiple pulses can be
> averaged to reduce errors.
>
> The value of D is not needed. Both clocks must be able to identify
> individual light pulses, but that is easy to arrange by making the
> interval between pulses large enough, or by including identification in
> the pulse.
>
> Tom Roberts

This is way too complicated. Here is a much simpler and more robust way:
C1 starts its clock from 0 and sends a signal to C2.
When C2 receives the signal from C1 it resets itself (to zero)
When the reflected signal comes back to C1, C1 simply halves his elapsed time. C1 and C2 are now synchronized

On Sunday, 24 October 2021 at 17:21:59 UTC+2, tjrob137 wrote:
> On 10/23/21 6:20 PM, RichD wrote:
> > On October 23, tjrob137 wrote:
> >>>> Here are three techniques he described to synchronize clock C2
> >>>> to clock C1. A) Repeatedly send a light pulse from C1 to C2,
> >>>> where it is reflected back to C1. Set C2 so at the reflection
> >>>> it displays a value that is midway between the values on C1
> >>>> when it was emitted and received. B) Place a pulsed light
> >>>> source at rest in F at the midpoint between C1 and C2, able to
> >>>> send light pulses to both clocks. Set C2 so it displays the
> >>>> same value as C1 when they receive a given pulse. C) Measure
> >>>> the distance in F between C1 and C2, call it D. Let C1 emit
> >>>> light pulses to C2, and set C2 so when it receives a pulse it
> >>>> displays a value that is the emission value on C1 plus D/c.
> >>
> >>> (C) subsumes (A) and (B), as D must be known in all cases.
> >>
> >> No. methods A and B do not require knowing the distance between the
> >> clocks C1 and C2. Method B require one to be able to determine the
> >> midpoint between them, but the value of the distance is not
> >> needed.
> >
> > In method (A), upon receiving the reflected pulse, C1 sends the
> > midway value to C2, via radio. C2 receives this message after a
> > transmission time delay. He then sets his clock to.... ? He needs
> > to know this delay, which he calculates as D/c. Hence he needs to
> > know D.
> That's just a stupid way of doing it. It's easy to design method A so D
> is not needed:
>
> For one specific light pulse, C1 records the time on C1 the pulse is
> sent, call it X. When C2 reflects the pulse it records the time on
> C2, call it Y. When C1 receives the reflection it records the time on
> C1, call it Z, C1 then sends the value (X+Z)/2 to C2 by any convenient
> means -- that is the value C2 should have had at the reflection in order
> to be synchronized with C1. When C2 receives this message, C2 adds
> (X+Z)/2-Y as an offset to C2. C2, of course, is running throughout, and
> after this addition is synchronized with C1.
>
> As C1 is repeatedly sending light pulses, this can be checked using
> successive pulses, and/or the offsets from multiple pulses can be
> averaged to reduce errors.
>
> The value of D is not needed. Both clocks must be able to identify
> individual light pulses, but that is easy to arrange by making the
> interval between pulses large enough, or by including identification in
> the pulse.

In the meantime in the real world, however, GPS clocks
keep measuring t'=t, just like all serious clocks
always did.

On 10/23/21 10:51 AM, Townes Olson wrote:
> On October 14, tjrob137 wrote:
>> Here are three techniques he described to synchronize clock C2 to
>> clock C1. In all cases both clocks must be at rest in a single
>> inertial frame F, and all light pulses are in vacuum. A) Repeatedly
>> send a light pulse from C1 to C2, where it is reflected back to C1.
>> Set C2 so at the reflection it displays a value that is midway
>> between the values on C1 when it was emitted and received. B) Place
>> a pulsed light source at rest in F at the midpoint between C1 and
>> C2, able to send light pulses to both clocks. Set C2 so it displays
>> the same value as C1 when they receive a given pulse. C) Measure
>> the distance in F between C1 and C2, call it D. Let C1 emit light
>> pulses to C2, and set C2 so when it receives a pulse it displays a
>> value that is the emission value on C1 plus D/c.
>
> Method (C) is brain-dead for a discussion of fundamentals, because it
> relies on the proposition that light invariably propagates at the
> speed c in terms of inertial coordinates, which we could know only by
> measuring the speed, which already requires inertially synchronized
> clocks.

Sure. As I said, I was describing the three methods Einstein described.

> Method (A) really isn't a direct method, [...]. Method (B), as
> explained previously, is the only sensible conceptual method, since
> it involves nothing other than spatial measurement [...]

Method A is every bit as valid and direct as method B [#]. And method A
does not require the spatial measurement of B. Both, of course, depend
on the isotropy of the propagation of light pulses relative to the
inertial frame F, on clocks ticking uniformly when at rest in F, and on
the ability to add a numerical offset to a clock.

[#] In the physicist's sense, in which math is trivial
and only physical effects matter. Methods A and B make
the same physical assumptions about the world.

Tom Roberts

On 10/24/2021 11:21 AM, Tom Roberts wrote:
> On 10/23/21 6:20 PM, RichD wrote:
>> On October 23, tjrob137 wrote:
>>>>> Here are three techniques he described to synchronize clock C2 to
>>>>> clock C1. A) Repeatedly send a light pulse from C1 to C2, where it
>>>>> is reflected back to C1. Set C2 so at the reflection it displays a
>>>>> value that is midway between the values on C1 when it was emitted
>>>>> and received. B) Place a pulsed light source at rest in F at the
>>>>> midpoint between C1 and C2, able to send light pulses to both
>>>>> clocks. Set C2 so it displays the same value as C1 when they
>>>>> receive a given pulse. C) Measure the distance in F between C1 and
>>>>> C2, call it D. Let C1 emit light pulses to C2, and set C2 so when
>>>>> it receives a pulse it displays a value that is the emission value
>>>>> on C1 plus D/c.
>>>
>>>> (C) subsumes (A) and (B), as D must be known in all cases.
>>>
>>> No. methods A and B do not require knowing the distance between the
>>> clocks C1 and C2. Method B require one to be able to determine the
>>> midpoint between them, but the value of the distance is not needed.
>>
>> In method (A), upon receiving the reflected pulse,  C1 sends the
>> midway value to C2, via radio.  C2 receives this message after a
>> transmission time delay.  He then sets his clock to.... ? He needs
>> to know this delay, which he calculates as D/c. Hence he needs to
>> know D.
>
> That's just a stupid way of doing it. It's easy to design method A so D
> is not needed:
>
> For one specific light pulse, C1 records the time on C1 the pulse is
> sent, call it X. When C2 reflects the pulse it records the time on
> C2, call it Y. When C1 receives the reflection it records the time on
> C1, call it Z, C1 then sends the value (X+Z)/2 to C2 by any convenient
> means -- that is the value C2 should have had at the reflection in order
> to be synchronized with C1. When C2 receives this message, C2 adds
> (X+Z)/2-Y as an offset to C2. C2, of course, is running throughout, and
> after this addition is synchronized with C1.
>
> As C1 is repeatedly sending light pulses, this can be checked using
> successive pulses, and/or the offsets from multiple pulses can be
> averaged to reduce errors.
>
> The value of D is not needed. Both clocks must be able to identify
> individual light pulses, but that is easy to arrange by making the
> interval between pulses large enough, or by including identification in
> the pulse.

Similar methods are used for synchronizing computer clocks with a master
or with each other, where the network delay is unknown. Including NTP.

On Sunday, October 24, 2021 at 8:43:53 AM UTC-7, tjrob137 wrote:
> >> A) Repeatedly send a light pulse from C1 to C2, where it is reflected
> >> back to C1. Set C2 so at the reflection it displays a value that is midway
> >> between the values on C1 when it was emitted and received.
> >
> > Method (A) really isn't a direct method, [...].
>
> Method A is every bit as valid and direct as method B [#].

No, method A is not a method at all. Einstein merely says "Two clocks are synchronized if" the readings at those events have that relationship, but this is not an explicit method of setting the clocks so that they have that relationship. Witness the fact that, in your follow-up post today, you parroted the actual method (that was already posted in this thread on Oct 12) based on this implicit condition.

> >> B) Place a pulsed light source at rest in F at the midpoint between C1 and
> >> C2, able to send light pulses to both clocks. Set C2 so it displays
> >> the same value as C1 when they receive a given pulse.

Right, this is parroting the direct and canonical method, which is essentially just implementing the definition of inertial simultaneity -- as also described in the Oct 12 post, where it was noted that it's not restricted to light pulses, and can be applied to, e.g., identical bullets from identical guns at rest at the midpoint, or sound waves from the midpoint of a rod, etc.

> >> C) Measure the distance in F between C1 and C2, call it D. Let C1 emit light
> >> pulses to C2, and set C2 so when it receives a pulse it displays a
> >> value that is the emission value on C1 plus D/c.
> >
> > Method (C) is brain-dead for a discussion of fundamentals, because it
> > relies on the proposition that light invariably propagates at the
> > speed c in terms of inertial coordinates, which we could know only by
> > measuring the speed, which already requires inertially synchronized
> > clocks.
>
> Sure. As I said, I was describing the three methods Einstein described.

Einstein didn't give that as a fundamental method of synchronization, for the reason explained above.

Dono wrote [responding to Tom's parroting of an actual method based on A]:
> This is way too complicated. Here is a much simpler and more robust way:
> C1 starts its clock from 0 and sends a signal to C2. When C2 receives the
> signal from C1 it resets itself (to zero). When the reflected signal comes back
> to C1, C1 simply halves his elapsed time. C1 and C2 are now synchronized.

This is conceptually identical to the method described on Oct 12 and repeated by Tom, as far as synchronization goes, setting to half the interval, etc., but your process doesn't transfer any actual time, it focuses on equality with the arbitrary agreed reset value of zero. Of course, with further communication, the two clocks could then agree to each offset by any fixed amount, and that extra step is how the more elaborate process differs from the simple process. In other words, if C1 is regarded as the standard clock, whose value we don't want to change, and we want to synchronize C2 with it, we can't use the generic "t=0" reset, we need to communicate the actual time, which is what the more elaborate process does. As far as simply equalizing the readings, the two methods are identical.