Discussion :

[darkontes]

bonjour bonjour
voila je cherche, avec camllight, à programmer un jeu de la vie. pour cela j'ai besoin d'une fonction qui permet de compter le nombre de voisins vivants en une case de la matrice, de plus je dois faire au final un jeu de la vie dans un monde torique ( cf ma fonction "aux" plus bas )
pour l'instant voila ce que j'ai fait :
je considere g la matrice de taille (n*p) et je cherche le nombre de voisins vivants a la case de coordonnées (i,j) et je considere qu'une cellule vivante contient un 1 et une morte un 0

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
let nb_voisins g n p i j =
 let rec aux = function 
  |(-1,a)->aux(n-1,a)
  |(n,b)->aux(0,b)
  |(c,-1)->aux(c,p-1)
  |(d,p)->aux(d,0)
  |(a,b)->(a,b)
  in 
   let x = ref (-(g.(i).(j)) in 
    for k=(i-1) to (i+1) do 
     for t=(j-1) to (j+1) do
      x:=!x+(g.(fst(aux(k,t))).(snd(aux(k,t))))
     done
    done;
!x;;

voila et on me repond tres poliment

Toplevel input:
> |(c,-1)->aux(c,p-1)
> ^^^^
Warning: this matching case is unused.
Toplevel input:
> |(d,p)->aux(d,0)
> ^^^
Warning: this matching case is unused.
Toplevel input:
> |(a,b)->(a,b)
> ^^^
Warning: this matching case is unused.
nb_voisins : int vect vect -> int -> int -> int -> int -> int = <fun>
#

et je sais pas ce qui ne va pas !!!

donc si vous pouviez me donner un petit coup de pouce ca n'est pas de refus

merci d'avance

[Cacophrene]

Bonsoir,

Ce code présente plusieurs problèmes :

• D'abord, tu ne sembles pas avoir compris ce qu'est le filtrage. Quand tu écris (n, b), il ne faut pas croire que cela signifie (x, b) when x = n, car ce n'est pas le cas. En d'autres termes, si tu veux vérifier qu'un élément de ton filtre est égal à une certaine valeur, il faut utiliser when. Écrire (n, b) stocke le premier élément du couple dans n, le second dans b, et c'est tout (aucune comparaison n'est effectuée).
• Ensuite, les conventions de nommage ne sont pas respectées. On ne donne généralement pas de règle toute faite et immuable, mais on déconseille fortement d'utiliser des noms à une seule lettre. Des noms convenablement choisis améliorent la lisibilité du code, la détection des anomalies et les évolutions ultérieures.
• Dans les boucles for, il y a des parenthèses inutiles qui alourdissent les notations et des expressions qui peuvent être simplifiées.

Cordialement,
Cacophrène

[darkontes]

a d'accord merci je vais regarder ca
mais c'est vrai que pour le filtrage je n'avais pas tres bien compris (d'un autre coté pour l'instant en classe on n'a fait que 6 h de TP ^^ donc je suis encore pas tres sur de ce que je fais )
voila je vais voir ca

[Cacophrene]

Re,

Une piste de code, qui ne corrige qu'une partie des problèmes évoqués ci-dessus :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
let nb_voisins g n p i j =
  let rec aux = function
    | -1 -> aux (n - 1)
    | x when x = n -> aux 0
    | x -> (function
      | -1 -> aux x (p - 1)
      | y when y = p -> aux x 0
      | y -> (x, y)
  ) in
  let x = ref (-g.(i).(j)) in
  for k = i - 1 to i + 1 do
    for t = j - 1 to j + 1 do
      let a, b = aux k t in
      x := !x + g.(a).(b)
    done
  done;
  !x

Remarque : il y a au moins une autre manière de résoudre le problème de l'univers torique au jeu de la vie. Il s'agit d'un simple modulo. Je te laisse le soin de chercher un peu dans ce sens. Mais courage, c'est en bonne voie.

Cordialement,
Cacophrène

[darkontes]

bon je vais chercher vers le modulo quand meme parceque en attendant j'avais fait ca :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
let nb_voisins grille n p i j =
 let rec aux = function 
  |(a,b) when (a=(-1))->aux(n-1,b)
  |(a,b) when (a=n)->aux(0,b)
  |(a,b) when (b=(-1))->aux(a,p-1)
  |(a,b) when (b=p)->aux(a,0)
  |(a,b)->(a,b)
  in 
   let x = ref (-(grille.(i).(j))) in
    for k=(i-1) to (i+1) do 
     for t=(j-1) to (j+1) do
      x:=!x+(grille.(fst(aux(k,t))).(snd(aux(k,t))))
     done
    done;
!x;;

mais c'est pas tres ... esthetique
en tout cas merci pour la piste parce que j'ai bien l'impression d'avoir compris : car exemple premier filtre a -1 je renvoie n-1 en fait je demande -1 modulo n et quand c'est n je demande de renvoyer 0 c'est a dire n modulo n ^^
en tout cas MERCI beaucoup

edition :
a oui je crois que ca y est

Code :

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

1
2
3
4
5
6
7
8
let nb_voisins grille n p i j =
let x = ref (-(grille.(i).(j))) in
    for k=(i-1) to (i+1) do 
     for t=(j-1) to (j+1) do
      x:=!x+(grille.(i mod n).(j mod p))
     done
    done;
!x;;

et c'est vraiment plus joli ^^

[Cacophrene]

Bonjour,

C'est effectivement plus rapide de l'écrire avec un modulo, mais attention quand même à ceci :

Code :

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

1
2
3
4
5
6
7
 
cacophrene(~)$ ocaml
        Objective Caml version 3.11.1
 
# -1 mod 10;;
- : int = -1
#

Il y a donc une petite chose à ajouter pour s'assurer que tu as bien des indices valides (c.-à-d. 0 <= i < longueur).

Cordialement,
Cacophrène

[darkontes]

aïe la parcontre je ne suis plus vraiment sur de ce que renvoie modulo
ou peut etre renvoie-t-il les valeurs entre -10 et 10

dons ce cas, devrais-je modifier le code comme suit :

Code :

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

(grille.(i mod n).(j mod p))

deviendrait

Code :

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

(grille.((i+n) mod n).((j+p) mod p))

???

[Cacophrene]

Bonjour,

(grille.((i+n) mod n).((j+p) mod p))

La solution que tu proposes est correcte puisque la plus petite valeur prise par i ou j est -1 (de sorte que i + n ou j + p est toujours positif dès lors que n > 0 et p > 0). Tu peux aussi utiliser une condition pour traiter séparément le cas -1 (aucune préférence a priori pour l'une ou l'autre des deux écritures).

Cordialement,
Cacophrène

[darkontes]

merci beaucoup cacophrene

[adtunum]

Il est vrai que tes variables sont mal nommées. Lorsque tu liras du code écrit par une tierce personne tu te rendras compte qu'il est important pour la lisibilité que les variables soient nommées correctement. Cependant à ma connaissance il n'y a pas de documentation pour ocaml qui explique comment nommer correctement ses variables, donc il est normal qu'étant débutant ton nommage ne soit pas bon et nous te feront remarquer ces problèmes lorsque tu posteras.

Pour ce qui est des nom de variable à une seule lettre, il y a des exceptions. Par exemple dans une boucle for il est courant d'utiliser 'i' et pour une double boucle for d'utiliser 'i' et 'j'. Il est fortement déconseillé d'utiliser i et j ailleurs que pour des boucles car le lecteur s'attendra à ce que i et j soient des variables de boucle. Or c'est ce que tu fais dans ton code. Dans ton code i et j devraient plutôt être 'x' et 'y' car ce sont les positions d'une cellule dans une grille 2D, donc comme en mathématique on utilise (x, y) pour les coordonnées en deux dimensions.

Idem le nom de ta variable x n'est pas très heureux, car on s'attend à ce que ce soit une coordonnée sur l'axe des abscisses. Il vaut mieux utiliser res (pour result) ou v (pour valeur/value). res indique que c'est le résultat que la fonction va renvoyer à la fin, v indique une valeur plus ou moins standard par rapport à la fonction (si la fonction renvoie le nombre de voisins on se doute que v sera cette valeur).

Pour n et p tu peux utiliser (width, height) ou (row, column) ou bien encore (dim_x, dim_y). (w, h) serait aussi accepté bien qu'on préfère des noms de variable plus parlant. Par exemple dans LablGL et dans ocaml-sdl ils utilisent (w, h) (les initiales de width et height).

Code ocaml :

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

1
2
3
4
5
6
7
8
9
10
let nb_neighbours grid dim_x dim_y x y =
  let v = ref 0 in
  for i = (x-1) to (y+1) do
    for j = (x-1) to (y+1) do
      if i <> x && j <> y then
        v := !v + grid.((i+dim_x) mod dim_x).((j+dim_y) mod dim_y)
    done
  done;
  (!v)
;;

Maintenant une remarque sur le code lui-même. En règle général il vaux mieux écrire le code le plus simple possible. Pour plusieurs raisons. D'abord un code plus simple est plus simple ce qui simplifie les choses. Un code plus simple n'est pas toujours plus simple à concevoir cependant un code plus simple est toujours plus simple à lire et à comprendre. Du code est souvent amener à être lu par des tierce personne, donc il est important de penser à elles. De plus on est souvent amener à relire du code longtemps après l'avoir écrit, donc là aussi s'il est plus simple il sera plus simple à relire.
Enfin avec un code plus simple, il y a moins de risque d'avoir des bugs.
Je fais ici allusion à ton astuce par rapport à l'initialisation de la variable pour soustraire la valeur de la cellule même. Il est beaucoup plus sémantique d'exclure son traitement dans la boucle. Si on regarde sur cette page, on remarque qu'aucun n'a utilisé ton astuce :
http://rosettacode.org/wiki/Conway's_Game_of_Life

Encore au sujet de la simplicité, dès le départ lors de l'écriture de ta fonction tu aurais pu te simplifier CONSIDÉRABLEMENT la vie. Au lieu de ta boucle récursive aux et de tes boucles for, pourquoi ne pas simplement lister toutes les cases de cette façon :

Code ocaml :

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

1
2
3
4
5
6
7
8
9
let nb_neighbours g x y =
  (get g (x-1) (y-1)) +
  (get g (x-1) (y  )) +
  (get g (x-1) (y+1)) +
  (get g (x  ) (y-1)) +
  (get g (x  ) (y+1)) +
  (get g (x+1) (y-1)) +
  (get g (x+1) (y  )) +
  (get g (x+1) (y+1))

il est vrai que ma fonction get sur RC est une implémentation pour une grille bornée, et non rebouclée, mais il est facile de la changer pour :

Code :

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

1
2
let get g dim_x dim_y x y =
  g.((x + dim_x) mod dim_x).((y + dim_y) mod dim_y)

Je me permets enfin une dernière remarque, en tapant [ ocaml game of life ] dans google, on trouve le lien suivant dans la première page des résultats : http://rosettacode.org/wiki/Conway's_Game_of_Life#OCaml

[Cacophrene]

Bonsoir,

Parfois on ne veut pas dérouler les boucles dans le calcul du voisinage parce qu'on envisage ensuite d'étendre la notion au voisinage de taille 2, 3, etc... pour changer un peu les règles et obtenir des automates particuliers.

Pour tout le reste je suis entièrement d'accord. La forme sous laquelle un code est présenté est presque aussi critique que le fond.

Cordialement,
Cacophrène

[adtunum]

Encore une remarque concernant l'indentation du code source.
En Caml on indente le code à 2 espaces.

Je te recommanderais de lire la documentation suivante (c'est bien c'est en français) concernant le formatage du code :
http://caml.inria.fr/resources/doc/g...elines.fr.html

[gasche]

Encore une remarque concernant l'indentation du code source.
En Caml on indente le code à 2 espaces.

Je ne suis pas d'accord. Chacun indente comme il veut, du moment que son code source reste cohérent (y compris quand plusieurs personnes y travaillent, qui doivent alors accorder leur indentation).

Je conseille personellement aux débutants d'utiliser 4 espaces, voire des tabulations (quand l'éditeur de texte n'indente pas automatiquement), car des espacements plus marqués rendent la lecture plus facile à un non-habitué.

[Cacophrene]

Bonjour,

Moi je suis longtemps resté à 4 espaces pour l'indentation, et même avant je mettais un espace avant les points-virgules. De gustibus et coloribus...

Cordialement,
Cacophrène

[darkontes]

ba merci, je vais essayer de faire attention les prochaines fois euh non je ne vais pas essayer : je vais le faire (heureusement que vous me le faites remarquer comme ca je ne prendrais pas l'habitude )

bon je vais lire la docu

clairs efficaces rapides sympathiques faisant des remarques constructives, ya pas moyen, je mets ce forum dans mes favoris ^^
vous etes supers merci beaucoup a tout le monde

[adtunum]

Bonsoir,

je suis d'accord avec vous que "les goûts et les couleurs, ça ne se discute pas"
cependant si on télécharge plusieurs projets depuis le hump on constate que la plus grande majorité des programmeurs ocaml ont adopté l'indentation à 2 espaces. Dans d'autres langages courants comme C, PHP, Perl, Python, il n'y a pas que je sache un tel ralliement autour d'une telle convention. Sauf peut-être avec Pear (le framework officiel de PHP) où on impose une indentation à 4 espaces obligatoirement.

En C ça ne me dérange pas de lire du code à 2, 3, 4 ou 8 espaces, en revanche pour lire du code OCaml il me faut réindenter à 2 espaces sinon j'ai beaucoup de mal à lire le code. Je ne sais pas pourquoi il y a un tel consensus pour l'indentation à 2 espaces en OCaml, c'est peut-être dut la structure de sa syntaxe.
Toujours est-il qu'étant donné ce consensus il paraît raisonnable de se rallier à l'usage courant.

Sinon au sujet des tabulations, pour moi c'est vraiment pire que tout !
Si on regarde le code des projets (pas uniquement en ocaml) écrits par plusieurs personnes, on constate que c'est le bazars pour 80% d'entre eux, avec un mélange de tabulation et d'espace. Et même parfois c'est l'horreur absolue : un mélange d'indentation tabulé et espacé avec les tab d'une largeur autre que 8 ce qui fout totalement en l'air l'indentation !
De plus souvent les commentaires de fin de ligne sont alignés avec une certaine largeur de la tabulation, et si on change cette largeur les commentaires ne seront plus alignés. Bref selon moi (et beaucoup d'autres) les tabulations sont à proscrire absolument !

L'auteur de Python a d'ailleurs déclaré que si c'était à refaire, il aurait fait en sorte que l'interpréteur Python refuse catégoriquement tout programme contenant des tabulations.

[InOCamlWeTrust]

Le consensus autour de l'indentation à 2 espaces n'en est pas vraiment un. OCaml dispose d'une fonction permettant de réécrire le code indenté avec 2 espaces, et manifestement, beaucoup de personnes l'utilisent (malheureusement !).

'\t' rules!

[adtunum]

Bonsoir,

1) Je ne vois pas du tout pourquoi cela peut-être malheureux, pourrais-tu développer ?

2) Je ne connais pas cette fonction d'OCaml permettant de reformatter le code, pourrais-tu indiquer quelle est cette procédure ?

3) Que le code soit reformaté ou pas, ça ne change rien au fait implacable que 99% des projets OCaml sont indentés à 2 espaces. Pour qu'il y ai un tel consensus c'est qu'il a une bonne raison.

[Cacophrene]

Bonjour,

À titre personnel, je n'aime pas du tout l'indentation à base de tabulations, surtout quand elle est grossièrement mélangée aux espaces. Bref, pour moi, ce serait plutôt '\t' sucks. Concernant le choix de 2 espaces, ça vient peut-être du fait que cela évite de se retrouver trop vite collé à la marge droite, surtout quand on indente systématiquement le filtrage. Un exemple :

Code :

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

1
2
3
4
5
6
7
8
9
let foo x y z =
  match x with
    | 0 -> (* ... *)
    | _ -> match y with
      | 0 -> 0 (* ... *)
      | _ -> match z with
        | 0 -> (* ... *)
        | _ -> (* ... *)

À comparer à la version avec 4 espaces :

Code :

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

1
2
3
4
5
6
7
8
9
let foo x y z =
    match x with
        | 0 -> (* ... *)
        | _ -> match y with
            | 0 -> 0 (* ... *)
            | _ -> match z with
                | 0 -> (* ... *)
                | _ -> (* ... *)

En clair, c'est peut-être lié à l'écriture même du code OCaml, qui est souvent concis mais dense. À côté, un code C/C++ paraît souvent beaucoup plus aéré (ce qui ne présage en rien de sa lisibilité).

Cordialement,
Cacophrène

[darkontes]

ba pour un petit debutant comme moi c'est vrai que j'aime bien le 4 espaces je trouve ca tout de suite plus clair, apres j'imagine qu'avec l'habitude il n'y a pas besoin d'en mettre autant, mais la je crois que j'adopte le 4 ^^