fmaz fmaz a écrit 494 commentaires

Ce n'est pas parce que « les décideurs préssés » comme il semble bon de les appeler ici ne se rendent pas compte de l'utilité d'embaucher des ig de recherche que ce boulot n'existe pas. Et ce n'est pas non plus parce qu'ils manquent que les chercheurs doivent faire un boulot qui ne leur est pas demandé.

Je ne sais pas ce qu'est l'opérateur @@.

Pour le _ -> 0, c'est quelque chose de très puissant.

En OCAML, on peut faire de la programmation par filtrage (i.e. a coup de switch mais en beaucoup plus puissant).

Pour additionner les éléments d'une liste, on peut faire de la façon suivante:

let rec glop l=match l with
[] -> 0
| x::l2 -> 1+(glop l2)

le _ sert quand on ne moque du reste. Par exemple, pour tester si une liste ne contient qu'un seul élément (exemple débile, je sais), on peut écrire:

let foo l = match l with
_::[] -> true
| _ -> false

Dans l'exemple de la matrice, ce mécanisme est utilisé avec un mécanisme de récupérations d'erreurs.

Si on exécute un programme qui peut lancer des erreurs, on peut les rattraper à coup de try ... with

try
mon_code_principal
with
qu'est-ce que je fais en cas d'erreur

comme « mon_code_principal » peut lancer plusieurs type d'erreur, la section with
fait du filtrage sur le type d'erreur

try
mon_code
with
division_by_zero -> print "division par zéro = la tête à Toto"
| parse_error -> print "apprend à écrire banane !"

Dans le coup de la matrice, on a besoin de calculer la taille de la matrice. Il peut y avoir un problème avec une matrice vide et seulement dans ce cas. On fait donc un

try
length matb.(0)
with
_ -> 0

C'est tout.

Je pense que tu confonds le boulot de chercheur et celui d'ingénieur de recherche.

Certaines personnes sont douées pour chercher et trouver des trucs. Ce qu'elles produisent n'est certainement pas directement utilisable. Pour cela, il faut passer du temps pour polir, nettoyer, remettre en forme.

Ce travail de nettoyage, c'est plus celui d'un ingénieur de recherche. L'ingénieur doit évidemment travailler avec le chercheur.
Les chercheurs pourraient éventuellement passer du temps en polissage mais
- ce n'est pas ce qu'on leur demande. Il vaut mieux qu'ils inventent d'autres trucs que d'autres nettoieront ;
- ils ne sont pas forcément doués pour cela.

Je préfère qu'un Dijkstra, qu'un Knuth ou qu'un Tarjan passent leur temps à produire des trucs monstrueux qu'eux seuls peuvent trouver et que d'autres personnes fassent le lien.

Même au sein de la recherche la plus fondamentale, on retrouve ce genre de schéma. Pour parler d'un sujet que je connais bien.
1. Il y a 20 ans, 2 gars ont pondu une démo pour une vieille conjecture. La démo fait 600 pages. Pour une rapide introduction, voir http://en.wikipedia.org/wiki/Robertson-Seymour_theorem;
2. Un petit groupe de personne dont je fais parti passe beaucoup de temps à étudier cette démonstration pour bien la comprendre et pour la simplifier. C'est un bordel sans nom mais à force d'acharnement, sur ces 600 pages, on a réussi à faire fondre les 200 premières à moins de 40 pages
3. Ces 40 pages ont des implications très importantes en algorithmique théorique. Certains chercheurs essayent de faire les liens. On a donc maintenant de jolis algorithmes inutilisables pour plein de problèmes.
4. Certains chercheurs essayent de rendre ces algorithmes vraiment utilisable en pratique. Il existe maintenant des « proof of concept » super efficace pour certains problèmes particuliers.
5. Certains chercheurs commencent à écrire des bouquins « pour les masses » pour que certains ingénieurs de recherche apprennent ces concepts.

Avec un peu de chance, d'ici 20-30 ans, le travail commencé il y a 20 ans sera vraiment utilisé.

Je suis d'accord mais certains ingénieurs ont une attitude légèrement méprisante vis-à-vis des chercheurs: les chercheurs dans leurs tours d'ivoire, déconnectés de la réalité, qui ne connaissent rien à la vie.

