Michaël a écrit 2935 commentaires

D'habitude, on définit une variété comme étant un ensemble avec des cartes provenant d'ouverts de

Or on définit quand même souvent des variétés avec des cartes ne provenant pas de . Par exemple lorsqu'on travaille sur des sous-groupes de Lie, on prend souvent la carte exponentielle provenant de l'algèbre de Lie.

On résout cette difficulté en prenant des coordonnées dans l'algèbre de Lie. Tous les choix de coordonnées mènent au même atlas maximal (dans la terminologie de Lafontaine) donc à la même structure différentielle — donc on peut se contenter de définir les cartes en utilisant l'espace vectoriel qu'on veut.

Autrement tu peux aussi dire que tu vois ton espace vectoriel préféré comme une variété différentielle (avec la définition en ) et que tu transportes la structure sur ton objet d'étude grâce aux “cartes” ( ouvert de ). Ça marche aussi si tu veux changer d'espace vectoriel pour chaque carte.

Bien que je sois un psychorigide sur les abus de notations, […]

Il me semble que tu as un prédécesseur, Arnaudiès dont les cours de maths sont très pointilleux sur les notations — probablement pour être d'une grande clarté pour les débutants.

Questions sur l'intégration des formes différentielles

Pour tes questions d'intégration, on travaille normalement avec de partitions de l'unité qui sont localement finies, comme dans la fiche Wikipédia https://fr.wikipedia.org/wiki/Partition_de_l%27unité

C'est ce qui te permet de permuter tes intégrales et tes sommes. C'est peut-être plus facile de passer par une construction intermédiaire en disant que:

1. Tu intègres tes formes par rapport à une partition de l'unité
2. Étant données deux partitions de l'unité et tu déduis une nouvelle partition de l'unité et tu démontres que ta définition donne le même résultat pour ces trois partitions de l'unité
3. Tu conclus que ta définition ne dépend finalement pas de la partition de l'unité choisie.

Alors je n’y connais rien en maths et j’ai été voir le livre en me demandant si c’était accessible aux néophytes

Le public est les gens qui préparent l'agrég de maths, donc qui ont fait 4 ans de maths de façon intensive. Plutôt pas des néophytes donc.

Si tu as une certaine curiosité mathématique tu peux lire avec un certain plaisir les mathématiques d'école de Daniel Perrin, ou Euclid and beyond de Robin Hartshorne (en anglais). Des lectures plus difficiles mais peut-être sympas aussi sont:

• Concrete Mathematics, Knuth (celui de TeX)
• cours d'analyse de Roger Godement,
• Analysis by its history par Hairer et Wanner
• Exercices de Polyà et Szegö

Je ne sais pas trop ce que tu appelles séries formelles en en donnant une valeur à (qu'est-ce qu'il y a de formel à ta série?).

Les séries formelles à coefficients dans ont un chouette corps des fractions, qui est isomorphe au corps des séries de Laurent (séries de type “série formelle divisée par une puissance de la variable”).

(La partie fraction -> Laurent se fait en décomposant le dénominateur en éléments premiers entre eux puis en utilisant une identité de Bezout.)

Bien-sûr on est libre de définir les symboles comme on veut, mais si on s'amuse à dire “posons une racine carrée de ” ça fait un peu “d'abord je dis ce que je veux, na na na na nère.”

Habituellement on note le sous-anneau de engendré par et le nombre complexe , ce sous-anneau est en fait un corps, l'inverse de étant .

En tout cas, la notation \mathbb{K}[a] n'a de sens que si on est tacitement d'accord sur un sur-corps de \mathbb{K} contenant a. C'est tout mon point.

Euh ben quand tu dis “je peux vous trouver une structure où tu dis un peu plus, non?

Je me demande si je suis le seul au monde à avoir remarqué que, quand on parle de l'extension de corps , ce qu'on obtient dépend du corps ambiant dans lequel sont et a.

Ça dépend de ce que tu veux dire par “ce qu'on obtient”?

Par exemple si je prend Il n'y a pas de problèmes à construire un sur-corps de dans lequel .

Qu'est-ce que tu racontes? Si dans ton tu n'as pas on peut se demander pourquoi tu veux noter cet élément .

On devrait écrire […]

Je suis moyennement d'accord avec toi. Oui ces notations sont suffisamment ambiguës pour être donner du fil à retordre aux étudiants qui doivent non seulement apprendre des concepts difficiles mais en plus la manière particulière de les écrire. La manière classique de s'en sortir c'est de ne pas utiliser x et y comme coordonnées de points, on peut par exemple utiliser des indices pour distinguer. Si on est fan de formalisme — donc peut-être pas un étudiant — on peut tout faire marcher en disant que x et y sont les fonctions coordonnées du point, on écrit alors

