Discussion :

[InOCamlWeTrust]

J'ai moi aussi fait Math Sup en MPSI (hein, gorgonite !).

J'ai commencé Caml quelques semaines avant le début des cours : je voulais apprendre un premier langage sérieux et me suis acheté le gros bouquin de O 'Reilly que j'ai commencé à étudier comme un acharné. J'étais tout seul chez moi, sans internet, et j'étais bien content d'avoir la masse d'exemples de codes qui m'aidaient à comprendre les nombreux principes de ce langage.

Quand je suis arrivé deux semaines plus tard en cours, j'ai pu aider ceux qui avaient de réelles difficultés avec ce langage... et ce n'étaient pas les TP qui les sortaient d'affaire, souvent (hein, tu t'en souviens ?) !

Tout le monde n'a pas l'initiative de se prendre en charge et étudier à fond un langage et ses principes : je pense que, vu le post originel, la démarche de gorgonite était justifiée.

Je souhaiterais personnellement qu'il y ait plus de gens comme sicav qui postent leurs difficultés ici plutôt qu'ils aillent emmerder l'équipe de développement Caml (comme il m'est déjà arrivé plusieurs fois... merci à Pierre Weis et Xavier Leroy pour leur patience !).

Je souhaiterais aussi que les professeurs, s'ils en sont, tentent de fournir des explications supplémentaires aux élèves, tout comme ils le feraient s'ils venaient en personne le leur demander : ça apporterait un plus indéniable au forum, une sorte de valeur ajoutée dûe au regard autre porté sur la chose. Agiter le baton ne sert à rien.

gorgonite et d'autres participent activement à la vie de ce forum, c'est-à-dire le forum Langages fonctionnels : il aura fallu beaucoup de temps pour avoir la chance d'en voir un ici.

Ce forum est le forum de tous ceux voulant partager leur expérience dans le domaine des langages fonctionnels et Caml, mais respectez également le travail de ceux qui, comme nous, passons parfois plusieurs heures par jour à débugger des problèmes triviaux, répondre à des questions faciles, aider des débutants ou des moins débutants, et surtout rédiger de la documentation de qualité (je n'ai pas oublié ton message, gorgonite, mais je ne suis rentré de vacances que Dimanche à minuit et cette semaine, c'est tendu).

Désolé pour ce post véhément, mais il ya des choses qui me font vraiment sortir de mes gonds.

[Garulfo]

[...]
Je souhaiterais aussi que les professeurs, s'ils en sont, tentent de fournir des explications supplémentaires aux élèves, tout comme ils le feraient s'ils venaient en personne le leur demander : ça apporterait un plus indéniable au forum, une sorte de valeur ajoutée dûe au regard autre porté sur la chose. Agiter le baton ne sert à rien.[...]

Désolé pour ce post véhément, mais il ya des choses qui me font vraiment sortir de mes gonds.

Il faut effectivement te calmer, même si j'ai déjà vécu plus de véhémence de la part d'autres posteurs
D'abord si je suis au Canada il y a une raison: ici pédagogie et soutien à l'étudiant ont un sens.

Mais reste que donner une solution sans amener l'étudiant à réfléchir c'est surtout lui donner les moyens de se planter lors de l'examen. Et ça je n'agite aucun baton... c'est ce qui se passe.

Tu parles de math sup/spé... mais c'est le pire des endroits niveau pédagogie!!! Tu parles donc du pire des cas bien qu'il y ait forcément des profs consciencieux dans certains prépas. Je rappelle qu'à l'université on enseigne des cours de Caml et qu'il y a aussi des étrangers sur ce forum.

Quand tu donnes une solution, même si ça ne paraît pas sympa, fait en sorte de pousser l'autre à la comprendre pour l'utiliser... en laissant une partie non faîte. Je reconnais le soutien (financier en quelque sorte) des forums... ils contribuent à fournir une aide importante. Mais si l'aide n'est pas de bonne qualité alors c'est l'écueuil pour l'étudiant. Pas pour moi. Si ça ne me touchait pas, je ne serais pas là.