Pour citer un exemple célèbre, il suffit de voir la discussion entre Torvald et Tannenbaum.

Bref, je suis persuadé que certains ingénieurs sont prêts à regarder ce que font les chercheurs et que certains chercheurs sont prêts à aider les ingénieurs. Le principal problème, c'est qu'il n'y a pas de vraie culture de transfert et donc, c'est difficile.

Je n'ai plus écris d'OCAML depuis longtemps, je vais donc peut-être dire des bêtises.
Mais je me lance

> open Array
>
> let ( @@ ) f g x = f (g x)
>
> let produit mata matb =
> ....let coeff li col =
> ........fold_left ( + ) 0
> ............(init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)))
> ....in
> ....init (length mata) (init (try length matb.(0) with _ -> 0) @@ coeff)

On fait le produit des matrices mata et matb.
pour cela, on définit une fonction coeff li col qui donne le coefficient li,col de la matrice produit. Pour rappel, c'est mata(li,0)*matb(0,col)+...+mata(li,n)*mat(n,col)

Pour calculer ce coefficient, on utilise un fold_left qui prend en argument plein de trucs.

On voit entre autre apparaître (fun k->mata.(li).(k)*matb.(k).(col)). Si on appelle f cette fonction, le coefficient est donc f(0)+f(1)+f(2)+...+f(n).

Passons maintenant au fold_left. cette fonction prend en argument une fonction f, une valeur et une liste. Par exemple,
fold_left f 0 [1;2;3] = f (f (f (0 1) 2) 3

La fonction (+) est l'operateur + préfixé, c'est à dire (+) 1 2=1+2.
Pour additionner tous les éléments d'une liste, il suffit de faire un
fold_left (+) 0 l.

Si on recolle les morceaux, pour que la fonction coef retourne ce qu'il faut, il suffit que init n f tourne une la liste [f(0);f(1);...;f(n)]. Dans ce cas,

1. init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)) retourne la liste
[mata(li,0)*matb(0,col),...,mata(li,n)*mat(n,col)]
2. le fold_left (+) 0 ... rend la somme des éléments de la liste soit, le coefficient de li,col de la matrice.


Maintenant qu'on a une fonction coeff qui marche, il suffit d'utiliser init pour faire une jolie matrice. Si on part du principe qu'une matrice, c'est une famille de vecteurs, on construire un vecteur ligne, il suffit de faire un
init n k->coef li k.

On remarque que cette fonction a un paramètre (li). La fonction
li -> (init n k->coef li k) est donc la fonction qui rend le li-ème vecteur ligne de la matrice. En l'itérant à coup de init, on obtient une matrice.

Je passe l'utilisation du try with.

Bref, que d'explications pour un code de 6 lignes.

Dans le lien que j'ai donné, cette différence est mentionné et il me semble (je n'ai pas tout relu en détail) qu'Ingo semblait considérer l'approche de l'universitaire intéressante et qu'il allait l'essayer.

Bref.

Dans l'exemple donné, le principal problème est l'utilisation du fold_left. Les personnes qui ne programment que de façon impérative sont très destabilisées pas l'utilisation d'itérateurs fonctionnels.

Et ne me dites pas que les boucles for ou while sont plus naturelles. J'ai assuré un TP d'algorithmique de base et au vu des problèmes de mes étudiants, je peux vous assurer que ce n'est pas le cas.

La question est la suivante. Que préfères-tu:
- utiliser *. pour les réels ;
- devoir déclarer le type de toutes les variables entières ou réelles ?

Franchement, *. est beaucoup plus économique. Après, c'est juste de la syntaxe et comme toujours, les programmeurs sont très attachés à leurs habitudes et si un langage décide d'utiliser # au lieu de * pour la multiplication, ils n'utiliseront pas le langage. C'est exactement la même chose que le fil de discussion sur les raccourcis sous vi et blender.

Dommage.

Ce n'est pas le boulot d'un chercheur. Il ne faut pas tout confondre.