(égalité entre fonctions) et on n'a aucun problème de cohérence (et oui on peut dériver par rapport à x). C'est cependant plus facile de ne pas trop rentrer dans les détails, et si ces notations existent et sont utilisées par les mathématiciens professionnels, c'est parceque les avantages dépassent les inconvénients (concision, lisibilité de textes relativement anciens, etc.)

Je ne sais pas si tu es familier de la fréquentation des lieux de types comptoir de bistrot ou de PMU, mais twitter c'est exactement ça, mais à l'échelle de la planète.

Sinon j'aime bien aussi “le tout-à-l'égoût de la liberté d'expression” mais ça ne tient pas non plus compte du service rendu et du modèle financier de Twitter/Facebook. (Le service rendu c'est la manipulation, pour ceux qui dorment au fond de la classe.)

Oui, et Xfce est 25% (23%) plus léger que Gnome. Vu l'expression de départ (Gnome n'est pas plus lourd) ce qu'on attend c'est une phrase dont le sujet est Gnome plutôt qu'une dont le sujet est Xfce.

[…] entre 1.3g (gnome) et 1g (xfce) […]
"[Gnome] pese […] plus lourd", c'est quand meme une bonne difference, 25%

À vue d'œil j'irai même jusqu'à dire que Gnome est 30% plus lourd que Xfce. ;-)

Mon point n'est pas qu'il y a un bug (ça arrive), mais que la communauté autour des BSD me semble trop petite car sinon, les bugs auraient été trouvé plus tôt.

C'est la communauté des utilisateurs d'Ansible et BSD qui est trop petite… perso ça fait depuis longtemps que j'ai arrêté d'utiliser Ansible et je ne m'en porte que mieux… (terraform, shell scripts).

Outre les références généralistes que propose Bilbo une bonne idée est de lire des scripts utilisés dans des projets open-source. Par exemple:

• Scripts dans FreeBSD
• Scripts d'installation pour TeXlive, Anaconda, et autres grogiciels
• Scripts de configuration Dockerfile

À mon avis un des grands défauts de beaucoup de scripts, tutoriels et références, dont le Advanced Bash Scripting est qu'ils approchent le Shell comme un langage de programmation de type C, Python et essaient de répondre à des questions de type “comment utiliser des tableaux en shell". Je recommande plutôt d'aborder le shell comme un langage à part qui a ses idiomes propres.

Un des poncifs de la programmation est l'expression ”qu'il ne faut pas réinventer la roue” — négligeant que celui qui sait réinventer la roue est au passage tout sauf un potiron. C'est en suivant un peu aveuglément ce poncif mille fois ressassé qu'on se retrouve avec des milliers de dépendances banales et parfois un peu triviales, or comme tu le dis

Il est de bon ton de nos jours pour chaque langage de programmation qui se respecte de débarquer avec un système intégré de dépendances

et c'est justement difficile d'écrire un bon système de dépendances! Or là tout le monde réinvente la roue, encore et encore! Il faut aussi souligner que le problème de la résolution de dépendances des paquets n'est pas facile, c'est même un problème NP-complet et avec un peu de soin on peut montrer que le problème de l'installation est équivalent au problème de la satisfaisabilité d'un polynôme booléen. Autrement dit, c'est exactement le type de problèmes où la réinvention de la roue.

Pour le problème concret qui pousse à cela c'est qu'on voit malheureusement que la distribution de logiciels sous Linux est un cauchemar et qu'il n'y a pas de solution satisfaisante offerte par les gestionnaires de paquets “traditionnels”. (Au passage les systèmes de ports à la BSD ou MacPorts eux tirent assez bien leur épingle du jeu pour la distribution de logiciels “maison”.)

Une solution pragmatique est celle d'utiliser un environnement de type docker pour distribuer “le python officiel” de l'équipe pour le projet mais cela ajoute un petit peu de complexité dans le cycle de développement.

d'un point de vue marketing il était plus opportun de patienter sagement et de se voir considéré forcés par l'EU plutôt que de faire un changement unilatéral et voir des clients gueuler.

Sans parler de clients gueuler à qui force à faire quoi, si on sort un produit qui doit respecter une norme légale, c'est plutôt bien de connaître la norme en question.

Le gros avantage que je vois ici, c'est surtout que la Région peut agir comme gardien d'un niveau de qualité de service minimum à respecter.

