Transformez vos données avec les référentiels

Bonjour à tous,

Le contenu du tutoriel peut paraître trop "facile" ou évident. Le but de ce Zeste est de fournir une méthode un minimum rigoureuse pour aider le programmeur à trouver des formules de conversions entre ce que j'appelle des "systèmes de données". Si vous avez une idée de comment mieux appeler cela d'ailleurs, je suis preneur.

L'utilité immédiate du tutoriel est de pouvoir alléger un de mes tutoriels dans lequel je présente cette technique : https://zestedesavoir.com/tutoriels/611/les-espaces-de-couleurs-rvb-et-tsv/ . J'ai aussi écris ce Zeste pour pouvoir l'utilisateur dans d'autres tutoriels (en débutant l'écriture d'autres tutos je me suis rendu compte que j'avais d'abord besoin de celui là).

Ensuite dans le contenu du tutoriel en lui même je vais le continuer et lui rajouter beaucoup d'exemples mathématiques pour que le lecteur s'entraîner à démontrer les formules et faire attention aux contraintes sur les ensembles, et surtout pour montrer des cas d'applications plus concrets qu'un robinet d'eau chaude .

Edit 28 mars 2016 : J'ai renommé le tutoriel, pris en compte une ressource pédagogique (vidéo youtube) dans l'introduction, fini les deux premiers chapitres, commencé la rédaction des chapitres suivants. J'ai décidé de conserver l'exemple des degrés Celsius / Fahrenheit : il est vrai que l'on peut simplifier la formule finale et qu'une opération d'ajout de degrés aussi banale n'as pas besoin des référentiels. Cependant, je ne fais pas un tutoriel sur une technique nécessaire partout mais sur une technique "facultative" (elle présente une vision des choses) intéressante qui mènera dans les chapitres d'après à des vrais applications utiles. Je prend le pari que le lecteur saura passer outre ce petit défaut (si il le trouve) du premier exemple.

Quelques points où j'ai besoin d'aide :

