Conversion d'un programme Free Pascal Standard en programme Free Pascal Orienté Objet

Bonjour,

Je suis un vieux Pascalien et j'ai développé une application qui procède à l'analyse de séries temporelles. Dans le cadre de cette application je dois réaliser des calculs à l'aide de boucles imbriquées.
Ces calculs par définition répétitifs en nombre important entre 10⁶ et 10⁷ sont réalisés par un seul cœur et donc très couteux en temps. Je cherche donc à convertir mon application en Free POO de façon à réaliser un répartition multithreading des calculs.
Ma question est : Existe-t-il un logiciel qui me permettrait de convertir mon application en Free POO sans que j'ai à réécrire complètement 3200 lignes de code.

Merci pour vos conseils.:roll:

Bonjour,

Le pascal objet est un pascal donc a priori qui peut le plus peut le moins...

Mais (il y a toujours un mais) la gestion de l'interface homme machine peut grandement différer d'un outil à l'autre. Ce n'est pas tant la couche objet que le changement de bibliothèques impliqué par le changement d'outils qui demande des adaptations parfois importantes.

Si l'application est avec une IHM minimaliste comme le mode console, ça peut tomber en marche sans rien faire (sinon croiser les doigts).

Dans les autres cas, si la couche présentation a été bien isolée du code fonctionnel le coût de migration devrait être assez limité. Mais si le code mélange allègrement présentation, traitement et accès aux données, la réécriture intégrale de l'équivalent de 3200 lignes sera plus rapide que la technique des petits pas qui sera plus longue et gardera la structure de programme qui pose problème.

Salutations

Bonjour M. Guesset,

