Le temps

[ServerError503]

D'un point de vue théorique, l'énergie se conserve. L'énergie c'est, selon le théorème de Noether, la quantité conservée associée à l'invariance des lois de la physique au cours du temps justement. L'information, quant-à elle, ne se perd pas plus que l'énergie. La dynamique d'évolution des systèmes isolés est hamiltonienne donc isentropique.

Pourtant, le second principe de la thermo (parfaitement vérifié expérimentalement) nous affirme au contraire que l'entropie d'un système "isolé" ne peut que croitre ??? C'est même ça l'écoulement irréversible du temps. Quelle est l'explication ?

Elle est la suivante : aucun système (ne comprenant pas l'ensemble de l'univers) n'est réellement isolé. Le théorème H de Boltzmann par exemple, parvient à modéliser l'évolution irréversible d'un gaz parfait et son état d'équilibre (alors que les lois de la physique sont (presque) T-symétriques). Dans cette démonstration se cache, en fait, une fuite d'information hors de portée de l'observateur macroscopique : l'hypothèse dite du chaos moléculaire.

Il n'y a pas de possibilité de définir un écoulement irréversible du temps sans référence à la thermodynamique, c'est à dire à l'entropie : le manque d'information de l'observateur macroscopique.

Ce point a été développé de façon très intéressante par Carlo Rovelli, Alain Connes et Pierre Martinetti, dans des articles scientifiques extrêmement intéressants (et un peu déstabilisants) développant l'hypothèse du temps thermique, articles que j'ai déjà largement cités dans ce même fil.

L'écoulement irréversible du temps, n'est pas une déperdition d'énergie, mais une déperdition d'information.

Wow ! Je vous remercie pour cette démonstration claire et brillante. Je dois vous avouer que j'avais depuis longtemps déjà mis de coté cette idée, qui de toute évidence ne tenait pas la route et me semblait stérile. Si je l'ai évoquée ici, c'est simplement pour mettre à l'épreuve son Auguste Majesté et voir combien de temps il pouvait discuter sans manifester son arrogance (qu'est-ce que je peut être machiavélique )

Quoi qu'il en soit je suis quand même heureux de constater que mon idée n'était pas totalement stupide et dénuée d’intérêt (référence à la déperdition de quelque chose).
Si je comprend bien votre propos, il semblerait que tout système subit un "fuite" d'information (d'ordre ?) qui n'est d'autre qu'une transformation de l'information en quelque chose d’inaccessible pour l’observateur macroscopique. Par contre, j'ai bien essayer de lire les articles que vous citez mais malheureusement, c'est trop avancé pour mon niveau ...

Parallèle amusant: en informatique, il y a un adage qui dit que "The code rot (Les programmes pourrissent)". Après un certain temps et après que plusieurs programmeurs différents aient modifié le code, il devient de moins en moins clair et ordonnées, et tend à devenir plus brouillons et plus sujet aux bugs et aux anomalies intempestives.

[Lulu Cypher]

Salut ServerError503,

Parallèle amusant: en informatique, il y a un adage qui dit que "The code rot (Les programmes pourrissent)". Après un certain temps et après que plusieurs programmeurs différents aient modifié le code, il devient de moins en moins clair et ordonnées, et tend à devenir plus brouillons et plus sujet aux bugs et aux anomalies intempestives.

Ça reste une analogie très lointaine dans laquelle le temps ne fait rien à l'affaire .... le principe même du code reste son immuabilité (tant qu'un *&%?$*?% ne vient pas y foutre le bordel).
Pour ce qui concerne son pourrissement les causes sont directement liées aux différents intervenants surnuméraires mais surtout à la nature de leur intervention (conception non maintenue à jour, documentation obsolète, plan de tests de non régression non implémenté ou non réalisé, spécification élastique, formation inadaptée, bref méthodologie de travail déficiente) et la traçabilité de ce qu'ils font .... il n'y a pas forcément déperdition d"information mais modification de l'information .... un ajout d'information peut aussi conduire à ce pourrissement.

[Psyricien]

Je dois vous avouer que j'avais depuis longtemps déjà mis de coté cette idée, qui de toute évidence ne tenait pas la route et me semblait stérile.

Et après il s'étonne que je poutre ... pour le coup c'est justifié .
Donc tu as fait exprès de défendre une idée "qui ne tiens pas la route", en dépit des arguments avancé ...
J'aime bien les gus qui cherche à mettre en "évidence" des choses sur leur interlocuteurs ... en généralement, ça donne bien plus d'info sur eux que sur l'interlocuteur .