Tu parles d'exemple de code (dans un livre) mais ce n'est pas du tout pareil... à moins que ce code soit la réponse d'une question du prof. Hors tu as eu l'attitude de chercher avant par goût personnel, puis d'adapter ce que tu connaissais à la nouvelle problématique... c'est génial, mais tu représentes environ 10% des étudiants. C'est pas terrible... Pensez y... Si votre but c'est d'aider les personnes qui viennent poser des questions de cours, alors aidez les vraiment à long terme... pas juste pour une question de devoir. Et l'envoyer paître ailleurs peut être une manière de le réveiller.

[Garulfo]

sinon pour en revenir au probleme, personnellement je trouve l'ordre decroissant, cad [1;2;3] represente X²+2X+3; plus subtil et moins abordable que l'ordre croissant qui me prend 5 lignes (oui je sais, les programmes les plus courts ne sont pas les plus évidents, masi bon..), cependant je me suis passé de l'utilisation de list_length -qui implique un parcours de liste supplementaire- et cela implique de changer un peu la façon de tourner le probleme notamment pour cet ordre décroissant.

Dans ces représentations, il y en a une meilleure que l'autre.
Je ne sais pas si tu l'as vu, c'est peu probable, mais il y a des opérateurs particulièrement important: les folds. Maîtriser le fonctionnel, c'est souvent maîtriser ces opérateurs. Dans ces opérateurs, l'un est bien plus efficace que l'autre (récursif terminal pour être exact): le fold_left.
Toute la question, à long terme, c'est de savoir utiliser la bonne représentation qui permet d'utiliser le fold_left

Toujours est-il qu'il se trouve que ceci est en correspondance avec ce que j'ai cru que ton prof te demande: le coût algorithmique qui va dépendre de ta représentation. Choisir la bonne représentation assure une efficacité de l'algorithme... vois tu laquelle des deux ? et pourquoi ?

[dudulebzh]

Euh , a vrai dire je ne connait pas vraiment l'operateur "fold" donc jl'ai pas utilisé, par contre je pense bien être dans le recursif terminal...euh...enfin je crois ^^.
Bon en gros ma recursion (en fonction auxiliaire) donne ça :

match liste with
a::[]-> 0, []
|a::q-> match aux q with
x,y->x+1,(x+1)*a::y

J'ai placé le cas de la liste vide avant la fonction recursive et pis j'ai une autre fction pr extraire la valeur dun couple..

Voila sinon de toute façon voua inquietez pas mon devoir est rendu, et pour le coup du professeur je crois bien que c'était juste une blagounette ^^ :p

[InOCamlWeTrust]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
match liste with
                    a::[]-> 0, []   
                    |a::q-> match aux q with
                                x,y->x+1,(x+1)*a::y

N'écris jamais du code comme ça : mal indenter, ne pas parenthèser, etc... c'est source d'erreurs futures, surtout en Caml

Préfère ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
match liste with
  | a :: [] -> (0, [])
  | a :: q ->
    (match (aux q) with
      | (x, y) -> (x + 1, (x + 1) * a) :: y))

- ajoute des espaces de part et d'autre des opérateurs
- mets toujours la barre verticale '|' en début de filtrage
- dans les filtrage imbriqués, parenthèse absolument les filtrages
- écris toujours les n-uplets avec des parenthèses : dans le cas contraire, le jour où tu écriras des n-uplets de n-uplets, tu seras complètement perdu !
- n'écris jamais de if sans else
- n'utilise pas le mot-clef rec abusivement (surtout lorsqu'il n'y en pas besoin !)
- n'écris pas non plus [x], mais x :: [] : même si c'est plus moche et que ça fait réellement bizarre, dans du long code, ça saute aux yeux tout de suite, alors que la première forme est assez silencieuse
- et surtout, surtout : commente ton code à l'aide des commentaires ouverts avec (* et fermés comme ceci et (* peuvent etre imbriques *) *).

