fmaz fmaz a écrit 494 commentaires

> En france, l'informatique est rattaché aux maths appliquées.

Alors pourquoi y a-t-il des sections différentes au CNU pour les maths appliquées et l'informatique.

Comment expliques-tu qu'après ma thèse, j'ai été qualifié en 25 (mathématiques) et en 27 (informatique) mais pas en 26 (maths appliquées) ?


Pour ceux qui lisent encore ceci mais qui ne comprennent rien à ce que je raconte, je recommence en plus verbeux. Après une thèse, pour pouvoir se présenter à un concours pour être enseignant chercheur, il faut envoyer un dossier au CNU qui dit si on a le droit. Le CNU est divisé en section pour éviter qu'un historien ne se retrouve avec un dossier de chimiste. Dans mon cas, des matheux ont accepté de me qualifier en 25 (resp. 27) et ont donc reconnu que ce que je faisais, c'était suffisamment des maths (resp. de l'informatique) pour eux mais pas en 26. Je ne fais donc pas de maths appliquées.

>Peut-être le fait que pour un humain résoudre un problème
> se fait en général en decoupant le pb en plus petit pb qu'il
> résoudra un par un et qu'il enchainera. Le paradigme
> procédural est donc naturel.
>
>Mais la programmation fonctionnelle,le commun des mortels
> a t'il les bagages mathématiques nécessaire pour
> comprendre la récursivité (suites reccurrentes), le lambda calcul, ...

C'est quoi pour toit le paradigme procédural ?
Le principe de la réccurrence, c'est exactement ce que tu décris comme étant naturel.
On pour résoudre pour n, on se rammène à un truc plus simple (n-1). Le tri fusion est un bon exemple.

Le problème avec tout ça, c'est qu'un informaticien, ça peut être l'administrateur système, l'analyste programmeur, ou le chercheur en théorie des graphes.

Pour prendre une analogie mécanique, cela revient au même que dire qu'un mécanicien ou qu'un ingénieur de chez peugeot sont tous les deux de mécanos.

Oui, l'utilisation des mathématiques est marginale chez ton concessionnaire automobile mais non l'utilisation des mathématiques n'est pas marginale dans les bureaux d'études automobile.

La grande majorité des informaticiens sont des mécaniciens de l'informatique. Oui, ils n'utilisent pas beaucoup de maths. C'est aussi compatible avec le fait que les maths prennent une part importante en informatique.

Bref.

C'est clair que mon code est lent. Cependant, j'ai écris le code ci-dessus en 5 minutes. Je n'ai pas essayé d'implémenter un algo à pas variable.
J'imagine que pour la méthode à coup d'intégrale elliptique, tu utilises un algo d'approximation et pour que le temps de calcul ne soit pas trop long, tu dois utiliser une méthode à pas adaptatif auquel cas, l'algo serait fondamentalement du même type. Pour ce qui est du nombre de points de l'ellipse, length(C) permet de régler le problème.

Par ailleurs, je ne prétends pas qu'asymptote, c'est de la merde et que metapost, c'est génial. D'ailleurs, quand on me demande comment je fais les figures, je mentionne metapost mais je conseille asymptote. Si je ne connaissais pas metapost, je commencerais par asymptote. Maintenant, au vu de l'utilisation et la connaissance de metapost que j'ai, asymptote n'apporte pas assez d'avantages pour que je saute le pas. Il manque juste le solveur linéaire dont je me sert beaucoup.

Bref.

Frédéric

P.S. je trouve amusant de me voir "trans-cité" dans un autre forum.

Pour ce genre de choses, je ne vois pas pourquoi tu n'approximes pas ton ellipse pas des segments de droites. Avec le truc super basique ci dessous, j'obtiens 3.14142 comme approximation de pi, ce qui n'est pas trop mal. En faisant un truc plus évolué avec un pas adaptatif, on peut très bien obtenir quelque chose de suffisamment précis et de rapide.

u=5cm;
beginfig(1)
path elipse;
pair a;

elipse=(u,0)..
for i=1 upto 99:
((u,0) rotated (3.6*i))..
endfor cycle;

s=0;
l=.01;
for i=l step l until length(elipse):
a:=(point i of elipse)-(point (i-l) of elipse);
s:=s+((xpart a)++(ypart a));
draw point i of elipse;
endfor;
show s/(2u);
endfig;
end

Je ne suis pas prof de math et je ne dessine donc pas de mediatrice...

Dans la pratique, je l'utilise surtout quand j'ai dessiné un bout de schéma que je stock dans une "picture" et que je veux placer ce schéma dans un dessin plus gros.

J'utilise ce genre de chose aussi quand je veux placer des boites les unes par rapport aux autres. Par exemple,

A.c=(0,0);

xpart(A.c-B.c)=0;
ypart(D.c-C.c)=0;
xpart(C.c)=xpart(.5[A.c,B.c]);
ypart(D.c-C.c)=ypart(C.c-A.c);;
ypart(A.c-D.c)=3xpart(B.c-A.c)=15cm;

drawboxed(A,B,C,D);

> Vu les équations que Metapost est capable de résoudre,
> c'est vraiment une fonctionnalité anodine.

C'est peut-être une fonctionnalité anodine mais c'est la seule raison pour laquelle je ne suis pas encore passé à asymptote.

Comme toujours, à partir du moment où on travaille avec un langage Turing puissant, on peut faire la même chose. Oui mais l'expressivité, c'est quelque chose d'essentiel.

Plus précisément, Metapost embarque un solveur d'équation linéaire. Ça permet de faire ça [1] sans faire trop de calcul.

Dans l'exemple que je donne, je dessine plein de pentagone ayant des côté en commun. J'ai donc les points z0 et z1 qui sont définit et j'aimerai calculer les points
z2, z3, z4 qui me finissent mon pentagone. Pour cela, il suffit d'écrire

z2-z1=(z0-z1) rotated 108;
z3-z2=(z1-z2) rotated 108;
z4-z3=(z2-z3) rotated 108;

et paf, les points z2, z3 et z4 sont calculés.

Si on veut une application affine qui transforme z1 et z2, z3 en z4 et z5 en z6, on écrit

transform T;
z1 transformed T=z2;
z3 transformed T=z4;
z5 transformed T=z6;

et après, on peut appliquer la transformation T à n'importe quoi.

[1] http://frederic.mazoit.free.fr/LaTeX_metapost/calendrier/

Ben, d'après ce que je comprend, ça permet de découpler le travail des graphistes et de les rendre plus productifs.

Tu définis un jeu "de base", avec le rendu mais pas encore toutes les options de jouabilité et les graphistes jouent avec. Tiens, à cet endroit là, c'est pas bô, j'm'a planté, j'ai confondu la texture du rocher avec cette du green du jeu de golf !
Le graphiste change la texture et c'est directement appliqué dans le jeu, sans avoir à recompiler quoi que ce soit, sans avoir à redémarrer le jeu, sans rien. C'est plus rapide, plus motivant pour les graphistes. Ils peuvent même travailler à plusieurs en même temps sur le monde => au final, tu obtiens un monde plus joli et mieux fini plus vite et à moindre frais.

Bref.

Moi, je ne sais pas.

Tu sais, les conteneurs, ça existe: matroska, divx, tar.

Il suffit, pour l'échange, de faire un conteneur qui emballe le fichier et les meta-données et hop, pas de problème.

Et je me dis pas que c'est pénible. C'est pénible si on a pas les outils pour gérer automatiquement ces conteneurs. Je rappelle que tous les hacks à la libmagic ou les heuristiques pour deviner l'encodage d'un texte, ça a un coût.

Mais, J'avais répondu à ce message !

Bon, je recommence.

Avec un FS, on peut accéder à un fichier de deux façons: avec l'inode, avec le chemin.

Ce que je propose, c'est changer la sémantique du chemin, pas de changer l'organisation des données sur le disque. Pour le boot initial, cela ne poserai donc pas de problèmes.

Par ailleurs, si on n'utilise que des chemins qui correspondent à des requêtes conjonctives, si chaque étiquette correspond à une vue et si on ne crée pas plusieurs fichiers avec le même nom et les mêmes étiquettes, on se retrouve avec exactement le comportement d'un fs classique. À moins d'essayer de faire des choses bizarre, un script ou un programme n'aurait aucun moyen de faire la différence.

L'aspect transition pourrait donc se faire en:
- changeant le fs ;
- puis modifier le reste pour utiliser les fonctionnalités offertes.

Maintenant, pour l'aspect lourdeur, si on a gardé des fs hiérarchiques et pas des bdd, c'est, je pense initialement pour une question de lourdeur puis par habitude. Il y a 20 ans, les ordinateurs ne pouvaient pas se permettre d'incorporer dans un fs, une base de donnée. Maintenant, quand on voit ce que font zfs ou reiser 4, je ne pense pas qu'une base de donnée pose des problèmes insurmontables.

Mais c'est clair que je n'ai pas envie d'une BDD qui explose, pas plus qu'un système de fichiers qui explose.

Pour l'aspect « transfert de fichiers », je ne vois pas le problème.

Quand tu envoies un fichier à quelqu'un, tu perds les informations que les droits, sur les différentes dates associées.

Si j'envoie une photo à quelqu'un, je n'ai pas forcément envie que cette personne sache que je lui avais associés les tags 'mon amour', 'noël 2007'.

La seule vraie information importante à transmettre, c'est le type de fichier et libmagic est justement là pour montrer que ce n'est pas si important puisqu'on arrive à deviner le type du fichier sans regarder l'extension.

Tu ne veux pas de mon truc (qui au passage n'est pas mon truc mais celui de beaucoup d'autres) mais tu veux bien d'une couche supplémentaire. Cette couche, comment tu l'implémentes à coup d'appels dans le VFS de gnome ou dans celui de kde ? C'est super pour l'intégration ça, vi ou emacs n'auront pas accès à ces possibilités mais kate ou gedit oui ? Ou alors, tu l'implémentes comme un système de fichier (à coup de fuse) ?

Bon, j'ai fait une erreur de manip, je recommence.

Il me semble ridicule qu'un nom de fichier serve à autre chose que donner un nom à un fichier. On ne fait pas apparaître les droits d'accès à un fichier dans le nom du fichier alors quoi doit-on faire apparaître le type du fichier dans le nom ?

Qu'on utilise un ., un : ou un #, ce n'est que de la syntaxe. Je suis d'accord que c'est important mais il me semble qu'on gagnerait vraiment à utiliser une logique de tags en offrant la possibilité d'y accéder depuis la ligne de commande.

Oublions pour un moment l'aspect syntaxe et interdisons l'utilisation d'un . dans le nom d'une étiquette. Ainsi, toto.truc est un fichier toto ayant une étiquette truc.

ls *.owner=jlapin donne tous les fichiers appartenant à jlapin
ls *.c donne tous les fichiers ayant une étiquette c
ls *.c.owner=jlapin donne tous les fichiers appartenant à jlapin et qui ont une étiquette c


Si on réfléchit 30 secondes, la commande find est juste un patch pour pouvoir augmenter les limitations du système de fichier pour accéder aux méta données des fichiers. On ne peut pas écrire
lpr *.pdf.date=today
alors on utilise une commande pour le faire.

Avec une logique de tags + une BDD + une bonne syntaxe, on aurait quelque chose de vraiment puissant.

Mélange de relationnel+hiérarchique.

Les répertoires ne sont que des requêtes sur une BDD.

ls /pdf/!author:jlapin/création<1 janvier 2006
donnerait tous les pdf dont jlapin n'est pas l'auteur et dont la date de création est avant le 1er janvier 2006. L'intérêt du point de vues répertoires, c'est qu'on peut facilement procéder par affinage successifs.

Comme certaines requêtes sont fréquentes, on pourrait définir des vues.
/home, serait la vue correspondant à la requête sur tous les fichiers ayant l'étiquette 'home'.
/home/jlapin serait un raffinage de la vue précédente.
Elle contiendrait tous les fichiers ayant les étiquettes 'home' et 'jlapin'
Pour éviter le bordel, dans /home, comme il y a jlapin, on vire tous les fichiers qui apparaissent dans jlapin.

On peut aussi avoir une vue /mail/lapinette&(non patron).

Ensuite, par dessus ce genre de choses, on peut imaginer un moteur d'étiquetage (beagle et autre) qui ajouterait de façon dynamique des étiquettes => paf les répertoires sur des filtres bayesiens.

Ainsi, on virerait toute la logique de base de données des mailers, et autres gestionnaires de tous poils (musique, vidéo, photo, timbres...). Tous les utilitaires qui travaillent directement avec le système de fichier pourraient avoir accès à ce genre de fonctionnalités. Bref.

Un système allant dans ce sens est BFS [1]. Mais le système écrit par Yoann Padioleau dans sa thèse [2], bien que pas complètement mature, c'est avant tout un travail de recherche, va beaucoup plus loin que BFS. L'introduction de sa thèse est vraiment très intéressante et l'état de l'art qu'il dresse est vraiment bien.

En fait, je pense que la logique BDD peut se rajouter sans trop de problèmes sur un système de fichier classique. C'est d'ailleurs comme cela que certains systèmes de fichiers ont commencés.

Bref.

[1] http://fr.wikipedia.org/wiki/BFS
[2] http://www.irisa.fr/centredoc/publis/theses/2005/irisapublic(...)

C'est vrai que c'est pas lourd du tout d'ouvrir un fichier zip pour ce rendre compte que ce n'est qu'un fichier zip et pas un fichier open document.

Ça va paraître provocateur mais qu'est-ce qui justifie que deux fichiers aient des noms différents ?

De toute façon, ils ont des inodes différentes, le système peut donc les identifier. La seule chose, de pouvoir les identifier au niveau de l'utilisateur. Si on reprend la notation meta-données à coup de #, on pourrait très bien faire un

vi toto#c

ls toto#*

qui liste les meta-données des fichiers

...

Bref.

Si tu as des méta-données, il suffit que le système de fichiers permette d'accéder aux méta-données pour faire ton ls *.png.

On peut décider d'interdire les # dans les noms de fichiers et les utiliser comme séparateur de meta-données

On pourrait donc faire ls *#png#date=today#size<10ko

Bref. De toute façon, il faut abandonner les systèmes de fichiers hiérarchiques.

L'argument, « la théorie des ensembles, ça ne sert à rien » est exactement le genre de réaction qui me semble être à coté de la plaque.

Si on regarde objectivement ce qui « sert » dans les maths qu'on enseigne au collège/lycée, il n'y a pas grand chose:
- la géométrie (thalès, pythagore...),
- poser et résoudre des équations même simple,
- tracer la courbe représentative d'une fonction,
- dériver,
- intégrer,
tout ceci n'est utile qu'à une minorité. Pour s'en convaincre, Il n'y a qu'à voir la tête d'un banquier quand on demande un prêt immobilier, quand on demande comment sont calculés les indemnités:« mon bon monsieur, c'est bien compliqué... » alors que c'est une bête récurrence arithmético-géométrique que j'ai étudiée au lycée. Un autre exemple est l'étude de la fonction numérique f:salaire -> impôt. « Mon dieu avec ma dernière augmentation, j'ai gagné une tranche, je vais me faire saigner à blanc d'un coup ! »

Alors qu'on étudie ça ou autre chose...

En revanche, avec ces notions, on peut essayer de raisonner et que ce soit avec pythagore ou des ensembles, on peut le faire.

Pour niveler par le bas, il faut avoir une public avec un niveau hétérogène pour choisir de travailler au niveau minimal du groupe.

Dans le cas des maths modernes, le but était de se placer dans un domaine où tout le monde part de zéro. Alors bien sur, comme le niveau minimal est aussi le niveau maximal, on peut dire qu'on fait du nivellement par le bas. Mais on peut aussi dire qu'on applique une politique super élitiste en se plaçant au niveau des tout meilleurs.

Bref.

Le principe des maths modernes était pourtant louable. Partant du constat que

- quelqu'un d'un milieu social élevé pouvait plus facilement suivre et aider son enfant que quelqu'un d'un milieu social faible,
- qu'à part les compter (je racourcis), le but des maths est surtout d'apprendre à raisonner et que dans ce cadre là, raisonner sur le théorème de pythagore ou sur des théorème de théorie des ensembles, c'est du pareil au même,

il semblait intéressant de changer complètement les programmes pour que tout le monde (ou presque) parte avec 0 connaissances. De cette façon là, on pouvait espérer écart l'inégalité entre le petit Charles-Henri et le petit Moustafa.

Le problème, c'est que les personnes ayant appris à raisonner ont un pouvoir d'abstraction plus fort et la théorie des ensembles, c'était un peu trop abstrait pour Moustafa et ses parents alors que Charles-Henri et ses parents s'y sont adaptés en 30 secondes. Au final, au lieu de les réduire, on a encore accrus les écarts entre les classes.

Les maths modernes ont bien été un échec mais cet échec, au vu du raisonnement qui a mené à son introduction, n'était pas forcément si prévisible.

Fred

C'est le genre de chose que fait COQ.

L'idée est d'utiliser la correspondance de Curry-Howard.

En math, on démontre souvent des trucs du genre: A implique B.
En info, on code souvent des fonctions qui prennent A et qui rendent B.

Si on réinterprète les maths, le théorème A implique B, ce n'est rien d'autre qu'une fonction qui, à partir d'une preuve de A, te rend une preuve de B. C'est la même chose.

En brodant un peu (beaucoup), on obtient un truc comme COQ qui permet de générer du code certifié. La seule chose, c'est que le mode de programmation est carrément spécial.

Exemple, pour programmer un tri, on démontre le théorème suivant:
Il existe une fonction f de l'ensemble des listes dans l'ensemble des listes telle que
- f(l) est une permutation de l
- f(l) est triée.

Une fois le théorème démontre, on peut demander à COQ de sortir du code implémentant une fonction qui vérifie les hypothèses du théorème: un tri.

Bref, le jour où les programmeurs de base sauront utiliser ce genre d'outil n'est pas encore arrivé.

Je n'ai rien sous la main. Je vais demander au gars.

Tous les profs que je connais utilisent cabri [1] et tous les concurrents que j'ai pu voir l'ignorent complètement. Malheureusement, beaucoup de travail a été fait avec cabri et sans filtre d'import, la migration...

Bref.

Frédéric



[1] http://www.cabri.com/fr/

J'ai pas mal discuté avec un informaticien linguiste de mon labo et il fait de la détection d'ambiguïté dans le langage naturel. Dans le contexte du langage naturel, ce n'est pas parfait mais dans le cas d'un truc plus basique, ça doit pouvoir trouver toutes les ambiguïtés.

Ce que je veux dire, c'est qu'imposer les parenthèses n'est pas nécessaire. Dans pas mal de cas, ce n'est pas ambigu. En revanche, le compilo peut te dire là où il en manque, un peut comme quand le compilo d'ocaml te dit que ton patern matching n'est pas exaustif et qu'il te sort un exemple.

Blop.

On voit bien que tu n'as pas eu d'étudiants qui, quand tu imposes OCAML comme langage, pour un projet compil, se mettent à hurler qu'OCAML, c'est de la merde. Si c'était bien, ça serait utilisé dans l'industrie. Eux, ils veulent programmer en C, C++ ou java.

Un certain nombre d'étudiants considère que la fac, c'est un truc chiant qui ne sert qu'à leur permettre de rajouter une ligne sur leur CV et surtout pas à apprendre quelque chose. Les trucs utiles, ils les apprendront sur le tas.

C'est vraiment question d'habitude.

Il part du principe qu'une matrice, c'est un tableau dont on veut remplir les cases.

Pour cela, il utilise la fonction
> let init_matrix f = Array.init n (fun i -> Array.init n (fun j -> f i j));;

qui prend en paramètre une fonction f à deux arguments et qui construit la matrice
f(0,0), f(0,1), f(0,2), f(0,3),...
f(1,0), f(1,1), f(1,2),...
f(2,0), f(2,1),...
f(3,0),...

Une fois qu'on a cette fonction, il suffit de donner en paramètre la fonction qui calcule le coëfficient. Je trouve cette approche très élégante.

Pour l'addition, c'est la fonction
> fun i j -> p1.(i).(j) +. p2.(i).(j)
qui me semble vraiment lisible.

Pour la multiplication, c'est la fonction
> fun i j -> sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j))
Cette fonction est un poil plus compliquée mais pas trop.
il a d'abord défini la fonction
sigma i j f ->
qui calcule f(i)+. ...+.f(j)

ainsi, sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j))
calcule p1.(i).(0)*p2.(0).(j)+. ... +. p1.(i).(n-1)*p2.(n-1).(j), ce qui est bien la valeur voulue.

Pour définir la matrice identité, on utilise
fun i j -> if i=j then 1. else 0.

etc...

Bref, ce n'est pas parce que vous n'avez pas l'habitude de programmer de façon fonctionnelle que son code n'est pas élégant.