Deutsch   English   Français   Italiano  
<LKByosKU0FYSjZktQN0sxbS6LFw@jntp>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!2.eu.feeder.erje.net!feeder.erje.net!fdn.fr!usenet-fr.net!pasdenom.info!from-devjntp
Message-ID: <LKByosKU0FYSjZktQN0sxbS6LFw@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: Quand le bouffon Python se croit malin de critiquer le 
 =?UTF-8?Q?g=C3=A9nie=20Hachel=20=3A=29=29?=
References: <7onLIy3ybw-R5ob6HgZ8YMst3LY@jntp> <7cfGUVs3I_srY2ozirSMmP-NOEM@jntp> <va789l$blq6$15@dont-email.me>
 <d0RrffM8HuN3ZJ4WUQ5rpRVuqAU@jntp> <va7cp6$blq6$22@dont-email.me> <va7gnr$blq6$25@dont-email.me>
 <z_xVjhRZgmCHFIgwfNGUbOZ04Z4@jntp> <vaa375$sicr$6@dont-email.me> <InBcOME0Li0nvvBo1gASM3d9Cr8@jntp>
 <vaf025$1q24g$16@dont-email.me>
Newsgroups: fr.sci.physique
JNTP-HashClient: PnPXs10CONk1KCloOEhyhyoTyMM
JNTP-ThreadID: xhXMV5017uyuIW6jcjdtCI17rVE
JNTP-Uri: http://news2.nemoweb.net/?DataID=LKByosKU0FYSjZktQN0sxbS6LFw@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Sun, 25 Aug 24 11:56:36 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Injection-Info: news2.nemoweb.net; posting-host="e8cbf2474b472b9bb79db3dccb6a856bc1d05409"; logging-data="2024-08-25T11:56:36Z/8999818"; posting-account="4@news2.nemoweb.net"; mail-complaints-to="julien.arlandis@gmail.com"
JNTP-ProtocolVersion: 0.21.1
JNTP-Server: PhpNemoServer/0.94.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-JNTP-JsonNewsGateway: 0.96
From: Richard Hachel <r.hachel@tiscali.fr>
Bytes: 9321
Lines: 215

Le 25/08/2024 à 12:12, Python a écrit :

> Mais il ne s'agit pas de ça du tout à ce stade : même dans le
> référentiel où les horloges A et B sont au repos il n'y a pas
> encore de définition de la coordonnées de temps, c'est justement
> le BUT de la procédure de synchronisation que d'établir le sens
> de cette coordonée.

 Tu ne comprends toujours pas ce que je dis.

 Je veux bien qu'on se donne une méthode pour synchroniser les montres.

 Mais dans un univers anisochrone, il n'y aura qu'une synchronisation de 
type M qui va être à la fois utile et cohérente. C'est une 
synchronisation abstraite qui est d'ailleurs, celle d'Einstein.

 Cette synchronisation est une synchronisation imaginaire, mais utile. 

 Elle n'existe d'ailleurs pas dans la nature.

 Ne serait-ce que deux montres A et B, tu ne pourra jamais les accorder 
ensemble DANS la nature,
alors je te parle pas pour une infinité de montres. 

 Il faut donc une montre imaginaire, placée à égale distance de tous 
les autres montres,
et c'est sur sa perception propre de l'INSTANT PRESENT universel, que nous 
allons obtenir une synchronisation utile. 

 Mais on tourne en rond, parce que tu VEUX que ça tourne en rond. 
 
> Tout ce que l'on a est ce que mesure l'horloge A lors de l'événement
> e1 = "émission d'un signal vers B" et e3 = "réception du signal
> renvoyé par B" à savoir t_A et t'_A (et idem pour t_B avec l'horloge
> B).

 Oui, si tu procèdes comme ça, tu sais qu'il y a eu e1,e2,e3, et qu'il y 
a eu tA(e1)=0,
et tA(e3)=2. 

 Valeurs admise par l'univers entier. 

 Cela donne tA(e3)-tA(e1)=2AB/c de façon manifeste.

 Mais sans expérimentation ajoutée, tu ne peux pas en savoir plus.

 En particulier, parce que tu ne sais pas depuis quand on a déclenché B 
(elle marque peut-être 45:05'25")
quand elle reçoit le bip de A, et elle n'en sait pas plus sur l'heure 
qu'il était en A lorsque le bip a eu lieu.

 En résumé, en utilisant A et B, tu ne sais avec la plus parfaite 
certitude que trois choses:

 tA(e1)=0,
 tA(e3)=2. 
 tA(e3)-tA(e1)=2AB/c

 Tu ne sais rien de B, et de A, tu ne sais même pas tA(e2)

 C'est par décision autoritaire, mais fausse (ils n'ont toujours pas 
compris la RR) que certain se croient malin en imposant tA(e2)=1. 

 C'est faux.

 Ils vont ensuite aller très vite et s'enfoncer dans l'erreur en posant 