aucun système (ne comprenant pas l'ensemble de l'univers) n'est réellement isolé.

Pas complètement exact ... des système peuvent être "temporairement isolé" sans pour autant être "l'ensemble de l'univers".

G>

[ServerError503]

Ça reste une analogie très lointaine dans laquelle le temps ne fait rien à l'affaire .... le principe même du code reste son immuabilité (tant qu'un *&%?$*?% ne vient pas y foutre le bordel).

Ça se voulais un parallèle amusant ...

Parallèle (Larousse): Qui se développe dans la même direction que quelque chose d'autre, semblable.
Amusante (Larousse) : Qui amuse l'esprit, l'œil, etc., qui sort de l'ordinaire.

Le parallèle se situe au niveau de l'entropie qui semble croitre avec le temps.
Amusant signifie dans ce contexte que c'était une analogie non-sérieuse.

Sinon, c'est bien vrai que temps ne change rien. Mais ça, je penses que tous les lecteurs l'avaient bien compris. Aussi : même si vous ne changer rien au code, il devient désuet avec le temps, en ce sens, il "pourri" aussi.

[ServerError503]

J'aime bien les gus qui cherche à mettre en "évidence" des choses sur leur interlocuteurs ... en généralement, ça donne bien plus d'info sur eux que sur l'interlocuteur .

Le Gus en question se demande bien ce que ça mets en lumière chez lui ...
Si vous pouviez arrêter de mettre systématiquement des winks à la fin de chaque phrases, comme un ersatz médiocre de ponctuation, ça aiderait à ne pas avoir l’impression que vous tentez d’adoucir le mépris contenu dans la phrase précédente...

[Psyricien]

J'aime bien les gus qui cherche à mettre en "évidence" des choses sur leur interlocuteurs ... en généralement, ça donne bien plus d'info sur eux que sur l'interlocuteur .

Le Gus en question se demande bien ce que ça mets en lumière chez lui ...

Je vais te laisser deviner ... je ne voudrais pas de déstabiliser par quelques observations sur ta personne .
Mais j'aime à voir comment vous avez tenu à confirmer mon diagnostique, vous n'étiez pas là pour discuter/comprendre.
Et après il est se congratule de me réaction devant son propos inepte .
Amis du bon sens, passé votre chemin

Si vous pouviez arrêter de mettre systématiquement des winks à la fin de chaque phrases, comme un ersatz médiocre de ponctuation, ça aiderait à ne pas avoir l’impression que vous tentez d’adoucir le mépris contenu dans la phrase précédente...

Je peux* ... vais-je le faire ? C'est une autre question ... oops

*En même temps, qu'est-ce qui est en dehors de ma porté ?

G>

[Lulu Cypher]

Ça reste une analogie très lointaine dans laquelle le temps ne fait rien à l'affaire .... le principe même du code reste son immuabilité (tant qu'un *&%?$*?% ne vient pas y foutre le bordel).

Ça se voulais un parallèle amusant ...
Parallèle (Larousse): Qui se développe dans la même direction que quelque chose d'autre, semblable.
Amusante (Larousse) : Qui amuse l'esprit, l'œil, etc., qui sort de l'ordinaire.
Le parallèle se situe au niveau de l'entropie qui semble croitre avec le temps.
Amusant signifie dans ce contexte que c'était une analogie non-sérieuse.
Sinon, c'est bien vrai que temps ne change rien. Mais ça, je penses que tous les lecteurs l'avaient bien compris. Aussi : même si vous ne changer rien au code, il devient désuet avec le temps, en ce sens, il "pourri" aussi.

Bon un donneur de leçon qui prend les gens pour des cons .... c'est quoi y'a un nid ... bon je vais essayer sur le même ton pour être dans l'air du temps mais n'hésites pas à me reprendre si tu ne me trouves pas assez méprisant (je débute dans ce style)

J'ai bien parlé d'analogie et attention ..... tadam ..... j'ai mis un joli smiley rigolard qui donne un indice fort du sérieux avec lequel je prend ce post ... bon nous n'avons pas le même humour .... j'aurais du m'en rendre compte quand tu as qualifié ton propre exemple d'amusant (j'avoue j'avais un indice moi aussi)[1].