1. Les pré-requis d'introduction mathématiques sont ils suffisant selon vous ?
2. La justification physique du mélange de l'eau et de la température est assez floue…
3. Plus d'exemples en conclusion sur l'utilisation des référentiels dans les sciences ! (j'en développerais aussi certains dans des chapitres)

Merci d'avance pour votre aide

Salut,

Je suis assez mitigé, sans vouloir faire un jeu de mots douteux (enfin, si, un peu, on va pas se mentir ).

En fait, je ne comprends pas ce que tu essayes de faire passer comme message. D'un côté tu sembles vouloir prôner le fait de donner un sens à tes variables, et de l'autre, tu passes sous silence le sens de la moitié de tes variables. Tu ne dis pas que $\dfrac 95$ est la pente de la relation affine entre les deux unités et que $32$ est l'offset à l'origine. Si tu avais fait ça, exclure le code "je multiplies la température en Celsius que je veux ajouter à des Fahrenheit par la pente de la relation affine entre les deux" devient nettement plus litigieux, et même en fait complètement litigieux si l'on considère qu'il s'agit du moins gourmand des quatre proposés.

Tu sembles proposer de se rabattre toujours sur l'algo naïf "on ramène tout à la même unité, on fait la tambouille nécessaire et ensuite on repart sur l'unité désirée". Alors, ça marche toujours, on est d'accord, mais c'est un peu bête de faire ça systématiquement lorsque les relations entre unités sont quasi-linéaires et qu'on peut s'épargner des gros calculs sans perdre le moindre sens.

J'ai une deuxième observation, c'est que tu formalises mathématiquement les changements d'unités avec des fonctions mathématiques (ce qui est un très bon point), mais tu donnes des fonctions à effet de bords dans tes pseudos-codes. Bon courage pour faire des compositions avec de telles fonctions lorsque le problème se corse un peu. C'est plus un détail, mais je trouve que ça fait perdre beaucoup de puissance à ton propos.

Salut,

Je suis assez mitigé, sans vouloir faire un jeu de mots douteux (enfin, si, un peu, on va pas se mentir ).

En fait, je ne comprends pas ce que tu essayes de faire passer comme message. D'un côté tu sembles vouloir prôner le fait de donner un sens à tes variables, et de l'autre, tu passes sous silence le sens de la moitié de tes variables. Tu ne dis pas que $\dfrac 95$ est la pente de la relation affine entre les deux unités et que $32$ est l'offset à l'origine. Si tu avais fait ça, exclure le code "je multiplies la température en Celsius que je veux ajouter à des Fahrenheit par la pente de la relation affine entre les deux" devient nettement plus litigieux, et même en fait complètement litigieux si l'on considère qu'il s'agit du moins gourmand des quatre proposés. Tu sembles proposer de se rabattre toujours sur l'algo naïf "on ramène tout à la même unité, on fait la tambouille nécessaire et ensuite on repart sur l'unité désirée". Alors, ça marche toujours, on est d'accord, mais c'est un peu bête de faire ça systématiquement lorsque les relations entre unités sont quasi-linéaires et qu'on peut s'épargner des gros calculs sans perdre le moindre sens. Salut,

Merci pour ton retour c'est ce genre de commentaires que j'attends. Tes remarques viennent principalement du fait que l'exemple choisi est trop simple. J'ai tout de même une question : comment tu fait pour démontrer "je multiplies la température en Celsius que je veux ajouter à des Fahrenheit par la pente de la relation affine entre les deux" ? J'imagine que tu te bases sur un résultat évident des fonctions affines, mais comment tu le démontres à la base ?

"il s'agit du code le moins gourmand des quatre proposés" Oui mais ça je m'en fiche complètement, le but est qu'à la fin celui qui a suivi le tutoriel sache tout refaire tout seul (cf. mon tutoriel sur les espaces de couleurs RVB et TSV je n'y donne pas toutes les réponses).

Si tu as une idée d'opération sur les degrés plus compliquée qu'un ajout ou une multiplication tout en restant réaliste je suis preneur (ou un autre exemple d'introduction…).

Sinon effectivement j'ai pensé à rajouter d'expliquer 9/5 et 32 mais j'ai peur que ça fasse trop lourd, mon but n'est pas de faire un cours sur les fonctions affines.

Ah oui tu parles du fait que le paramètre DegreFahrenheit soit inout ?

Tes remarques viennent principalement du fait que l'exemple choisi est trop simple.

Je pense justement que c'est ce qui pourrait faire son intérêt si bien exploité. Montrer que l'algo naïf n'est pas forcément le meilleur et que réfléchir un peu avant de coder sur le sens de la relation entre les variables (et pas seulement le sens des variables elles-même) est une bonne idée.

J'ai tout de même une question : comment tu fait pour démontrer "je multiplies la température en Celsius que je veux ajouter à des Fahrenheit par la pente de la relation affine entre les deux" ? J'imagine que tu te bases sur un résultat évident des fonctions affines, mais comment tu le démontres à la base ?

Facile, c'est la définition même d'une pente : $\alpha=\dfrac{y_a-y_b}{x_a-x_b}$. $x_a-x_b$, c'est ton écart en température Celsius (qui n'est pas une température Celsius, ce que tu passes un peu sous silence), $y_a-y_b$, c'est ton écart en Fahrenheit. Avec ça, il devient trivial que $y_a = y_b + \alpha (x_a-x_b)$. Un autre avantage de cette façon de faire, c'est aussi que c'est la seule qui met en lumière le fait que le décalage d'origine des deux températures n'intervient absolument pas dans le problème.

[EDIT : d'ailleurs, le fait que tu passes sous silence que l'on ajoute un écart en Celsius et non une température t'empêche d'expliquer (et empêche le lecteur de comprendre) pourquoi on n'ajoute pas directement ces degrés Celsius convertis en Fahrenheit, ce qui donc pourrait limiter les capacités du lecteur à réappliquer ça sur un autre problème]

Si on veut formaliser un peu plus, la relation étant linéaire (à un changement de repère trivial près) un DL au premier ordre permettra de décrire ce qui se passe dans un voisinage de taille infinie autour de n'importe quel point d'ancrage. On a donc juste besoin de la dérivée (autrement dit la pente) de la relation entre les deux pour réaliser des additions.

Pour partir sur un autre point de vue, ta question se généralise au cas suivant. On est dans un repère $(x, y)$ ((Celsius, Fahrenheit) par exemple), avec la relation $y=ax+b$. La question de base, c'est "si j'avance de tant en $x$, de combien j'avance en $y$ ?". Question qu'on a probablement tous entendu au collège au moment d'aborder les fonctions affines, puis réentendu au moment de généraliser le concept de pente avec la dérivée. Au collège, on comptait même les petits carreaux pour calculer la pente avec la formule que j'ai donné plus haut, faisant sans le savoir un calcul de dérivé simplissime. Pour moi, le meilleur code en terme de sens est celui qui exploite ça pour ne pas faire apparaître inutilement les ordonnées à l'origine.

"il s'agit du code le moins gourmand des quatre proposés" Oui mais ça je m'en fiche complètement, le but est qu'à la fin celui qui a suivi le tutoriel sache tout refaire tout seul (cf. mon tutoriel sur les espaces de couleurs RVB et TSV je n'y donne pas toutes les réponses).

Je ne vois pas pourquoi les deux seraient incompatibles, ce sont deux problèmes différents. La question du coup revient à "quel est le message que tu veux faire passer ?". J'avais l'impression que ton message principal, c'était "il faut regarder le sens des variables que vous manipulez avant de foncer dans le code". Du coup, je pose la question "pourquoi ne pas regarder aussi le sens des relations entre les variables avant de foncer dans le code". Ça me parait crucial pour savoir refaire soi-même des codes pour voyager dans un espace $(x,y)$ qui ne soient pas complètement à la rue lorsque les relations sont un peu compliquées et que leur inversion est coûteuse, voire impossible (dans ce dernier cas, ton propos sur le fait que composer les conversions dans un sens puis dans l'autre doit donner une fonction neutre tombe à l'eau).

Ah oui tu parles du fait que le paramètre DegreFahrenheit soit inout ?

Oui.

Tes remarques viennent principalement du fait que l'exemple choisi est trop simple.

Je pense justement que c'est ce qui pourrait faire son intérêt si bien exploité. Montrer que l'algo naïf n'est pas forcément le meilleur et que réfléchir un peu avant de coder sur le sens de la relation entre les variables (et pas seulement le sens des variables elles-même) est une bonne idée.

Pourquoi pas, mais comme premier exemple d'introduction c'est moyen ça retarderait le moment où l'on a besoin de mon tuto. (Sinon le tutoriel serait sous cette forme : je donne un problème, ah bah en fait ça se simplifie, et si on faisait plus compliqué ? bam je suis obligé de passer par les systèmes de données)

J'ai tout de même une question : comment tu fait pour démontrer "je multiplies la température en Celsius que je veux ajouter à des Fahrenheit par la pente de la relation affine entre les deux" ? J'imagine que tu te bases sur un résultat évident des fonctions affines, mais comment tu le démontres à la base ?

Facile, c'est la définition même d'une pente : $\alpha=\dfrac{y_a-y_b}{x_a-x_b}$. $x_a-x_b$, c'est ton écart en température Celsius (qui n'est pas une température Celsius, ce que tu passes un peu sous silence), $y_a-y_b$, c'est ton écart en Fahrenheit. Avec ça, il devient trivial que $y_a = y_b + \alpha (x_a-x_b)$. Un autre avantage de cette façon de faire, c'est aussi que c'est la seule qui met en lumière le fait que le décalage d'origine des deux températures n'intervient absolument pas dans le problème.

Ok (il te reste à démontrer que la pente ne change pas mais oui) de toute façon il existe un calcul plus simple que passer par (f-1) rond (ajout Celsius) rond f pour démontrer la formule alors mon truc de système de données est mauvais pour cet exemple trop basique).

[EDIT : d'ailleurs, le fait que tu passes sous silence que l'on ajoute un écart en Celsius et non une température t'empêche d'expliquer (et empêche le lecteur de comprendre) pourquoi on n'ajoute pas directement ces degrés Celsius convertis en Fahrenheit, ce qui donc pourrait limiter les capacités du lecteur à réappliquer ça sur un autre problème]

Oui c'est vrai, ça complique encore mon exemple ou comment je dois l'aborder…

"il s'agit du code le moins gourmand des quatre proposés" Oui mais ça je m'en fiche complètement, le but est qu'à la fin celui qui a suivi le tutoriel sache tout refaire tout seul (cf. mon tutoriel sur les espaces de couleurs RVB et TSV je n'y donne pas toutes les réponses).

Je ne vois pas pourquoi les deux seraient incompatibles, ce sont deux problèmes différents. La question du coup revient à "quel est le message que tu veux faire passer ?". J'avais l'impression que ton message principal, c'était "il faut regarder le sens des variables que vous manipulez avant de foncer dans le code". Du coup, je pose la question "pourquoi ne pas regarder aussi le sens des relations entre les variables avant de foncer dans le code". Ça me parait crucial pour savoir refaire soi-même des codes pour voyager dans un espace $(x,y)$ qui ne soient pas complètement à la rue lorsque les relations sont un peu compliquées et que leur inversion est coûteuse, voire impossible (dans ce dernier cas, ton propos sur le fait que composer les conversions dans un sens puis dans l'autre doit donner une fonction neutre tombe à l'eau).

Oui j'aimerais transmettre les deux message . Par contre j'aimerais avoir un exemple où l'inversion est coûteuse/impossible et qu'il y a une simplification à ne pas calculer (f-1) rond (opération) rond f

Ok effectivement il faut que je corrige ça

Merci pour tes commentaires, je pense qu'il faut que je trouve un autre exemple d'introduction.

Sinon le tutoriel serait sous cette forme : je donne un problème, ah bah en fait ça se simplifie, et si on faisait plus compliqué ? bam je suis obligé de passer par les systèmes de données

Ça me fait penser à un truc au passage, je ne comprends pas bien ce que tu désignes par système de données. Tu pourrais essayer de détailler ça ?

il te reste à démontrer que la pente ne change pas mais oui

Tu me demandes sérieusement de prouver que $\dfrac 95$ est une constante ?

Par contre j'aimerais avoir un exemple où l'inversion est coûteuse/impossible et qu'il y a une simplification à ne pas calculer (f-1) rond (opération) rond f

$y=Ax$ avec $A$ une grosse matrice pas carrée.

Sinon le tutoriel serait sous cette forme : je donne un problème, ah bah en fait ça se simplifie, et si on faisait plus compliqué ? bam je suis obligé de passer par les systèmes de données

Ça me fait penser à un truc au passage, je ne comprends pas bien ce que tu désignes par système de données. Tu pourrais essayer de détailler ça ?

Bah c'est ça le problème, le concept est tellement évident / trivial qu'il n'a jamais été nommé à ma connaissance, j'ai sorti ça mais je suis prêt à changer (cf. premier post). Il s'agit juste d'englober toutes tes variables dans un ensemble comme un système de coordonnées sauf que dans mon cas il ne s'agit pas forcément de quelque chose de géométrique.

il te reste à démontrer que la pente ne change pas mais oui

Tu me demandes sérieusement de prouver que $\dfrac 95$ est une constante ?

Nonon c'est juste que tu partais de l'hypothèse que pour tout couple (x,y), la pente est égale à dy/dx, et oui c'est très facile à démontrer c'est juste par réflexe que je faisais cette remarque désolé.

Quelle est l'opération et la fonction f ? Après ouais, un exemple non linéaire m'intéresserait aussi . Quoiqu'il en soit comme je l'ai marqué dans le tuto il s'agit d'un moyen de retrouver la formule finale même si elle se simplifie après coup.

J'ajouterais aussi plus tard un petit passage sur le fait que cette méthode doit être utilisée exclusivement quand on peut mettre des ensembles ("systèmes de données") en bijection et que des fois le problème doit être modélisé autrement.

Bah c'est ça le problème, le concept est tellement évident / trivial qu'il n'a jamais été nommé à ma connaissance, j'ai sorti ça mais je suis prêt à changer (cf. premier post). Il s'agit juste d'englober toutes tes variables dans un ensemble comme un système de coordonnées sauf que dans mon cas il ne s'agit pas forcément de quelque chose de géométrique.

On appelle ça une dimension. Mais je comprends toujours pas ce que tu essayes de mettre sous ton terme "systèmes de données", et j'ai l'impression que c'est pas super clair pour toi non plus. Peut être qui faudrait que tu essayes vraiment d'énoncer ça clairement, ça te permettrait de mieux cerner ce que tu veux aborder dans ton tuto.

Quelle est l'opération et la fonction f ?

Euh… Sérieusement ? L'opération est une multiplication matricielle, et la fonction est $f:x\mapsto Ax$.

Après ouais, un exemple non linéaire m'intéresserait aussi

Bah ça, t'en as à la pelle, $y=ax^2+bx+c$ déjà.

Désactivation de la beta du tutoriel Les systèmes de données comme outil de transformation

Pour plus d'informations envoyez-moi un message privé.

Oyez oyez les agrumes !

Je vous annonce avec plaisir la ré-ouverture de la bêta du contenu « Transformez vos données avec les référentiels ! » ! Je vous souhaite une agréable lecture à l'adresse suivante :

Merci pour votre participation.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l'adresse suivante :

Merci d'avance pour vos commentaires.

Bonjour,

Je reprends à mon compte le message d'adri1 :

En fait, je ne comprends pas ce que tu essayes de faire passer comme message.

J'ai beaucoup de mal avec le rythme. Il te faut l'équivalent de 5 pages (dixit un copier-coller dans un traitement de texte) pour traiter le problème simplissime Fahrenheit / Celsius.

L'exemple du mitigeur derrière n'apporte pas grand chose, je trouve (ou alors je passe à côté d'un truc fondamentale).

Ton passage Résumé de la démarche pour créer un référentiel devrait arriver bien plus tôt, afin qu'on comprenne plus clairement ce que l'on fait.

Pour finir, le terme référentiel utilisé dans ce contexte est-il usuel ? J'ai toujours entendu dire, en physique, changement d'unité pour Fahrenheit / Celsius, ce qui me laisse assez septique.

Ca marche je vais mettre le résumé plus tôt. Le tutoriel a l'air dense ; je suis en train de le remettre en forme en moyen tutoriel pour qu'il soit plus léger et plus clair. Pour le rythme, le tutoriel est fait pour les débutants (je pense viser un public au minimum lycée / fin collège), chaque notion doit donc être bien assimilée et montrée avec plein d'exemples.. Pour les confirmés j'espère que la navigation plus pratique en forme de moyen tutoriel leur permettra de sauter les parties trop simples .

L'exemple du mitigeur apporte un référentiel à deux variables, sinon on pourrait tout mettre sous la forme "c'est une unité, je fait des changements d'unités" (les référentiels sont une généralisation de cela, en gros).

C'est moi qui "invente" cette utilisation du terme référentiel, donc non c'est pas usuel. En même temps je ne trouve pas beaucoup de ressources sur le concept que je présente (à part la vidéo en introduction), donc j'introduis mes propres termes.

Pour être honnête, j'ai l'impression que tu n'as pas suffisamment cerné ce que tu souhaites présenter, ce qui expliquerait que ce ne soit pas clair pour nous lecteurs non plus…

L'exemple du mitigeur apporte un référentiel à deux variables, sinon on pourrait tout mettre sous la forme "c'est une unité, je fait des changements d'unités" (les référentiels sont une généralisation de cela, en gros).

J'aurais plutôt tendance à dire que ton exemple du mitigeur est un changement de paramétrisation, que tu peux voir comme un changement de repère et non de référentiel. Un changement d'unité peut également être vu comme un changement de repère.

Ce que moi et semble-t-il Gabbro ne comprenons pas, c'est ce qu'apporte la lourde machinerie que tu proposes pour faire un simple changement de repère, qui dans le deux cas présents n'est qu'une bijection linéaire. On peut difficilement faire plus simple, mais tu construis quelque chose de compliqué sans en montrer l'intérêt.

Ça me semble même plutôt inutilement compliqué (ou plutôt source de confusion) de présenter un changement d'unité comme étant un changement de repère. La seule fois où le voir comme ça m'a été vraiment utile pour comprendre quelque chose, c'était en lisant cet excellent article. On est assez loin des besoins du débutant à qui il faudrait 5 pages pour absorber la conversion Fahrenheit/Celsius.

La technique présentée dans le tutoriel apparaît inutile car les deux premiers chapitres présentés ici sont une introduction (il n'y a donc pas encore de vraie utilisation dans ce que j'ai publié là, qui justifie de suivre le concept introduit).

J'en déduis donc qu'il faut que j'attende un peu pour publier le tutoriel, le temps d'écrire la suite. J'ai presque fini le prochain chapitre avec l'utilisation en maths 1D, sauf que ça présente un vrai intérêt à partir de la 2D (sinon on revient sur une compréhension "c'est une unité" alors que "c'est un changement de repère" est le bon message que j'ai envie de faire passer).

"Pour être honnête, j'ai l'impression que tu n'as pas suffisamment cerné ce que tu souhaites présenter, ce qui expliquerait que ce ne soit pas clair pour nous lecteurs non plus…" On verra donc avec la suite des chapitres .

Sur le vocabulaire employé, "J'aurais plutôt tendance à dire que ton exemple du mitigeur est un changement de paramétrisation, que tu peux voir comme un changement de repère et non de référentiel" tu as tout à fait raison mais là j'aimerais introduire le concept de "référentiel" (puisque ce que j'explique n'a pas vraiment de nom ! à part principe du parapluie qui est aussi un nom donné au pif par quelqu'un) indépendamment de sa signification en mécanique… J'ai pas envie d'utiliser la notion de repère puisque trop ancrée dans la mécanique et la géométrie. La notion de "paramétrisation" me plaît par contre (mais remplacer dans le tutoriel "référentiel" par "système de paramétrisation" me semble trop lourd).

Pour l'article oui je l'avais lu car il était sorti dans la discussion sur l'analyse dimensionnelle, très intéressant ! (mais je suis perdu dans les commentaires de l'article ça part trop loin)

tu as tout à fait raison mais là j'aimerais introduire le concept de "référentiel" (puisque ce que j'explique n'a pas vraiment de nom ! à part principe du parapluie qui est aussi un nom donné au pif par quelqu'un) indépendamment de sa signification en mécanique… J'ai pas envie d'utiliser la notion de repère puisque trop ancrée dans la mécanique et la géométrie. La notion de "paramétrisation" me plaît par contre (mais remplacer dans le tutoriel "référentiel" par "système de paramétrisation" me semble trop lourd).

Euh… C'est plutôt l'inverse en fait. Un repère est un objet mathématique, et ce que tu fais porte un nom, c'est un changement de repère. La notion de référentiel, elle, est utilisée en mécanique pour désigner ce à quoi tu attaches un repère pour décrire le mouvement des objets (exemple classique, un référentiel terrestre avec un repère monodimensionnel parallèle à $\vec g$ pour décrire simplement une chute libre verticale).

J'ai envie de développer un concept maths / algo et pour ce faire je privilégie un vocabulaire vierge dans le domaine des maths : référentiel me semble donc plus approprié que repère / changement de repère qui ont une connotation géométrique.

Si je comprends bien, il y a deux postes tu voulais utiliser "référentiel" parce que "repère" a une connotation physique, et maintenant que tu réalises que "référentiel" a une connotation physique, tu ne veux pas utiliser repère parce qu'il aurait d'après toi une connotation géométrique ? Un repère est simplement une origine et une famille de vecteurs qui sert de base à un espace de paramètres dans lequel le système que tu souhaites décrire peut se balader avec plus ou moins de degré de liberté. Changer les vecteurs de base ou l'origine pour décrire un même objet, c'est changer de repère. Tous ces concepts sont déjà très bien définis, tu n'es pas en train d'inventer un nouveau concept mathématique nécessitant l'utilisation d'un vocabulaire nouveau.

J'abonde dans le sens d'adri1. Ce que tu fais n'est pas un changement de référentiel, et l'appeler ainsi risque plus d'apporter de la confusion qu'autre chose.

J'ai essayé de dire plusieurs choses dans la même phrase le message est mal passé. Oublions le sens qu'ont ces mots en physique.

Repère a un sens en physique ET (surtout) en maths !

Oui parce que déjà clairement défini en maths.

Mon concept de référentiels est plus général, d'où l'intérêt de ne pas utiliser le vocabulaire "repère" ; on pourrait croire que le tutoriel porte sur quelque chose de géométrique.

Comment tu peux dire ça alors qu'un référentiel et un changement de référentiel n'existent pas en maths / algo / info ? Je développe un concept, il me faut un mot, je profite de la polysémie et cela ne me gêne pas. Maintenant effectivement dans les 10% du tutoriel où il y aura de la physique il faudra que je précise que je ne parle pas de mécanique et de référentiels galiléens / terrestres / etc

Mon concept de référentiels est plus général,

En quoi ? Qu'est-ce que ton concept a de plus que les repères ? Avant d'avoir la prétention de mettre au point un concept que tu penses nouveau, soit sûr de connaître les concepts existant.

Reprenons l'exemple de ton mitigeur. Soit $\mathcal R(O, \hat T, \hat D)$ un repère sur l'espace des états du mitigeur, avec l'origine correspondant à un débit nul (pour lequel $\hat T$ n'est pas défini). Tout état du système avec un débit non nul s'exprime $\vec E=T\hat T + D\hat D$. On peut construire un second repère $\mathcal R'(O, \hat D_f, \hat D_c)$. Comme l'origine est la même et que les relations sont linéaires entre les différentes échelles, passer d'un repère à l'autre se fait à l'aide d'une matrice de passage. Si l'origine des deux repères n'est pas la même, il suffit d'ajouter une translation pour change de repère.

Maintenant, dis nous clairement ce que ce formalisme ne permet pas et qui justifie la construction d'un concept différent des repères.

d'où l'intérêt de ne pas utiliser le vocabulaire "repère" ; on pourrait croire que le tutoriel porte sur quelque chose de géométrique.

Je ne pense pas qu'une personne suffisamment "mûre" mathématiquement parlant pour voir un changement d'unité comme un changement de repère aura besoin qu'on lui précise que les repères ne se limitent pas à la géométrie. C'est un peu comme si quelqu'un faisant un cours sur la multiplication matricielle s’inquiétait parce que le mot multiplication pourrait faire penser à du calcul élémentaire. Par contre, il y a de fortes chances que tu ais besoin de lui expliquer que ce que tu appelles référentiel est en fait un repère.