Discussion :

[elishac]

J'ai une petite question : si a est un vecteur et f une fonction, est-ce que "let b= f a", lorsque f est l'identité, permet de créer un vecteur b indépendant de a, ou est-ce qu'il faut écrire "let b= copy_vect (f a)" ?

[Cacophrene]

Salut !

J'ai une petite question : si a est un vecteur et f une fonction, est-ce que "let b= f a", lorsque f est l'identité, permet de créer un vecteur b indépendant de a, ou est-ce qu'il faut écrire "let b= copy_vect (f a)" ?

Le test est très facile à faire :

Code :

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

1
2
3
4
5
6
 
let testf f =
  let x = [| 1; 2; 3 |] in
  let y = f x in
  y.(0) <- 2;
  x = y

Il suffit de comparer le résultat de testf (fun x -> x) (= true) et testf Array.copy (= false). Donc la réponse est non. L'identité est une identité, pas une copie ! Il faut utiliser Array.copy (vect_copy avec caml-light) pour le faire.

Cordialement,
Cacophrène

[Cacophrene]

Salut !

Dans ces conditions, d'après le post précédent, si le calcul de R donne A, est-ce qu'une modification de R effectue une modification de A ?

Une règle simple à appliquer quand on utilise les tableaux :

(1) si on veut faire des effets de bord, c.-à-d. modifier le contenu des cases du tableau sur place, on ne fait pas de copie. Dans ce cas, la fonction renvoie généralement unit. (2) Si on veut coder sans effets de bord, c.-à-d. renvoyer un nouveau tableau, on crée une copie (copy_vect ou Array.copy) locale avant toute modification. C'est généralement cette copie qui est renvoyée comme résultat de la fonction.

À toi de voir ce que tu veux faire de ta fonction inverse_pol. Remarque : on a le choix parce que caml est un langage fonctionnel impur. Ceci dit, il faut se méfier des effets de bord et il n'est donc généralement pas recommandé d'en faire, sauf si c'est justifié (par exemple, recopier des tableaux de très grande taille peut être pénalisant ou rhédibitoire). Anti-remarque : les tableaux ont été implémentés comme modifiables sur place (mutable)...

Par ailleurs, pouvez-vous me dire si la procédure vous semble correcte ou améliorable ?

A priori le recours massif aux traits impératifs indique qu'il y a matière à réécrire le code d'une façon plus idiomatique. D'ailleurs, les codes qui contiennent des boucles for et surtout while sont généralement plus difficiles à prouver, quand c'est demandé (recherche d'un invariant de boucle et tout ce qui s'ensuit).