Avoir du code incorporé dans le noyau linux n'est que très peu valorisé académiquement. Un universitaire va donc faire un patch, faire des mesures et sortir un papier. Une fois le patch écrit, il y a beaucoup de boulot pour arriver à le faire incorporer au noyau. Il n'y a qu'a voir les problèmes de Con Kolivas pour faire incorporer son ordonnanceur, les frustrations et les rancoeurs que ça peut occasionner.

C'est aussi le cas pour les systèmes d'exploitation.

Le dernier exemple en date que j'ai sous la mais, c'est
le super ordonnanceur de monsieur Ingo Molnar qui
refait (en moins bien) ce qu'un universitaire à fait 11
ans avant lui.

cf. http://kerneltrap.org/node/8141. L'article cité par Ting
Yang est de 1996.

Dans ce que tu dis, je vois deux choses :
1. Le problème programmation impérative <-> programmation fonctionnelle
2. Les autres trais du langages.

Pour le premier point, c'est clair que quand on dis à un étudiant qui sait déjà programmer (par exemple en C) qu'on va programmer sans variables et sans boucles, ça lui fait bizarre.

En fait, je pense qu'un bon programmeur devrait maîtriser les deux styles de programmation car les deux ne sont pas adaptés à toutes les situations: écrire un produit de matrice de façon fonctionnelle, c'est ridicule et écrire un algo de résolution des tours de Hanoï impérativement, c'est l'horreur. De façon plus générale, je pense que pour manipuler des structures de données un peu complexes, l'approche fonctionnelle est supérieure et que pour beaucoup de choses plus basique l'approche impérative se justifie bien.

Pour ce qui est du second point, je trouve que
- la programmation par filtrage,
- avoir un système de modules paramètriques ,
- avoir un vrai typage fort,
- avoir un ramasse miettes pour la mémoire,
- ...
est vraiment très agréable.

Au final, je trouve dommage que les langages ayant du succès soient des langages assez basiques. Ceci dit, cela reste compréhensible car pour qu'un langage ait du succès, il faut qu'il possède une grosse communauté pour développer plein de bibliothèques. Or un langage trop évolué fait souvent appel à des concepts et des façons de programmer inhabituels et peu de développeurs vont s'y intéresser. Comme peut de développeurs s'y intéressent, la communauté reste réduite et le cercle vertueux de promotion du langage ne s'amorce pas.

Bref.

Je suis d'accord qu'OCAML est un bon langage sous utilisé.

Pour vire un module pénible, rm marche très bien.

Le format JPG utilise la DCT (Discrete Cosinus Transform) et pas des ondelettes.

> La force d'Unix a était de dire "tout est fichiers", toutes les applications
> ont discuté par fichier. Le mec qui a codé ls n'est pas allé demandé au
> mec qui codé grep comment mieux s'interfacer.....

Je ne voudrais pas paraître impoli mais je pense que tu es complètement
à côté de la plaque.

Les gens qui ont codé unix (ça existait peut-être avant, je ne sais pas) ont pensé un système pour interfacer des programmes: l'entrée, la sortie, l'erreur standard + les redirections et les tubes.

Après, le gars qui a écrit ls a fort subtilement pensé à écrire le résultat dans la sortie standard et grep peut filtrer l'entrée standard. Merveilleux, ls et grep peuvent s'interfacer par un simple 'ls | grep'.

Transposition libre:
Cela m'a toujours amusé chez les linuxiens : ils peuvent utiliser certains executables windows (wine, vmware, qemu) et maintenant certains drivers windows (ndiswrapper). Bon mais si c'est pour utiliser linux et aller prendre les drivers et les application sous windows pourquoi ne pas utiliser directement windows ?

Réponse un poil hors sujet, sur l'exemple que tu donnes, il suffit de passer les opérations (+, *) en paramètre à ton code.

Et si on échange des fichiers avec quelqu'un qui n'utilise pas la même locale ?

Ce que j'observe sans trop savoir si je dois en rire ou en pleurer, c'est le combat d'arrière garde que mènent les majors. Comment ils ne veulent pas changer leur modèle économique, ils font des pieds et des mains poru imposer tout un tas de choses qui ne serviront à rien d'ici 5 ans.