Finalement tu dis comme moi que le temps ne fait rien à l'affaire .... bon alors tout ça n'était que du vent ?

Ah bah non tu dis pas tout à fait comme moi tu dis que le temps ne fait rien à l'affaire ..... mais que quand même il fait un tit quelque chose (tout ça est d'une logique sans faille) .... oui tu introduis le concept de code "désuet"[2] .... Oui j'avoue qu'il existe du code "pas à la mode" mais pas à cause d'une action du temps .... à cause des critères purement externes (choix des méthodes, langage, air du temps ... si si ça existe[3]). En gros cette désuétude n'est pas une caractéristique du code mais de celui qui juge souvent un peu sans finesse. L'élégance du code, la désuétude de la méthode, tout ça ne sont que de la sodomie de diptère .... il y a le code qui fonctionne et qui rencontre les caractéristiques de qualité qui sont exigés et il y a le "reste" (pouah).

Le code ne vieillit pas il ne s'altère pas il ne devient pas autre chose avec le temps il fait ce qu'il doit faire et ne fait pas (si la job a été faite dans les règles de l'art) ce qu'il ne doit pas faire ... il continuera à s'exécuter de la même manière en fournissant le même résultat jusqu'à la fin des temps (pour peu que le substrat sur lequel il s'exécute ne vieillisse pas ce qui n'est pas gagné). Une boucle "for", un "if then else" resteront toujours ce qu'ils sont des instruction inaltérables. On pourrait pousser le raisonnement à l'extrême et se dire qu'on pourrait supprimer en théorie tout "if then else" (par effet de mode/modernisme irréfléchi[4]) puisque s'il existe des comportements différents alors c'est que les objets concernés sont différents ... on pourrait donc remplacer ce groupe d'instructions par autant de classes d'objets différents (très à la mode) et conduisant à une maintenabilité du code proche de 0.

Bon finalement j'ai du mal dans ce style ... alors je vais enterrer cette hache de guerre futile que tu as surement déterrée par erreur.

Bonne journée

-------------------------
[1] J'espère que je n'utilise pas de mots trop complexes .... d'un autre côté il est heureux que tu aies ton Larousse à tes côtés.
[2] Qui est passé de mode, plus en usage, périmé, suranné (cf. Larousse).
[3] Souvent catégorisé par des gens qui ne comprennent pas leur métier et programment comme des cochons sans concevoir ... ou se prennent pour des développeurs parce qu'ils ont réussi leur première macro Excel ... ou même ne se contentent que de suivre les forums techniques et s'autorisent à donner leur avis éclairé en ignorant à quel point ils ignorent ce métier.
[4] Un modernisme irréfléchi est une attitude qui consiste à dire ex nihilo qu'une technique, un savoir faire, une connaissance, un savoir est mieux non pas parce qu'il est mieux mais parce qu'il est plus "récent".

[ServerError503]

...

Je trouvais juste amusant ce concept de perte d'information dans le code (la dérive par rapport à l'intention originale des concepteurs) versus la perte d’information dans un système isolé comme le mentionnait ABC.
Maintenant si vous tenez à débattre tous les détails d'une analogie foireuse, libre à vous ... En passant je ne vous prends pas du tout pour un con, mais quand, comme informaticien, on se fait donnez une leçon de ce qu'est ou non du code, ça laisse songeur à savoir qui prend l'autre pour un ignare...

[Lulu Cypher]

En passant je ne vous prends pas du tout pour un con, mais quand, comme informaticien, on se fait donnez une leçon de ce qu'est ou non du code, ça laisse songeur à savoir qui prend l'autre pour un ignare...

Je me faisais aussi la même remarque .... comme quoi la population des informaticiens n'est pas homogène

Allez ... bière pour tout le monde

[ServerError503]

En passant je ne vous prends pas du tout pour un con, mais quand, comme informaticien, on se fait donnez une leçon de ce qu'est ou non du code, ça laisse songeur à savoir qui prend l'autre pour un ignare...

Je me faisais aussi la même remarque .... comme quoi la population des informaticiens n'est pas homogène

Allez ... bière pour tout le monde

On nage en pleine récursion là ! Arrêtez ma pile (stack) n'en peut plus !

[Raphaël]

Oui. Le temps est juste une variable "commode" pour indexer l'évolution d'un système. Puisque l'évolution du système dans le temps est monotone.

Désolé, moi pas comprendre c'est quoi une évolution monotone.