qu'il est évident que tA(e1)=tB(e1) et que tA(e2)=tB(e2) : la notion de 
présent plat, de simultanéité globale. 

 C'est pas comme ça que ça marche. 
  
> 
> Que ce sont ces valeurs que A affichait lors de e1 et e2 est un FAIT
> pour tout les observateurs qu'ils soient immobiles ou non dans ce
> référentiel, voire même accélérés. Andersen et Mikko se tuent à
> t'expliquer un truc aussi trivial depuis des semaines sur s.p.r.

 Je viens de te dire (ouvre un peu tes oreilles) que la valeur que A 
affiche 
est un FAIT pour tous les observateurs de l'univers. On peut même écrire 
que pour TOUS tA(e1)=0.

 Mais c'est pas de ça que je parle, je parle de leur heure à eux, SUR 
LEUR MONTRE quand se produit e1.
 
 Ta connerie, c'est de fusiller Hachel avant de l'avoir seulement compris. 


 Tu vas alors dire : l'anisochronie universelle, c'est un délire. Ca 
n'existe pas. Le présent est la même pour tous les participants au 
référentiel stationnaire. 

 Et là tu fusilles le plus beau concept et la plus belle RR jamais 
donnée en totalité et en évidence. 

 
> 
> ENSUITE, quand A aura été synchronisée sur B (ou B sur A) alors
> on pourra parler des coordonnées de temps de ces deux événéments,
> dans le référentiel où A et B sont au repos.

 Tu ne PEUX pas, BORDEL, synchroniser deux montres ENTRE ELLES. Il te faut 
obligatoirement un troisième 
participant M, isométrique, qui va donner le bip, qui saura que les bips 
ont été reçu simultanément (dans son présent à lui), et qui recevra 
les deux réponses simultanément.

 On aura alors A et B synchronisés, parfaitement synchronisés, MAIS SUR 
M.

 Tout sera alors très simple et très pratique, les événement seront 
calculés par rapport au temps présent de M, et cela va donner une 
cohérence à l'ensemble anisochrone. 

> Il s'agira bien de t_A et t'_A dans le cas où c'est B qui aura
> été synchronisé sur A (et d'autres valeurs, décalées, si c'est
> l'inverse).

 Quelle est l'heure de B quand il reçoit e2? 

 Comment la décides-tu? Comment synchronises-tu A et B sur quelque chose 
de cohérent?

 C'est d'ailleurs ce que fait la synchronisation Einstein (de type M chez 
Hachel). 

> Mon appli qui visualise tout ça avance bien, je posterai le lien
> ici quand elle sera terminée.

 Le problème, c'est qu'Einstein suppose à tort (le piège est terrible) 
qu'un faisceau lumineux, ou une information se déplace à c dans les 
deux. 

 Ca parait tellement évident que le contradicteur ne peux être que fou.

 Cette fausse croyance pourrit complètement la RR depuis cent vingt ans, 
et la rend complètement fausse dès qu'on s'éloigne des observations 
transversales. 

 Dans nos exemples, où se trouve le point M nécessaire à un certain 
type de synchronisation cohérente?

Loin, et sur une normale 4D à l'hyperplan. 

 Il est donc évident que l'information  A->B et B->A s'effectue à la 
même vitesse.

 Il est donc évident que si l'on a (notation événement Python) :
 tA(e3)-tA(e1)=2AB/c

 On va forcément avoir : tM(e3)-tM(e1)=2AB/c    tautologie.

 Nous venons de dire qu'il n'y a aucune raison valable pour que POUR LUI 
(anisochronie hachélienne en train de pourrir le monde ou douceur ou 
suavité du présent Minkowskien, qu'importe) la vitesse de l'information  
A->B et B->A soit différente.

Il vient aussitôt de façon absolument élémentaire, quelque soit la 
vision des choses (Minkowskiene ou Hachélienne) que :


 tM(e3)-tM(e1)=2AB/c    ---->  tM(e2)-tM(e1) = tM(e3)-tM(e2)

 L'aller se produisant forcément à la même vitesse que le retour pour M 
quelque soit le système relativiste utilisé. 

 Nous allons donc synchroniser les montres de l'univers sur M (à égale 
distance de toutes).
 C'est M qui déclenche A et B. 
 Il envoie un bip, et attend la réponse (en mode Hachélien il déclenche 
========== REMAINDER OF ARTICLE TRUNCATED ==========