Requêtes de tutoriels

Je veux bien relire le tuto, je l'ai déjà dit. Mais jen 'ai pas le temps de le rédiger.

À noter : le tutoriel sur Swift est en cours de rédaction par GuillaumeDIDIER, avec Dominus Carnufex et moi-même en tant que correcteurs.

Info : Le tutoriel sur le Powershell est en cours d'édition par Thiht et moi même. Si vous avez des idées précises, faites les moi parvenir et je verrai pour les ajouter !

Super ! Je vais surveiller la beta zone pour pouvoir vous relire dès que vous l'y mettrez.

Adimensionnement d'un problème

j'ai déjà pratiqué alors selon le tempsq ue j'ai au moment où le projet prendra forme, je peux être coauteur ou relecteur.

C'est une idée intéressante, mais je ne comprends pas quelque points:

• qu'est-ce que tu veux dire par "dimensions issues des algorithmes" ?
• que viennent faire les notions d'ordre de grandeur et de système d'unités naturelles ? Je veux dire par là que je comprends parfaitement qu'il y a un lien avec l'analyse dimensionnelle, mais ce sont des sujets tellement vastes à eux tout seul que je ne suis pas sûr que ce soit une bonne idée de les ajouter en plus, ça risque de faire un énorme pavé difficile à gérer côté auteur comme lecteur.