Est-il un problème que je ne puisse résoudre ?

Oui: mon problème de manque de temps. Mon temps propre passe de plus en plus vite et c'est vraiment chiant d'autant plus que selon la RR il devrait être invariable.

On constate alors que le "décalage" de simultanéité entre \({\cal R}\) et \({\cal R}'\) est constant, et ne dépend pas du temps.

Plutôt étonnant comme résultat, non ? Si le décalage de simultanéité ne dépend pas du temps, il dépend de quoi alors ?

Ton raisonnement est invalide, je te l'ai déjà démontré. Étrangement tu ne commente pas la démonstration en question (voir message précédent).

Peut-être parce que les démonstrations mathématiques c'est un peu trop abstrait pour moi.

[unptitgab]

Peut-être parce que les démonstrations mathématiques c'est un peu trop abstrait pour moi.

Essayer de parler de physique sans comprendre le langage qui permet de le décrire, c'est un peu comme être au milieu de l'océan avec des cartes, une horloge et un sextant sans savoir s'en servir, les chances de se perdre sont grandes.
Quant à une évolution monotone, c'est lorsque sa formalisation mathématiques montre qu'elle est strictement croissante ou strictement décroissante sur un intervalle.

[Totoche]

Le code ne vieillit pas il ne s'altère pas il ne devient pas autre chose avec le temps il fait ce qu'il doit faire et ne fait pas (si la job a été faite dans les règles de l'art) ce qu'il ne doit pas faire ... il continuera à s'exécuter de la même manière en fournissant le même résultat jusqu'à la fin des temps (pour peu que le substrat sur lequel il s'exécute ne vieillisse pas ce qui n'est pas gagné).

/hors sujet on

Il y a quand même ceux qui s’amusent à rendre les API méconnaissables à chaque version mineur des spécifications du langage, quand ce n'est pas la grammaire du langage lui même (non, j'ai pas d'exemple sur ce second point, mais je suis certain qu'il y a des malades pour faire ça). C'est d'autant plus gênant quand le code est interprété sur une machine distante (saloperie de world wide web)...

Curieusement, plus le langage est récent (non, php, javascript, je ne vous ai pas regardé avec des gros yeux), plus c'est le cas. Conclusion, plus un programme est récent (du moins plus le langage utilisé l'est), plus le temps s'écoule rapidement pour ce programme. Merde, je crois que je viens de découvrir une nouvelle loi...

[Psyricien]

Oui. Le temps est juste une variable "commode" pour indexer l'évolution d'un système. Puisque l'évolution du système dans le temps est monotone.

Désolé, moi pas comprendre c'est quoi une évolution monotone.

Une petite recherche google ? Quant on rencontre un terme inconnu ça me semble même le minimum:
https://fr.wikipedia.org/wiki/Fonction_monotone
On retombe encore sur un indice que vous ne cherchez pas à comprendre. Vous attendez juste que les réponses "arrivent".
Qui plus est j'avais déjà donné le sens du terme sur ce fil ... mais bon .