Ça peut-finir en “round-robin” à la fin de chaque exercice… comme ça l'usager a un service pourri, qui circule entre trois entreprises moisies qui perdent le marché chaque année mais le retrouveront dans deux ans lorsque les deux autres l'auront aussi perdu. (Entre-temps elles auront fignolé un petit powerpoint de chez mamie pour dire qu'elles ont amélioré la stratégie, pris un nouveau CEO, etc.)

j'avoue je ne sais pas si c'est une référence précise. mais c'est à prononcer "qwalitaye" et je trouve ça rigolo.

Moi aussi je trouve ça rigolo sans avoir de référence précise. Je suis toujours parti du principe que c'était une petite moquerie contre le franglais d'entreprise grand-gagnante.

Je ne pense pas qu'il soit nécessaire que chacun connaisse parfaitement la cli de docker. Seulement, ton exemple sur Git est juste. Oui, avoir une GUI permet à des profanes de s'en servir. Mais d'un autre côté, ça empêche aussi les gens d'en découvrir plus sur l'outil.

On utilise un outil pour faire quelque chose de précis: pour mon travail de développement je suis plutôt du genre “power-user/scripteur” qui va préférer les interfaces textuelles et les outils CLI pour à peu près tout: git, sql, docker… mais pour des tâches spécifiques comme par exemple faire une validation des critères d'acceptation, discuter un patch, faire une code review, explorer une BDD avec un collègue, et d'autres… les outils graphiques permettent une approche différente de la CLI.

Je trouve que la CLI est assez impitoyable avec la baisse de concentration qui est inéluctable si on n'est pas la personne qui manipule le système, les interfaces graphiques vont au contraire aider à se raccrocher en affichant plus de contexte et en montrant visuellement qu'on change de sujet, pour donner des exemples. Pour la productivité et l'automatisation, c'est bien-sûr la CLI qui garde souvent la main haute, mais ce n'est pas toujours le critère principal!

[…] le codage classique des entiers naturels […]

Je suppose que tu fais référence à la construction de Von Neumann mais il est aussi très commun de partir de l'axiome de l'infini. En bref la méthode fonctionne en énonçant l'axiome de l'infini comme suit:

Il existe un ensemble X qui n'est pas l'ensemble vide et
une application injective qui n'est pas surjective.

Puis on choisit un un point qui n'est pas dans l'image de et on prend l'intersection de toutes les parties -stables de qui contiennent , ce qui nous permet ensuite de suivre la méthode de Peano.

Pour les lexers simples l’approche typique est d’utiliser des fonctions mutuellement récursives, type read_whitespace, read_identifier, read_immediate_string , read_expression, etc. Comme Python ne sait pas faire l’optimisation de récursion terminale, on s’en sort en faisant comme l’OP. Bon courage!

Je cherche à mettre en place des environnements test et production pour créer un site web avec django mais je n'ai jamais travaillé en situation réelle de "production" dans une boite informatique.

Pour avancer dans cette direction je recommande une approche par petit pas.

Avant de commencer il faut faire quelques choix techniques, ma proposition serait la suivante:

1. Faire du développement sans branches, cela élague la complexité. (trunk-based development) Cela a des conséquences sur la façon dont travaille l'équipe mais si l'équipe c'est toi, on peut sauter cette partie. :-)

2. Faire du déploiement continu. Un commit poussé est un commit déployé.

Avant de te lancer en production, si tu n'es pas familier de la technique, c'est plus facile de créer un environnement de laboratoire et une technologie comme docker permet de faire cela assez facilement.

Tu crées 3 environnements (docker compose) un pour la chaîne de livraison (pipeline), un pour le bac à sable (sandbox) et un pour la production (production). Dans la pipeline il ya un logiciel de CICD qui tourne, comme Jenkins ou GoCD par exemple. Dans tes environnements sandbox et production il y a le classique TIER3: Jango, BDD, et HAPROXY ou APISIX. Une fois que ton laboratoire est opérationnel tu peux le modifier pour le faire marcher ailleurs.

-est ce que je fais un github action qui déploie ma branche production automatiquement sur un serveur production et un github action qui déploie ma branche "test" automatiquement sur un autre serveur ou est ce que je met mes deux environnement test et prod sur le meme serveur?

Test et prod sont sur des serveurs différents: est-ce que ton environnement de production a le droit de planter ou de fonctionner en performance dégradée si tes tests mettent la machine ko? Est-ce que la bdd de test a le droit d'arriver en production suite à une erreur de configuration? Si tu veux rendre ces erreurs aussi peu plausibles que possible, utilise des serveurs différents et des droits d'accès différents. (Par exemple sur Gandi ou AWS: des comptes différents).

-comment faire référence à la meme base de données dans django pour le test et la production?

Tes environnements sont séparés, donc cela n'a pas le droit d'arriver. Maintenant, tu peux vouloir utiliser un snapshot de la BDD en production dans les tests. Ta pipeline doit pouvoir initialiser la BDD avec un snapshot arbitraire. Ensuite il faut s'équiper pour éliminer plein de choses des snapshots: artefacts cryptographique et tokens d'authentification, données personnelles, données business. (C'est en principe plus facile de créer des données synthétiques que d'adapter les données de production pour les tests.)

-Dois je avoir 3 bdd ? (une test, une production et une de sauvegarde) ?

En général deux (si tu travailles sans redondance), des snapshots si possible et des sauvegardes fichier.

-je comprend comment pousser du code sur des branches distinctes, mais j'ai du mal à comprendre comment git gere les branches en local : est ce que je peux configurer git pour que quand je modifie mon code dans un repertoire ca ne le modifie que sur une des branches? ou dois je distinguer un repertoire prod et un repertoire test ?

Quand tu modifies, du point de vue de git (commit) cela se fait toujours sur la branche en cours. Tu n'as pas forcément besoin de travailler avec des branches, et surtout pas pour distinguer "test" et "prod": cela se fait via un fichier de configuration ou des variables d'environnement.

Pour démarrer, fait des petits pas, un environnement de laboratoire. Ton premier test est de faire un cURL qui marche sur ton site déployé. Bonne chance!

J'explique l'exemple de Gil Cot. :-)