Tout d'abord merci pour votre réponse et votre temps.
Je voudrais rajouter quelques éléments sur la nature de mon application qui est comme vous allez le voir, assez simple ce qui permettra j'espère, de préciser la solution optimale.
L'application de type FPC lie en entrée un fichier text de données assez volumineuses de 100000 A 500000 lignes. Ce fichier est stocké en mémoire et réaccéder à l'aide d’une variable de type pointeur.
n calculs sont effectués en parcourant le fichier (10⁶ < n < 10⁷) faisant intervenir plusieurs fonctions et procédures de type Pascal standard.
Dans l'état actuel de l'application n est le produit 3 boucles imbriquées. Apres chaque calcule si le résultat rempli certaines conditions il est stocké dans un fichier text (il y a très peu de résultats qui satisfont les conditions donc peu d'écritures (entre 1 et 10).
Ce qui serait souhaitable dans un premier temps c'est de paralléliser les calculs contrôles par la boucle la plus interne par le jeu d'un index a l'aide par exemple d'une procédure telle que
procedure DoSomethingParallel(Index: PtrInt; Data: Pointer; Item: TMultiThreadProcItem); ou l'index evidemment controlerait la boucle.
Mais dès que j'introduis ce type de POO il me semble que le compilateur va hurler car les calculs de la boucle utilisent évidemment mes fonctions et procédures Pascal standard mentionnées plus haut ...
Voilà merci pour votre conseil sur la base de ces nouveaux éléments. (surtout s’il y a une possibilité d’éviter la réécriture complète) :roll:

Bonjour,

Apparemment, Si je comprends bien, la POO ne serait utile que pour gérer les threads. Il n'y aurait donc pas une réécriture complète.

C'est un programme en mode console (ligne de commande) ? Sinon il y a de forte chance qu'il utilise nombre de composants qui sont des instanciations d'objets. Auquel cas vous faites déjà de la POO sans le savoir :D

L'histoire d'un pointeur m'interpelle. Cela évoque un traitement purement séquentiel car c'est le domaine d'excellence des pointeurs. Or le parallélisme suppose qu'il est possible de découper en traitements décorrélés. Est-ce le cas ?

Il faudrait voir le code pour se faire une idée (au moins les trois boucles).

Salutations

Bonjour POO,

Tout d'abord merci pour la réponse.
Oui effectivement il y a des instanciations d'objets dans mon programme.
Par ailleurs le pointeur fait effectivement référence a une lecture séquentielle d'un fichier texte. Mais le découpage se ferait au niveau des paramètres d'optimisation sur lesquels je fais une recherche par balayage. Donc l'idée serait de découper/repartir la boucle extérieure sur n cœurs / threads et on pourrait même pousser plus loin et faire un découpage de 2eme et 3eme niveau pour les boucles internes. :lol:
D'où la question : pour ceci dois-je réécrire la totalité de mon pgm ? :roll:
(Un bon nombre d'instanciations objets sont évidemment en dehors des 3 boucles).
:lol:
Bien cordialement, :P

Bonjour,

La réécriture devrait se limiter à celle des boucles pour tirer partie du parallélisme. Mais cette réécriture sera d'autant plus difficile si les boucles actuelles ne sont pas intrinsèquement indépendantes (par exemple, si l'itération i+1 d'une boucle dépend de l'itération i, alors ces deux itérations ne peuvent être parallélisées en l'état).

Il n'est pas nécessaire de multiplier les threads à outrance. Pour une machine à n cœurs, le nombre de threads devrait être limité entre n et 1.3 n (si SMT ou HT) au delà il n'y aura pas de gain voire même une légère diminution de performances.

Salutations

Bonjour Guesset et merci pour la réponse, :P

Les boucles sont je pense indépendantes mais imbriquées. Pour être tout fait clair la boucle la plus extérieure J pour s'incrémenter d'un pas, attend que la boucle K ait complètement réalisée toutes ces itérations de 1 à n qui pour s'incrémenter d'un pas attend elle-même attend que la boucle L ait réalisée toutes ces itérations de 1 à m.
Sur cette base le parallélisme n8Oe devrait pas poser de problème ? 8O

Bien cordialement :D

Bonsoir,

A priori, si elles sont imbriquées c'est qu'elles sont interdépendantes. Prenons l'exemple du balayage d'un espace 3D. Il y aura une boucle en X suivie d'une boucle en Y puis d'une boucle en Z avant de pouvoir travailler au sein de la boucle la plus interne (celle en Z) sur le point (X, Y, Z) qui dépend des 3 niveaux de boucle.

En revanche, on peut avoir un thread qui traite le X = 0 modulo 4, un autre pour les X = 1 modulo 4, un autre pour les X = 2 modulo 4, et un quatrième pour les X = 3 modulo 4.

Mais il ne faut qu'il y ait interdépendance entre les itérations de X. Supposons que X évolue de 0 à Xmax et que dans cette boucle on calcule X2 = x* x avec la méthode incrémentale X2 = X2 + 2X + 1. X2 étant calculé à partir de l'itération précédente, elle ne peut fonctionner dans un thread qui va de 4 en 4 au lieu d'un incrément unitaire. Il faudra, soit revenir à x2 = x* x, soit adapter la formule incrémentale x2 = x2 + 8x +16.

Salutations

Bonjour Guesset,

Merci pour votre reponse.
Si je suis votre logique la boucle la plus interne dans ce cas est la seule a etre independante.
Est ce que nous pouvons etre d'accord au moins sur ce point ? 8O
Bien a vous:P

Bonjour Jacco,

Une boucle est indépendante des autres si elle n'utilise aucun résultat (y compris l'indice de boucle des autres boucles).
Si la boucle la plus interne n'utilise rien des boucles qui l'entourent, pourquoi serait elle dedans ?

La boucle la plus externe (la première) est a priori indépendante des autre boucles même si on peut imaginer des cas tordus (et souvent difficiles à gérer) où une boucle interne perturbe une boucle externe. La seconde peut être également indépendante auquel cas elle peut être permutée avec la première.

Le fait qu'une boucle externe doive attendre que les boucles interne aient terminé leur job est une dépendance temporelle qui n'est pas propre aux boucles mais au traitement séquentiel des instructions. C'est cela que le parallélisme permet de casser un peu.

En général, la boucle principale se prête bien au parallélisme, mais il peut y avoir des modifications à faire, notamment si il y a des interdépendances entre les itérations de cette même boucles (si une valeur Val_i dépend par exemple de Val_i-1, i étant l'indice de boucle).

Le plus simple serait de voir le code relatif à cette boucle pour je puisse être plus concret.

Salutation

Bonjour,

je m'immisce car dans ce genre de chose, j'ai besoin d'une précision absolue et il y a là quelque chose qui coince :

Citation:

---

Envoyé par Guesset

Mais il ne faut qu'il y ait interdépendance entre les itérations de X.

---

il ne faut qu'il y ait :koi:

il faut qu'il y ait ?
ou
il ne faut pas qu'il y ait ?
Merci,

Citation:

---

Envoyé par Guesset

---

Bonjour Guesset,

Merci pour la reponse rapide et pour l'interet porte a mon petit probleme (clavier qwerty sorry je n'ai pas accentuation Francaise sauf a "repiquer" les accents ailleurs).
Pour simplifier appellons la boucle externe 1, intermediaire 2 et interne 3
La boucle 3 est commandée par 3 indices, le code exécuté à ce niveau est

Code:

---

( (NO_OF_STEP = Indice_1) and (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3) )

---

ou Indice_1 est l'indice de la boucle_1, Indice_2 est l'indice de la boucle_2, Indice_3 est l'indice de la boucle_3.

la fonction appelée est

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

FUNCTION DERIVATIVE_S4S(PTR:PTRREC; DEPTH:INTEGER):FLOAT; {******************} VAR I:INTEGER; BEGIN DERIVATIVE_S4S := 0;   FOR I:=1 TO DEPTH DO BEGIN if (PTR^.C<>PTR^.PREV^.C ) then DERIVATIVE_S4S := DERIVATIVE_S4S + ( (( PTR^.C/PTR^.PREV^.C )-1)*(1 + SSI5) ); PTR := PTR^.PREV END;   END; // FUNCTION DERIVATIVE_S4S

---

J'espere que ceci vous permettra d'avoir une vue claire du probleme.


(PS Holala je viens de voir le message de Jipete et moi qui ne met pas l'accentuation, il ne va pas etre content du tout ... )

Si on se réfère à ce que tu nous montres, la construction ressemble à ceci :

Code:

---

1 2 3 4 5 6 7

for Indice_1 := ... for Indice_2 := ... for Indice_3 := ... if ((NO_OF_STEP = Indice_1) and (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3)) then begin // Traitement end;

---

Ce qui n'est clairement pas optimal. On devrait plutôt avoir quelque chose comme cela pour éviter de recalculer DERIVATIVE_S4S n fois (et accessoirement utiliser directement ce résultat comme low de la boucle 3 => un test de moins !) :

Code:

---

1 2 3 4 5 6 7

for Indice_1 := ... if Indice_1 = NO_OF_STEP then for Indice_2 := 1 to ... for Indice_3 := Trunc(DERIVATIVE_S4S(CURRPTR, Indice_2)) +1 to ... begin // Traitement end;

---

A partir de là, les "boucles" 2 et 3 pourraient être thread-ées. Je mets boucles entre guillemets parce que dans les faits, on utilisera plutôt des variables globales qu'on incrémentera de façon synchronisée par InterlockedIncrement (c'est le thread qui récupère l'indice du prochain élément à traiter).

Oui il y aura un certain travail de réécriture mais qui concernera principalement l'accès aux données (synchronisation) et la séparation UI/métier. Et pour répondre à la question originale, je ne connais aucun utilitaire capable de faire cela ;)

Quant au nombre de threads, il sera déterminé par le nombre de threads en exécution simultanée par rapport au nombre de cœurs.

Bonjour Jipété

Citation:

---

Envoyé par Jipété

Bonjour,

je m'immisce car dans ce genre de chose, j'ai besoin d'une précision absolue et il y a là quelque chose qui coince :

il ne faut qu'il y ait :koi:

il faut qu'il y ait ?
ou
il ne faut pas qu'il y ait ?
Merci,

---

Même si le "pas" renforce la négation c'est le "ne" qui la porte comme dans "je ne mange ni ne dors", "je ne sais d'où cela vient" etc. Ceci dit, même si la phrase reste correcte, j'aurais dû ajouter le "pas" salvateur 8-) à une compréhension aisée.

Ceci pour la forme, pour le fond il ne faut nulle interdépendance entre itérations si celles ci doivent être traitées en parallèle.

Salutations

Bonjour Andnotor,

Merci pour la reponse et le temps consacré.

Mais je ne pense pas que l'on puisse implementer ce type de solution pour la raison suivante :

Tout d'abord j'aurai du donner un code un peu plus complet et je m'en excuse. Le code ( (NO_OF_STEP = Indice_1) and (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3) )est en fait un element d'un test multiples et s'ecrit

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

or ( (NO_OF_STEP = Indice_1) and (DERIVATIVE_S4S(CURRPTR,ROUND(Indice_2)) > Indice_3) )   or // autre test . . . or // autre test   then begin   // Traitement 1   End else begin   // traitement 2   end

---

Donc j'ai besoin d'evaluer DERIVATIVE_S4S avec en Indice_2 > Indice_3. Indice_3 ne peux etre le resultat de l'evaluation de DERIVATIVE_S4S.
Enfin tous les cas doivent etre evalué sequenciellement au niveau de Indice_1 donc le test if Indice_1 = NO_OF_STEP n'a pas lieu d'être.

Citation:

---

Envoyé par Guesset

Bonjour Jipété



Même si le "pas" renforce la négation c'est le "ne" qui la porte comme dans "je ne mange ni ne dors", "je ne sais d'où cela vient" etc. Ceci dit, même si la phrase reste correcte, j'aurais dû ajouter le "pas" salvateur 8-) à une compréhension aisée.

Ceci pour la forme, pour le fond il ne faut nulle interdépendance entre itérations si celles ci doivent être traitées en parallèle.

Salutations

---

Bonsoir Guesset,

Merci pour la forme et le fond, et surtout pour le fond.
" nulle interdépendance " alors la boucle la plus externe pourrait au moins faire l'objet d'un traitement parallèle ?
Sinon le parallèlisme qui est censé s'appliquer en particulier au cas des boucles n'a plus aucun interêt.
Cordialement

Bonjour,

Je souscris aux remarques de Andnotor.

Il y a un travail de révision du code qui est un préalable - et peut être même un substitut - à une opération de parallélisation. Je renvoie sur la précédente discussion "Test multi conditions " qui semble porter sur le même code et qui proposait déjà quelques évolutions du code.

Par exemple, outre les modifications déjà proposées, on peut écrire ceci (seule la sortie de la boucle de la multiplication par une constante a de l'importance, au doigt mouillé le gain doit être au moins de 20 %):

Code:

---

1 2 3 4 5 6 7 8 9 10

function Derivative_S4S(Ptr : ptrRec; Depth : integer): float; begin Result := 0.0; while Depth1 > 0 do begin if Ptr^.C <> Ptr^.Prev^.C then Result += Ptr^.C / Ptr^.Prev^.C - 1.0; Ptr := Ptr^.Prev; dec(Depth1); end; Result := Result * (1 + SSI5); // Sortir de la boucle la multiplication par une constante (ie. 1 + SSI5 ne varie pas durant la fonction) end; // function Derivative_S4S

---

Des modifications unitaires aux modifications structurelles, le potentiel de gains semble important.

La complexité et la taille des tests ne peut être un argument pour garder le code en l'état. Au contraire elles témoignent d'un axe d'améliorations importantes. Paralléliser le code en l'état peut être séduisant à première vue mais je ne m'y risquerais pas

Salutations

Bonsoir Jacco,

Citation:

---

Envoyé par jacco

Bonsoir Guesset,
" nulle interdépendance " alors la boucle la plus externe pourrait au moins faire l'objet d'un traitement parallèle ?
Sinon le parallèlisme qui est censé s'appliquer en particulier au cas des boucles n'a plus aucun interêt.
Cordialement

---

Oui la boucle externe est généralement le meilleur candidat. Si la n^ième itération ne dépend pas des n-1 précédentes alors elle peut être confiées à un thread différent. Il existe bien des mécanismes permettant de s'accommoder de certaines dépendances mais cela a un coût en complexité et performances qui incite fortement à faire sans.

Bonne soirée.

Citation:

---

Envoyé par Guesset

Bonjour,

Je souscris aux remarques de Andnotor.

Il y a un travail de révision du code qui est un préalable - et peut être même un substitut - à une opération de parallélisation. Je renvoie sur la précédente discussion "Test multi conditions " qui semble porter sur le même code et qui proposait déjà quelques évolutions du code.

Par exemple, outre les modifications déjà proposées, on peut écrire ceci (seule la sortie de la boucle de la multiplication par une constante a de l'importance, au doigt mouillé le gain doit être au moins de 20 %):

Code:

---

1 2 3 4 5 6 7 8 9 10

function Derivative_S4S(Ptr : ptrRec; Depth : integer): float; begin Result := 0.0; while Depth1 > 0 do begin if Ptr^.C <> Ptr^.Prev^.C then Result += Ptr^.C / Ptr^.Prev^.C - 1.0; Ptr := Ptr^.Prev; dec(Depth1); end; Result := Result * (1 + SSI5); // Sortir de la boucle la multiplication par une constante (ie. 1 + SSI5 ne varie pas durant la fonction) end; // function Derivative_S4S

---

Des modifications unitaires aux modifications structurelles, le potentiel de gains semble important.

La complexité et la taille des tests ne peut être un argument pour garder le code en l'état. Au contraire elles témoignent d'un axe d'améliorations importantes. Paralléliser le code en l'état peut être séduisant à première vue mais je ne m'y risquerais pas

Salutations

---

Bonsoir Xor,

Merci pour votre réponse.
Je ne suis pas familiarisé avec le langage C et donc je ne connaissais pas la syntaxe += .

Juste une question, implicitement vous supposez que le couple d'instructions: while Depth1 > 0 do begin / dec(Depth1); est plus rapide que la seule instruction FOR I:=1 TO DEPTH DO ?
Sinon je dois reconnaitre que rajouter * (1 + SSI5) a chaque itération n'était pas très performant (quelque fois on veut ecrire rapidement un code et on laisse de coté la performance ...)
Si vous répondez par l'affimative a ma question j'implementerai votre solution surtout si je peux gagner 20% ...
Bonne soirée

Citation:

---

Envoyé par Guesset

Bonsoir Jacco,



Oui la boucle externe est généralement le meilleur candidat. Si la n^ième itération ne dépend pas des n-1 précédentes alors elle peut être confiées à un thread différent. Il existe bien des mécanismes permettant de s'accommoder de certaines dépendances mais cela a un coût en complexité et performances qui incite fortement à faire sans.

Bonne soirée.

---

Bonsoir Guesset,

Merci pour me permettre de garder un peux d'espoir pour la solution du parallèlisme.
Mais apparemment Xor n'a pas très encourageant ...

Cordialement

Bonsoir jacco,

Xor était juste un clin d’œil à Andnotor (and not or, il manque xor).

Citation:

---

Envoyé par jacco

Je ne suis pas familiarisé avec le langage C et donc je ne connaissais pas la syntaxe += .

Juste une question, implicitement vous supposez que le couple d'instructions: while Depth1 > 0 do begin / dec(Depth1); est plus rapide que la seule instruction FOR I:=1 TO DEPTH DO ?
Sinon je dois reconnaitre que rajouter * (1 + SSI5) a chaque itération n'était pas très performant (quelque fois on veut ecrire rapidement un code et on laisse de coté la performance ...)
Si vous répondez par l'affimative a ma question j'implementerai votre solution surtout si je peux gagner 20% ...
Bonne soirée

---

La plupart des modifications sont plus d'ordre esthétiques et les goûts se discutent. Ainsi l'usage de la syntaxe += permet une concision rare en Pascal et illustre bien une opération d'accumulation.
Les boucles qui se terminent à 0 sont plus "optimisables" que les boucles croissantes car les processeurs proposent des instructions spécifiques (comme Loop, Loop_cc...) et les compilateurs les utilisent si on leur donne leur chance. Le gain reste cependant très faible. Par ailleurs j'économise une variable...
En ce qui concerne les 20 % ce n'est hélas que sur la fonction améliorée mais c'est déjà cela.

Salutations

Bonjour Guesset,

J'ai donc implementé vos recommendations, le code est effectivement plus concis. Question performance je dois probablement gagner quelque chose ne serait-ce que pour la suppression de * (1 + SSI5) à chaque itération.
Par contre j'avoue n'avoir pas vu l'interêt des idées de Andnotor. Peut être y a t il quelque chose qui m'échappe ...

Bien Cordialement

Bonjour Guesset,

Apres une absence un peu prolonge, je reviens vers vous avec un probleme d'execution.

Je souhaite effectuer le test suivant

Code:

---

If (NO_OF_STEP = 47 ) and ( TCPH > Var_TCPH_NBal[ 1 ] )

---

Var_TCPH_NBal[ 1 ] est un element d'un array contenant un Real (TCPH est egalement un Real) .
A la compilation pas de probleme mais a l'execution ma routine n'evalue pas ou pas correctement ( TCPH > Var_TCPH_NBal[ 1 ] ).

Que pouvez vous me suggerez.

d'avance Merci pour votre aide

Jacco

Bonjour,

La petite portion de code ne semble pas en défaut.

Il faut cependant faire attention dans la comparaison de réels notamment dans le cas de l'égalité mais je ne vois pas de problème de ce type ici quoiqu'il pourrait y avoir une égalité attendue qui se transforme en un >.

Par exemple (sqrt(2)-1.0)*(sqrt(2)+1.0) sera rarement strictement = à 1.0 même si les affichages font l'arrondi qui semble que tout est OK. Il sera > ou <.

En effet, sqrt(2) = 2^1/2 + e, e étant une erreur d'arrondi positive ou négative très petite en valeur absolue.

Dans ce cas l'expression donne 1 + 2*2^1/2*e + e². L'erreur e est inférieure à la moitié du bit le plus faible donc e² est très en dehors de nos préoccupations de précisions. En revanche 2.8*e peut être supérieur (en absolu) au bit le plus faible. On dit que l'erreur est remontée. Je n'ai pas vérifié ce qu'il en est pour la racine de 2 dans les différentes représentations des réels mais l'exemple sert juste à illustrer le problème potentiel.

Une portion de code un peu plus conséquente serait certainement utile. Par ailleurs, en quoi le résultat n'est pas celui attendu ?

Salutations

Re-Bonjour Guesset et tout d'abord merci votre prompte réponse,

Code:

---

1 2 3

Var_TCPH_NBal, Var_CPDH_NBal : Array [ 1..100 ] of Real;   R1, R2: Real;

---

Le test complet se présente comme suit

Code:

---

If (NO_OF_STEP = 47 ) and ( TCPH > Var_TCPH_NBal[ 1 ] ) and ( ((CPDH-1)*100) > Var_CPDH_NBal[ 1 ] ) then xyz

---

Ce test est précédé et suivi par 400/500 inégalitées à peu pres du même type .
Le code complet de mon Pgm fait 15000 lignes.

Le point que je voudrais souligner est le suivant :
si je remplace respectivement Var_TCPH_NBal[ 1 ] et Var_CPDH_NBal[ 1 ] par R1 et R2 (simple Variables de type Real) affectés du même contenu que Var_TCPH_NBal[ 1 ] et Var_CPDH_NBal[ 1 ] j'obtiens bien le résultat attendu.

Le problème semble donc résider dans l'utilisation de Real éléments d'un array.

J'espère que ces éléments supplémentaires vous aideront.

Bien a vous

Jacco

Il serait préférable de passer par CompareValue en spécifiant un delta (unité Math) pour tester des réels.

Bonjour Jacco,

Citation:

---

Envoyé par jacco

...Le problème semble donc résider dans l'utilisation de Real éléments d'un array...

---

Ce n'est pas possible. Si les contenus sont les mêmes, c'est à dire que les uns sont des affectations des autres et non le résultat d'au calcul qui devrait donner le même résultat, le fait d'être en tableau ne change rien.

Attention : il ne faut pas supposer que l'affichage par défaut des valeurs prouve leur égalité car cet affichage a une précision donnée et pratique un arrondi.

Si le tableau n'est pas une simple affectation de valeurs mais un calcul, il faut vérifier par une comparaison d'égalité genre if v = a[1] then OK else KO;.

Il faut regarder si le tableau n'est pas modifié avant les tests soit volontairement soit accidentellement (par exemple au travers de pointeurs un peu hors jeu).

La solution de Andnotor revient, dans le cas de cette comparaison, à remplacer TCPH > Var_TCPH_NBal[1] par TCPH - Var_TCPH_NBal[1] > delta pour gommer l'incertitude sur les derniers bits.

Salutations

Bonjour Guesset et merci pour le support

Je vais reprendre mon code.

et Merci a Andnotor pour sa suggestion (Comparevalue) que je vais tester.

Tres bonne journee,

Jacco:P