On Saturday, October 26, 2024 at 8:44:51 PM UTC-6 Jesse Mazer wrote:

On Sat, Oct 26, 2024 at 3:06 AM Alan Grayson <[email protected]> wrote:





*So that one typo, which was correct elsewhere made it muddled for you? *


*In part yes. When I think an author doesn't know what he's expounding 
about, I lose interest. Also, although I was a software engineer at JPL, I 
don't know LISP,  so it would be hard to see what assumptions you made in 
generating the plot. And the plot is claimed to establish time dilation, 
and I'm not sure how you developed the width of the blue path say, to show 
time passes more rapidly compared to the other plots.  AG*


*I just assumed a width for the blue path.  All that determines is how fast 
the light clock ticks.  Then the other two light clock world lines were 
generated by point-by-point application of the given Lorentz transform.  So 
I showed the two clocks moving relative to blue ticked more slowly, not the 
other way around.  Do you not see that the bouncing photon hits the mirror 
less often in red's clock as measured in blue's frame. *



*Yes, so that implies tics are less frequent in red's clock, compared to 
blue's clock, so the time rate for red is less than blue, which is what I 
in effect posted -- that blue clock tics more rapidly than red clock. Why 
do you fail to understand what I wrote? AG *




*I understood it, but it read as if you didn't realize red was just the 
transform of blue and it is in the clock's own frame it runs fastest.  You 
wrote as though I "developed the width of the blue path say, to show time 
passes more rapidly"  whereas I chose it arbitrarily and derived the other 
two. Brent*

 
*Are you saying the red clock is in the same frame as the blue clock? I 
missed that point. Why did you model it this way, instead of just using two 
frames, one at rest, the other moving? Why does the red clock's photon 
cross at right angles, but this isn't so for the blue clock? Were they 
arbitrary choices? AG*

*This discussion began with my claim that there could be a clock paradox, 
defined by two clocks, each running slower than the other. If such a 
paradox existed, it would be impossible to produce a plot which would show 
it. So, what exactly does your plot show; that the LT establishes that a 
moving clock runs slower than a stationary clock? This is not something I 
disputed.** I don't see how your plot resolves a possible paradox. **AG*

*I thought that if I could synchronize clocks in two inertial frames 
without the LT, I could establish the paradox. But now I don't think this 
is true. What is true, is that the LT causes time dilation, and is, so to 
speak, the price we pay to guarantee frame invariance of the SoL. AG*

*For Jesse; I looked up Einstein's method for determining simultaneous 
events. IIUC, it involves two clocks and a light source midway between them 
to produce simultaneous events, with the conclusion that simultaneity 
exists in the rest frame of the clocks, but not in a moving frame. I didn't 
use it to establish that clocks in two inertial frames can be synchronized. 
Neither did I deny it. I don't see why you think there's something awry 
that I didn't use it. AG*


*Again, the problem is that you simply haven't clearly laid out what your 
procedure is for synchronizing different clocks at rest in the *same* 
frame, so your summary of the experiment you want to set up is too vague 
without that information. Are all the A clocks synchronized with one 
another using the Einstein synchronization procedure in the A frame, and 
then the B clocks set with reference to whichever A clock they are next to 
at some moment? Or is just one B clock set by reference to the A clock it's 
next to, and the other B clocks synchronized with that first B clock using 
the Einstein synchronization procedure in the B frame? Or some other 
option?*

*Jesse*


*I assumed that if the two juxtaposed clocks were set to t=0, and I 
specified how any other clock in either frame could be synchronized to 
those two clocks, one can infer how to synchronize any other clock, in any 
known distance to any previously synchronized clock, and synchronize that 
clock. I was trying to imagine a scheme for synchronizing all hypothetical 
clocks in both frames. If I could do this, I was thinking I'd be able to 
solve the apparent clock paradox. But I now realize that even if I could do 
this, the clocks will NOT remain synchronized because the LT won't allow 
it, and we must use the LT since it's presumably the only frame 
transformation that constrains the SoL to be frame independent. Therefore, 
I've come to the conclusion that the problem I'm trying to understand, can 
only be solved via the breakdown of simultaneity. AG*

*Finally, I note that Brent was correct in his initial response, that I 
failed to define the problem clearly. This might account for the fact that 
his plot fails to offer a solution to my initially ill-posed question. 
AFAICT, his plot just shows that the LT implies a clock in a spatially *
*moving frame, his red frame, tics at a slower rate than the clock in 
spatially fixed frame, his blue clock. This we already knew, and the 
problem I seek to understand, is what happens when the red and blue clocks 
become juxtaposed, but there's insufficient resolution in his plot at this 
point of interest, to shed any light on my problem. I now want to go back 
one of your previous posts where you allegedly showed that the LT is, 
indeed, a transformation, in the sense that it tells an observer in the 
spatially fixed frame, the rest frame, what the observer in the moving 
frame will actually measure. This issue puzzles me because of the 
contraction of a moving rod. In which frame does the shrinking rod reside? 
TY, AG *

-- 
You received this message because you are subscribed to the Google Groups 
"Everything List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/everything-list/f9bcb58d-e672-459f-9a97-b836e96000d9n%40googlegroups.com.

Reply via email to