Si tu ajoutes 1 mois au 31 janvier, il y a plusieurs façons d'interpréter le résultat, et on les trouve toutes en pratique.

• Comme c'est le dernier jour du mois, on dit que le bon résultat est le dernier jour de février.
• On dit qu'un mois c'est trente jours, donc on arrive le 1 ou 2 mars.

Si on se limite aux premiers jours du mois, il n'y a pas de difficultés à ajouter un mois ou une année, mais dès qu'on s'approche de la fin du mois il faut convenir d'une convention pour résoudre les cas peu clairs. Quel jour est désigné par:

• 12 mois après le 29 février
• 1 an après le 29 février
• 1 mois après 31 janvier
• 2 mois après le 30 décembre

etc.

Les difficultés résident dans ce que les conventions ne sont pas additives (ajouter 12 fois un mois et une fois 12 mois ce n'est pas forcément pareil) et que l'ordre dans lequel on ajoute respectivement des années, des mois, des semaines et des jours à une date (p.ex. dans 2 ans, 3 mois et 6 jours) change parfois considérablement le résultat.

J'ai grâce à toi un compte gitlab maintenant!

Quand-même je ne peux pas m'empêcher de faire la remarque qu'avant le : ce n'est pas une espace mais une espace insécable et qu'en ce qui me concerne j'ai toujours considéré que c'est le travail du logiciel que j'utilise de l'insérer:

https://github.com/foretspaisibles/cadet/blob/master/locale/punctuation/fr.tex#L14

Tu devrais formaliser cette réponse et l'ajouter à la base de données.

Ah que ça fait du bien de lire ton commentaire, les pieds bien sur Terre! :-)

J'aimerais que mon genre soit réellement une donnée accessoire, sans aucun intérêt dans la majorité des situations.

Ce souhait n'est pas à l'agenda du néoféminisme et une des raisons qui a poussé Annie Le Brun à écrire “Lâchez tout!” à la fin des années 70, un ouvrage ravissant! (Comme “Le trop de réalité”.)

Le problème est bien en amont de ça. Il faut permettre à chacun de trouver comment exprimer ses limites et de trouver comment les respecter collectivement. Tout cela est propre à chaque communauté, doit être reconstruit et ré-interrogé sans cesse.

Une difficulté est que dans beaucoup de ces communautés persistent des structures de pouvoir archaïques, c'est encore fréquent dans le milieu universitaire, hospitalier, les orchestres, les entreprises anciennes, qui semblent faire plutôt moins bien que le reste de la société.

Pour l'informatique, j'ai pu entendre Brigitta Böckler retracer l'historique de la “masculinisation” du milieu aux USA et je me souviens des deux faits saillants suivants:

1. La première communauté de grande importance, recrutée rapidement par IBM qui avait remporté un contrat d'état, était constituée de gens ayant un profil un peu particulier (en gros l'annonce disait “Are you playing chess? Bridge? You are the man to ride tomorrow's giants!” FR ”Jouez-vous aux échecs? Au bridge? Vous êtes homme à diriger les géants de demain!”.

2. Dans l'apparition de la micro-informatique personnelle, le matériel publicitaire est ciblé sur les petits garçons et leurs papas.

Ah ah c'est effectivement le titre de l'image! :-)

Le livre est vraiment très intéressant, au fait!