La syntaxe Caml est beaucoup trop ambiguë comme pour pouvoir se permettre de faire confiance aux priorités des opérateurs et autres (de tête, si je me souviens bien, il y a au bas mots une quarantaine de conflits dans la syntaxe Objective Caml !).

[Garulfo]

[...]

- ajoute des espaces de part et d'autre des opérateurs
- mets toujours la barre verticale '|' en début de filtrage
- dans les filtrage imbriqués, parenthèse absolument les filtrages
- écris toujours les n-uplets avec des parenthèses : dans le cas contraire, le jour où tu écriras des n-uplets de n-uplets, tu seras complètement perdu !
- n'écris jamais de if sans else
- n'utilise pas le mot-clef rec abusivement (surtout lorsqu'il n'y en pas besoin !)
- n'écris pas non plus [x], mais x :: [] : même si c'est plus moche et que ça fait réellement bizarre, dans du long code, ça saute aux yeux tout de suite, alors que la première forme est assez silencieuse
- et surtout, surtout : commente ton code à l'aide des commentaires ouverts avec (* et fermés comme ceci et (* peuvent etre imbriques *) *).
[...]

Amen..

je vais t'embaucher toi -_-

[Garulfo]

Euh , a vrai dire je ne connait pas vraiment l'operateur "fold" donc jl'ai pas utilisé,

Je ne te conseillais pas de l'utiliser, mais je t'emmenais vers la conclusion qu'une des deux représentations étaient meilleures que l'autre. La choisir change tout

par contre je pense bien être dans le recursif terminal...euh...enfin je crois ^^.
Bon en gros ma recursion (en fonction auxiliaire) donne ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
match liste with
                    a::[]-> 0, []   
                    |a::q-> match aux q with
                                x,y->x+1,(x+1)*a::y

[...]

Euh... c'est quoi comme fonction ça ?
let rec aux liste ?
Ça ne doit pas être ça... sinon tu aurais un problème de type non ?

Au passage InOCamlWeTrust, tu as une parenthèse de trop à la fin.

[InOCamlWeTrust]

Au passage InOCamlWeTrust, tu as une parenthèse de trop à la fin.

Laquelle ? Je ne la vois pas, car je dirais qu'il manque plutôt deux parenthèses... le code pas lisible et ambigü, il n'y a pas pire !

[Jedai]

Laquelle ? Je ne la vois pas, car je dirais qu'il manque plutôt deux parenthèses... le code pas lisible et ambigü, il n'y a pas pire !

Il manque effectivement une parenthèse devant "(x + 1) * a" dans ton code.

--
Jedaï

[Amergin]

Quand je donne un exercice en classe, je n'aime pas voir que certains éléments ont été donné par une personne externe qui ne connaît rien à ce que j'enseigne

Je ne veux pas polemiquer pendant des heures, d'autant que je ne suis pas certain d'avoir raison: moi aussi je suis prof (de physique), et je n'aimerais pas qu'on vienne contredire mon boulot avec des trucs sortis de je ne sais ou.

Mais les cours que j'ai eu en info etaient vraiment de qualite tres moyenne, notamment parce que les codes n'etaient pas suffisamment commentes (a mon gout au moins). Bon l'info pour physicien, ce n'est probablement pas le top de ce qui se fait.

Mais c'est vrai qu'il n'y a pas d'autres solutions que la pratique et il ne vaut mieux pas macher excessivement le travail, ce qu'on a peut-etre fait la.

[dudulebzh]

Alors en effet c'est une "rec aux liste", mais pour le typage il me semble correct: ça nous donne du int list->int*int list=<fun> je crois (enfin j'en suis sur ^^)..
Où serait le probleme de typage?

let rec aux liste = (*fonction auxiliaire récursive*)

match liste with

|a::[]-> 0, [] (*terminaison*)
|a::q-> (match aux q with

|x,y->x+1,(x+1)*a::y)