Tu as raison ces sujets sont un peu trop vastes, il s'agirait d'introduire ces notions seulement dans le contexte du tuto (quand on aborde le sujet sous l'angle physique on pourrait parler des unités naturelles) mais c'est vrai que c'est pas évident.

J'imagine que la première version du tuto ne parlerait que des liens 2 à 4 et après il faudrait arriver à consolider tous ces sujets dans une même explication.

Je pense même qu'on pourrait y introduire la notion de degré de liberté, mais je pars peut être un peu loin là (en tout cas un autre tuto sur ce sujet pourrait être cool)..

La question de l'ordre de grandeur vient avec notre compréhension des différentes variables qui interviennent dans nos équations / algorithmes. Le même "sens physique" qui nous permet d'aborder de façon grossière un problème physique (pouvoir dire très rapidement que le problème est insoluble ou difficile ou mal modélisé) pourrait aussi servir en maths / algorithmes (pour comprendre le problème, bien gérer les intervalles de variation des variables, et aussi par exemple pour réfléchir à la complexité de l'algo - à son ordre de grandeur).

Fournir un sens aux variables dans les algos me parait capitale. Personnellement ce que je trouve assez dur c'est déjà de leur fournir un nom qui soit assez explicite, peu compliqué (facilement retrouvable d'instinct reregarder le code) et qui représente véritablement la nature de l'information contenue dans celle-ci et ce qu'on peut faire avec elle.

Vérifier les formules

Exemple tout bête, mais si dans un algo on ajoute entre elles des quantités de nature différente, il faut directement se poser la question de savoir si cela a un sens. Et si la somme a bien un sens, c'est qu'il y a une conversion d'unité entre les deux, donc peut être un coefficient caché "à touiller". Il arrive parfois qu'on introduise un coefficient entre nos différentes variables (on pourrait donc rajouter dans l'article Fudge factor dans la liste ?).

De façon plus générale on peut vérifier qu'une formule est correcte, que les différentes variables interviennent de façon cohérente (par exemple regarder que les coefficients du polynôme que l'on vient de calculer sont tous à la bonne unité).

Count / Index

Dans la programmation en générale aussi on a tous le temps des compteurs de boucle / indices de tableaux. Connaître la nature de cette variable aide à bien la nommer séparément des autres (souvent une seule lettre en minuscule i,j,x,y,z etc..), la repérer facilement dans un code et repérer son utilité / son usage rapidement.

Les entiers qui désignent le nombre d'éléments dans une collection / un tableau aussi peuvent faire l'attention d'un nommage particulier : dans certains bouquins de programmation ils conseillent par exemple de les suffixer par Count tandis qu'il conviendrait de suffixer les indices par Index (enfin ce que l'on veut du moment que l'on a la même convention dans tout nos codes). Je trouve que cette séparation Count/Index est importante, cela permet de différencier des variables de même type (entier ici).

Objet

Dans le cadre de la POO, on peut remplacer "dimension physique" par le nom de la classe de l'objet en question et en prenant en compte les question d'héritages. Dans l'algo basique de tri par exemple on ne fait que des affectations d'éléments de même classe, et l'on ne peut comparer que des éléments qui sont comparables entre eux. Ce genre de réflexion amène à re réfléchir en permanence notre modélisation du problème en classes.

Note

Comme tu peux le voir ce tutoriel introduirait une façon de penser la programmation, alors forcément ça ne plairait pas à tout le monde, surtout ceux qui ont déjà de l'expérience et qui ont leur propre méthode de travail.

Aussi, je ne sais pas si cette vision des choses s'applique à tous les problèmes mathématiques (et donc algorithmiques), moi même je suis encore en train de réfléchir à cette méthode de travail. Je me suis en tout cas rendu compte que c'est souvent comme cela que je travaillais ; peut-être quelqu'un qui a plus d'expérience que moi pourrait écrire ce tutoriel voilà pourquoi je le marque ici.

Le lien sur le théorème π st cassé

Problème de conversion du caractère pi.
Ce lien fonctionne : https://en.wikipedia.org/wiki/Buckingham_π_theorem

Quelle idée de vouloir mettre un $\pi$ dans une URL. Oh, wait?

[/HS]

Je pense même qu'on pourrait y introduire la notion de degré de liberté, mais je pars peut être un peu loin là (en tout cas un autre tuto sur ce sujet pourrait être cool)..

Je ne vois pas comment tu peux parler du théorème de $\pi$ Buckingham sans aborder les ddl.

OK, je vois ce que tu veux dire pour le côté algorithmique. Pour moi, c'est quelque chose qui devrait être dans un tuto à part et qui viendrait se greffer sur la base théorique de l'analyse dimensionnelle. Cette dernière est suffisamment large pour ne pas avoir besoin de partir dans des exemples capillotractés et dont la pertinence serait potentiellement très discutable. Je pense à ton exemple sur les classes, on peut sans problème définir des lois de comparaisons qui font passer un objet incroyablement complexe pour un simple entier, surcharger les opérations élémentaires pour ajouter des pommes avec des oranges, etc. Se priver de ça sur la base de l'analyse dimensionnelle, je ne sais pas si c'est vraiment la bonne façon de pondre un bon code en objet (si c'est faisable ). Après tout, le but d'un objet, c'est pas justement d'abstraire absolument tout ce qui passe dedans à l'intérieur pour que son utilisateur puisse s'en servir sans avoir à se poser de questions ?

En fait, je pense que la programmation objet est fondamentalement trop mal foutue et pas assez rigoureuse pour se prêter à une analyse théorique aussi pointue pour déterminer la bonne façon de coder avec.

Ouais pourquoi pas faire un tuto physique et maths et un autre tutoriel séparé sur des méthodes de programmation dont quelques idées seraient issue du premier tuto.

En ce qui concerne la POO je me plaçais du point de vue du codeur qui conçoit et utilise pour lui même ses propres classes. Effectivement si tu te places du pdv du simple utilisateur (genre qui importe une bibliothèque) il ne faut pas avoir ce genre de raisonnement je suis d'accord.

( et je ne prétends évidemment pas faire un tuto sur "la bonne façon de coder" )

En tout cas j'adore l'analyse dimensionnelle ça fait parti des trucs que j'aime bien en physique (c'est à tort négligé en mathématiques d'ailleurs..), c'est intuitif et concret, mais je n'ai pas le temps d'écrire quelque chose là dessus.

En tout cas j'adore l'analyse dimensionnelle ça fait parti des trucs que j'aime bien en physique (c'est à tort négligé en mathématiques d'ailleurs..)

En même temps en maths additionner des aires et des longueurs ça gêne personne (genre dans un polynôme).

En plus ce n'est pas pour les mêmes besoins, je vois pas de situations en maths où une analyse dimensionnelle serait possible et utile.

En même temps en maths additionner des aires et des longueurs ça gêne personne (genre dans un polynôme).

Tu sembles oublier les coefficients. Si $y=ax^2+bx+c$, la dimension des coeficients $a$, $b$ et $c$ permet d'éviter d'ajouter des aires et des longueurs (ou des puissances différentes de la dimension de $x$, peu importe), ce qui n'a pas le moindre sens (même pour un matheux).

Mouais, pour les coefficients pourquoi pas. N'empêche que ça me semble compliquer une situation de dire ça, même si ça fait tenir debout ton point de vue.

En tout cas, je vois pas ce qui pose problème à additionner une longueur et une aire. Quand on représente les deux par un nombre réel, rien ne nous interdit de le faire.

J'avais des exemples je ne les ai pas marqué au fil du temps ; je te balancerais tout quand j'me souviendrais de ce à quoi j'ai réfléchi ces dernières années .

PS : c'est pas parce que tu peux le faire qu'il faut le faire. En plus je parlais d'une méthode de vérification de formules et de réflexion de problèmes algorithmiques

Quand on donne un problème comme le suivant :

« Quelle est la longueur d'un côté du carré dont l'aire égale la somme de la longueur de l'un de ses côté et 2 ? »

On fait exactement intervenir le fait qu'on peut additionner et comparer des nombres « d'origines » différentes.

Et alors ? Déjà tu fait intervenir un coefficient de conversion caché et ensuite tu fais ce que tu veux.

En tout cas, je vois pas ce qui pose problème à additionner une longueur et une aire. Quand on représente les deux par un nombre réel, rien ne nous interdit de le faire.

C'est parce que tu oublies qu'une longueur ou une aire n'est pas un simple nombre réel. Il faut lui attacher une dimension. C'est comme si tu étais dans un espace vectoriel et que tu essayes d'ajouter entre elles des composantes qui sont attachées à des vecteurs de base différents. Tu obtiens un résultat, mais tu sors de ton espace.

Évidemment, le problème ne se pose pas si tu as adimensionné l'espace, ce qui mathématiquement revient à écraser la dimension de l'espace dans lequel tes variables prennent leur valeurs.

« Quelle est la longueur d'un côté du carré dont l'aire égale la somme de la longueur de l'un de ses côté et 2 ? » On fait exactement intervenir le fait qu'on peut additionner et comparer des nombres « d'origines » différentes.

Non, parce que là tu es dans un espace adimensionné, sinon la réponse dépendrait du système d'unité.

Ça revient à ce que je disais. Ce point de vue fait tenir le votre mais complexifie bien une situation.

C'est parce que tu oublies qu'une longueur ou une aire n'est pas un simple nombre réel.

C'est bien plus simple de considérer qu'une longueur est un simple nombre réel.

L'interprétation physique que l'on donne ensuite a, en effet, besoin de dimensionnement. Mais mathématiquement parlant, ça n'est pas essentiel.