Il y a 10-12 ans, l'accès à internet se faisait par l'intermédiaire d'un modem. On devait payer les communications séparément. Un fournisseur d'accès à proposé un forfait illimité et tout le monde a pensé qu'il partait dans le mur, et tout le monde a eu tord. Le même phénomen s'est produit avec les téléphones portables et un certain forfait millénium. Même chose pour les communications téléphoniques fixes, les SMS... on commence même à voir des offres de ce genre pour la musique (par exemple http://www.musicme.com/illimite/). D'ici peut, on verra des fournisseurs de contenus proposer des forfaits pour des films. Le jour où tout le monde s'y sera mis, plus personne ne piratera. À choisir entrele téléchargement façon peer-to-peer où on attend plusieurs heures pour obtenir un film sans garantie de qualité, et avoir instantanément le même film par l'intermédiaire de sa « blop-box », il n'y a pas photo.

Je suis d'accord avec les commentaires ci-dessus, le contrôle complet du tout DRM ne sera mis en place que progressivement, en 2-3 ans et à ce moment là, toute cette débauche d'énergie ne servira plus à rien, pour les majors. En revanche, le gain me paraît clair pour microsoft. Ils veulent rendre le support hardware le plus difficile possible par les OS concurrents. Ils utilisent l'argument piratage habilement en sachant pertinemment:
1. qu'ils ne peuvent pas se permettre de tout vérouiller brutalement ;
2. que les pirates pourront contourner leurs mesures.
Le coup de la révocation du matériel, je suis persuadé que c'est du flan à part pour forcer les gens à renouveller leur matériel tout les 2 ans.

Blop

Frédéric

Pour la base, avec un point de vue php, il y a la doc de php:
http://www.php.net/manual/fr/security.database.php

Si on me donne leur mécanisme de branchement qui fonctionne dans 15% des cas, je vous en fais un pas cher qui voit juste dans 85% des cas.

Pour cela, appelons oracle1 le prédicteur de branchement et supposons qu'il retourne une valeur booléenne pour dire s'il faut brancher ou pas.

oracle2(x)=return(not(oracle1(x)).

Le coup du 15%, c'est sans doute de l'amélioration. Au lieu d'avoir du 50/50, on a du 65/35 et c'est tout de suite moins ridicule.

> pacman -Sy frozen-bubble

Et pour installer pacman, c'est

frozen-fubble -Sy pacman ?

D'un point de vue théorique, pour faire tout ce que du C fait en Ocaml, c'est simple: écrit un interpréteur C en Ocaml et appelle le c2ocaml. Après, au lieu de faire "foo monfichier", tu fais "c2ocaml foo.c monfichier". Tu as ainsi écrit un programme Ocaml (c2ocaml) qui fait tout ce que peut faire du C.

Ne pas optimiser, je veux bien mais il faut préciser ce qu'« optimiser » veut dire.

Faire un tri à bulles parce que c'est lisible et qu'il ne faut pas optimiser et que le compilo fera le boulot, ce n'est pas demain que ça fonctionnera.

Un certain nombre de personnes passent leur temps à ce genre d'optimisation pour que kde ou gnome fonctionnent plus vite.

Maintenant, réécrire un code C en assembleur pour utiliser des trucs, je suis d'accord qu'il faut éviter et repousser ça à la fin.

Frédéric

Non mais cela ne veut pas dire que sur les fonctionnalités qu'offrait kde 1,
kde4 ne soit pas plus efficace.

Reprenons depuis le début. Soit A un serveur et B un client.

Quand B demande une page à A, A lui envoie avec la page tout pour que B puisse
répondre ; c'est quand même le but. De plus, B ne communique pas pour faire sa
réponse. B envoie quelque chose et A accepte ou A refuse. Le serveur peut utiliser
son générateur de nombres aléatoires autant qu'il veut, ça ne change rien à ce
fonctionnement.

Si A fait ce que tu dis, tu "touilles" des trucs pour que les noms des champ du form
soient illisibles sauf que tu donnes le dictionnaire: le script java-script. Pour savoir
quels sont les champs piégés, le robot a deux méthodes :
- faire une analyse du rendu de la page pour voir quels sont les liens cachés ;
- utiliser le code java-script fourni pour savoir quels sont les champs qu'il renseigne.