[gasche]

En terminaison c'est pas 1, [] plutôt ? (commencer la factorielle avec 0, c'est classique et ça fait mal )

Il n'y a aucun problème de typage. Juste un warning de filtrage non-exhaustif : tu ne filtres pas le cas [], dans le premier match.

[InOCamlWeTrust]

Je le répète : n'utilise pas les n-uplets sans parenthèses. Ce n'est pas pour rien que bon nombre de points que j'ai cités avant concernant une façon saine et non ambiguë d'écrire du code se retrouvent dans la syntaxe révisée d'Objective Caml.

[gasche]

Hum, tu ne tolères même pas les élégants let x, y = .... in ?

Pas commode

Par ailleurs, c'est vrai que c'est potentiellement mal, mais avec une identation correcte on peut gérer les filtrages imbriqués sans parenthèses sans problème, et c'est quand même plus léger.
D'ailleurs, c'est dommage que le revised-syntax-man soit aussi paranoïaque au sujet des "dangling cases", parce que rajouter le génial "where" pour le restreindre à un seul binding, c'est super dommage

[dudulebzh]

un test sur la liste vide est effectué avant la fonction auxiliaire, donc pas de probleme de ce coté là, même si j'ai un "warning", quand a la terminaison on a bien du 0,[] car meme si on utilise la liste vide au lieu de 0::[] pour une raison de decalage de degré cela correspond a une multiplication par 0 simulée, et pas de risque de "phenomene factorielle" ^^vu que la valeur évolue par addition...
Sinon c'est vrai que les parentheses sont parfosi nécessaires, notamment pour les n-uplets, mais comme c'est un couple et que c'est assez clair, je m'en suis passé...
J'espere que cela repond a vos questions

[Garulfo]

Hum, tu ne tolères même pas les élégants let x, y = .... in ?
[..]

Personnellement je te dirais que cela dépend de ce que tu écris après. Mais celle-ci n'est pas innacceptable.

[InOCamlWeTrust]

Hum, tu ne tolères même pas les élégants let x, y = .... in ?

J'ai déjà perdu assez de cheveux durant ma jeunesse à propos des ambigüités de cette syntaxe !

Par ailleurs, c'est vrai que c'est potentiellement mal, mais avec une identation correcte on peut gérer les filtrages imbriqués sans parenthèses sans problème, et c'est quand même plus léger.

Grossière erreur : on ne fait pas du Haskell ! Objective Caml n'a aucune notion de l'indentation !

It is to avoid the problem of the ``dangling bar'' (the same than the ``dangling else'' in the ``if'' construct). In normal syntax, this program:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
     match ... with
       case1 ->
         match ... with
           case11 -> ...
         | case12 -> ...
     | case2 -> ...

is wrongly interpreted: to obtain what you want, you need to use parentheses or begin..end to close the internal match construct. There is a same problem with the if construct, because of the optional else (see further).

En syntaxe révisée, on écrirait ça comme ceci.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
     match ... with
       [case1 ->
         match ... with
           [case11 -> ...
         | case12 -> ... ]
     | case2 -> ...]

Et il n'y a plus de conflit, et c'est tout aussi léger !

La très très bonne idée de Haskell, ça a été d'introduire l'indentation dans la syntaxe : l'indentation fixe, en Haskell, la sémantique, et c'est un vrai régal lire du Haskell quelconque, car il est, de fait, toujours lisible... ce qui n'est pas le cas avec les autres langages.

D'ailleurs, c'est dommage que le revised-syntax-man soit aussi paranoïaque au sujet des "dangling cases", parce que rajouter le génial "where" pour le restreindre à un seul binding, c'est super dommage

Le where, serait aussi, pour moi à prohiber, dans l'état actuel ; c'est chelou de lire du code avec des identificateurs pas encore définis : ça embrouille plus qu'autre chose.

En Haskell, là encore, l'indentation du where permet une plus grande lisibilité qu'en Objective Caml révisé.