On constate alors que le "décalage" de simultanéité entre \({\cal R}\) et \({\cal R}'\) est constant, et ne dépend pas du temps.

Plutôt étonnant comme résultat, non ? Si le décalage de simultanéité ne dépend pas du temps, il dépend de quoi alors ?

Non pas étonnant du tout. Bien au contraire.
La seule différence entre deux référentiel, c'est leur vitesse relative. Cette dernière, si l'on parle de référentiel inertiel, ne change pas au cours du temps.
Il dépend de quoi, cet écart de simultanéité ? De deux choses (pourtant explicites dans mon message précédent)
-->La vitesse relative entre \({\cal R}\) et \({\cal R}'\).
-->La distance propre entre les deux évènements dont l'on parle.
-->Comme on parle de simultanéité, on pose par construction \({\rm d}t=0\) ou \({\rm d}t'=0\) selon le référentiel où cette simultanéité est estimée.
Ce qui se comprends aisément, puisque en RR un changement de référentiel c'est une rotation dans le Plan "temps-espace" d'angle "la vitesse relative entre les référentiel".
Donc, la différence de simultanéité dépend de la "longueur d'espace" impliquée (propre, où prise dans ton référentiel préféré, attention cependant à être cohérent entre la distance utilisé et les transformations de Lorentz à faire.), et ce via une relation faisant intervenir "la vitesse relative" entre \({\cal R}\) et \({\cal R}'\) (les transformées de Lorentz).

Simple non ?

Ton raisonnement est invalide, je te l'ai déjà démontré. Étrangement tu ne commente pas la démonstration en question (voir message précédent).

Peut-être parce que les démonstrations mathématiques c'est un peu trop abstrait pour moi.

Et c'est bien là le problème. On ne fait pas de physique sans un minimum de math. C'est comme vouloir lire du Shakespeare sans comprendre l'anglais.
Tu as alors toute les chances de ne pas comprendre les concepts que tu abordes, car tu va en rester à des analogies simplistes (sans pouvoir ce rendre compte de où celles si deviennent invalide).

On remarquera que je t'avais fait une démo "sans math" puisque tu es réfractaire ... démo que tu n'as pas dénier commenter .
Je te la remet pour mémoire:

En fait dans la mesure où la notion "d'instant présent" dépend du référentiel choisit (oui oui on y revient encore).
Votre idée s'invalide toute seule, puisque justement:
-->Prenez un évènement A.
-->Prenez deux évènements B et C, non simultané dans \({\cal R}\) où \({\cal R}'\).
-->A et B sont simultanés dans \({\cal R}\)
-->A et C sont simultanés dans \({\cal R}'\)
--> Au regards de la physique, \({\cal R}\) et \({\cal R}'\) sont deux référentiels inertiels et sont équivalents.
Dans votre description:
-->Dans \({\cal R}\), seul A et B existent réellement.
-->Dans \({\cal R}'\), seul A et C existent réellement.
-->Hors \({\cal R}\) et \({\cal R}'\) sont équivalent, aucun ne prime sur l'autre.
Donc B et C existent réellement, ce qui contredit votre assertion initiale, puisque B et C ne sont simultanés ni dans \({\cal R}\) ni dans \({\cal R}'\)

Démonstration par l'absurde, que votre affirmation ne tient pas .

On notera que dans cette exemple B et C peuvent être (ou pas) liés par la causalité. Si il sont lié par la causalité, on démontre ici que de votre point de vue B et C existe en même temps, et donc que deux point d'une chaine causale ont une existence "réel" selon vous au même moment.
Ce qui invalide définitivement votre idée de départ. Voyez ici, il n'y a pas de math, juste un peu de logique.

Je vous rappelle juste la définition de simultanéité en RR:
simultané dans \({\cal R}\) <--> \({\rm d}t = 0\)
simultané dans \({\cal R}'\) <--> \({\rm d}t' = 0\)

Aura t-on enfin une vrai réponse argumentée au lieu des habituelles fuites et autres affirmations gratuites ? C'est la seule inconnue qui demeure dans cet discussion.
G>

[LoutredeMer]

@ Lulu, Servorerror503 et Totoche


D'accord avec Lulu (bien qu'ayant bien moins de compétences, m'étant formée sur le tas en programmation web). Le code ne pourrit pas et ne vieillit pas avec le temps. C'est l'intervention humaine qui le corrompt ou mène a des modifications ou à carrément des suppressions.

Je citerai le format Flash (.swf), format original de toute animation qu'on a pu voir sur le web depuis 15-20 ans, remplacé par le format vidéo pour cause de nombreux piratages. Idem pour le plugin Java et l'applet Java, sujets à de nombreuses failles de sécurité. Oracle a donc décidé de supprimer les plugins sujets à attaques , comme Apple a décidé depuis déjà plusieurs années de ne pas charger les animations flash sur Mac, Iphones et Ipads. Mais le temps ne fait rien à l'affaire.

[Totoche]

On est bien d'accord que mon post, c'était juste histoire de dire une connerie dans un fil qui me dépasse complètement ^^

Bref, je sors

[Lulu Cypher]

D'accord avec Lulu (bien qu'ayant bien moins de compétences, m'étant formée sur le tas en programmation web). Le code ne pourrit pas et ne vieillit pas avec le temps. C'est l'intervention humaine qui le corrompt ou mène a des modifications ou à carrément des suppressions.

[ServerError503]

Avant que la moitié du forum ou de l'univers [observable] intervienne pour éclairer ce qui est évident, l'expression que j'ai utilisé, à savoir, " Après un certain temps et après que plusieurs programmeurs différents aient modifié le code", n'insinue en aucun cas que le temps lui-même pourrait modifier le code. Pas plus que l'expression "les ravages du temps", ne doit être comprise comme "l'entité temps est responsable des rides sur mon visage". Il s'agissait d'une figure de style. Par pité, trêve de sodomie entomologique !

Software rot, also known as code rot, bit rot, software erosion, software decay or software entropy describes the perceived "rot" which is either a slow deterioration of software performance over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or otherwise called "legacy" and in need of upgrade. This is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides.

The Jargon File, a compendium of hacker's lore, defines "bit rot" as a jocular explanation for the degradation of a software program over time even if "nothing has changed"; the idea being this is almost as if the bits that make up the program were subject to radioactive decay.[1]

Software can deteriorate in "performance" over time and become what is commonly called "legacy" as it runs and accumulates errors; this is not generally considered software rot, though it may have some of the same consequences. Usually, such a degraded state can be remedied by completely reinitializing its state (as by a complete reinstallation of all relevant software components, possibly including operating system software); this may also remedy some kinds of software rot, whereas other software rot is irreversible, as the operating environment of the software, or components of the software itself being incompatible, and hence becoming legacy.

[LoutredeMer]

D'accord avec Lulu (bien qu'ayant bien moins de compétences, m'étant formée sur le tas en programmation web). Le code ne pourrit pas et ne vieillit pas avec le temps. C'est l'intervention humaine qui le corrompt ou mène a des modifications ou à carrément des suppressions.

A la tienne

[ABC]

Des système peuvent être "temporairement isolé" sans pour autant être "l'ensemble de l'univers".

Non.

[ABC]

Quel que soit l'artifice utilisé pour tromper nos sens ou celui de la mesure, on mettra le doigt sur une dissymétrie qui montrera encore irréversibilité du temps. Les deux films ne seront pas identiques. Même en truquant le jeu, en utilisant une boule en acier attiré en fin de course par un aimant puissant pour annuler complétement les forces de frottements, je serais en mesure de pointer le fait qu'une vitesse constante est impossible.

Ce sont effectivement les phénomènes irréversibles (à nos yeux d'observateurs macroscopiques) qui sont l'écoulement irréversible du temps. Cette irréversibilité des évolutions n'est pas une conséquence ou une manifestation de l'irréversibilité de l'écoulement du temps, ils sont l'écoulement irréversible du temps.

Si, par exemple, on parvenait à inverser les vitesses d'évolution de toutes les particules dans l'exemple de la goutte d'encre tombée dans un verre d'eau, l'évolution repartirait rapidement dans le sens "normal", celui de la dilution de la goutte d'encre dans l'eau parce qu'aucun système (autre que l'univers dans son ensemble) n'est parfaitement isolé (ni parfaitement isolable, même temporairement).

[Psyricien]

Des système peuvent être "temporairement isolé" sans pour autant être "l'ensemble de l'univers".

Non.

Si, si .
Tout système où s'applique la conservation de l'énergie totale peut-être perçu comme isolé.
C'est le cas par exemple lors d'une collision entre entre particule. (même l'action de la gravitation des particules externe n'est pas stricto sensu inévitable)

G>

[ABC]

Tout système où s'applique la conservation de l'énergie totale peut-être perçu comme isolé.

Un système recevant autant d'énergie thermique qu'il fournit d'énergie mécanique par exemple conserve son énergie totale mais n'est pas un système isolé. Un système isolé est un système qui n'échangerait aucune forme d'énergie avec son milieu extérieur.

C'est le cas par exemple lors d'une collision entre entre particule. (même l'action de la gravitation des particules externe n'est pas stricto sensu inévitable)

D'accord, bien sûr, pour considérer cette approximation comme valide dans toutes ses applications pratiques.

[Psyricien]

Tout système où s'applique la conservation de l'énergie totale peut-être perçu comme isolé.

Un système recevant autant d'énergie thermique qu'il fournit d'énergie mécanique par exemple conserve son énergie totale mais n'est pas un système isolé. Un système isolé est un système qui n'échangerait aucune forme d'énergie avec son milieu extérieur.

Si vous faites l'effort de lire mon propos de travers ... il est certains que ça ne va pas aller .

C'est le cas par exemple lors d'une collision entre entre particule. (même l'action de la gravitation des particules externe n'est pas stricto sensu inévitable)

D'accord, bien sûr, pour considérer cette approximation comme valide dans toutes ses applications pratiques.

Euh ... manque un morceau à la réponse non ?

[25 décembre]

Oui