Discussion :

[ClaudeLELOUP]

Je craignais cette réponse.
C’est moins « "évident" » !
En effet, si je prends, par exemple la cause « Charriage d'éléments massifs par la crue », elle peut venir de
CCS_SS_2
En_SS_1
En_SS_2
G_SS
I_SS_1 à I_SS_8
MR_SS
SMR_1


qui n'ont pas nécessairement le même effet, le nombre de combinaisons va exploser !

[michael_g]

Oui je comprends bien !
Ceci dit, je ne pense pas que le nombre de combinaisons va "totalement" exploser. On va effectivement avoir un très (très) grand nombre de combinaisons, mais à mon avis, cela va vite converger. Beaucoup de trains mais pas forcément beaucoup de wagons dans chacun d'eux.

Tu peux tenter le coup tout de même ? Ca me serait bien plus utile d'avoir des trains composés des composants impliqués.

[ClaudeLELOUP]

Tu peux tenter le coup tout de même ?

C'est d'abord ce que j'avais essayé, sans succès immédiat.

... mais, pour plagier Descartes : « Il pleut, donc je suis » ... devant l'écran.

[ClaudeLELOUP]

Comment traites-tu le fait qu'un même num_compo ait plusieurs libellés ?



N'est-ce pas la combinaison des deux qu'il faut mettre dans le wagon ?

On aurait alors 58 effets qui sont aussi des causes (contre 43).

[michael_g]

Si la pluie te maintient devant l'écran, eh bien je suis très heureux qu'il pleuve alors

Le fait qu'un même num_compo soit associer à des causes différentes n'est pas un souci pour moi. Si je comprends bien, la conséquence est que l'on aura à certain moment des trains dont certains wagons successifs seront identiques ? Quelque comme par exemple : CCS_SS_1 --> I_SS_3 --> En_SS_2 --> En_SS_2.
A la limite même, les seuls trains qui m'intéressent sont ceux dont tous les wagons sont différents des uns des autres. Les trains possédant au moins 2 wagons identiques m'intéressent pas (ou peu).

[ClaudeLELOUP]

Bonjour,
Ça boucle !

Vois la BdD de travail : http://claudeleloup.developpez.com/&...0v28052014.mdb


Examine ces 3 requêtes :
- rLesCauses
- rLesEffets
- rLesEffetsQuiSontDesCauses
N.B. Le « r » initial est important.

Si tu prends l’exemple de la cause :
CCS_SS_1 Perturbation de la signalisation ferroviaire
elle engendre l’effet :
CCS_SS_2 Perturbation de la signalisation ferroviaire
qui à son tour engendre
CCS_SS_1 Perturbation de la signalisation ferroviaire

Si mon 1er wagon est CCS_SS_1, je lui accroche CCS_SS_2 .
Au tour suivant à CCS_SS_2, j’accroche CCS_SS_1…
C’est une chaîne sans fin !

Vois la table tTrains, c’est le résultat avec les causes limitées à celles contenues dans tLesEffetsQuiSontDesCauses, que j'ai bricolé pour tester.

[michael_g]

Bonjour !

Merci une fois encore pour cette nouvelle BdD de travail.
Alors pour te répondre dans l'ordre.

Les 3 requêtes "rCauses", "rEffets" et "rLesEffetsQuiSontDesCauses" me vont bien. Si je ne m'abuse, elles sont comme les précédentes ("Causes", "Effets" et "LesEffetsQuiSontDesCauses" sans le petit "r" devant) sauf que tu fais apparaître devant chaque cause et chaque effet le numéro du composant qui lui est associé ? Çà me va nickel.

Je comprends mieux d'où peuvent naître les chaînes infinies. Cela dit, bien que je ne sache pas comment ça puisse se formuler sur access, il faudrait que, pour chaque itération successive permettant d'ajouter un nouveau wagon à chaque train, ce nouveau wagon ne soit ajouté que s'il n'est pas déjà présent un peu plus haut dans le train.
Ainsi, chaque train posséderait des wagons en unique exemplaire à chaque fois. Et on éviterait donc des trains du type "CCS_SS_1 --> CCS_SS_2 --> CCS_SS_1 --> CCS_SS_2 --> CCS_SS_1 --> CCS_SS_2 --> CCS_SS_1 --> CCS_SS_2 --> I_SS_6" et on aurait à la place des trains du type "CCS_SS_1 --> CCS_SS_2 --> I_SS_6". Et en faisant comme ça, je pense qu'il n'y aurait plus de chaînes infinies puisque celles-ci semblent naître d'une succession infinie de quelques composants identiques (du type : CCS_SS_1 --> CCS_SS_2 --> [...] --> CCS_SS_1 --> CCS_SS_2). S'il y a plus de composants identiques dans les trains, il n'y a plus de risque de chaînes infinies (je pense).

Ma légère peur dans le fait que tu ailles piocher dans des causes limitées, c'est évidemment qu'on oublie de former d'éventuels trains avec des wagons cause/effet. Du coup, s'il est possible de limiter l'ajout d'un wagon au seul cas où celui-ci n'est pas déjà présent dans le train, je me dis que tu n'as plus à aller piocher dans des causes limitées pour éviter les chaînes infinies.

[ClaudeLELOUP]

Du coup, s'il est possible de limiter l'ajout d'un wagon au seul cas où celui-ci n'est pas déjà présent dans le train

Pas de la tarte !

[michael_g]

Oui, j'imagine très bien !
Désolé de ne pouvoir aider dans la formalisation du programme...

[ClaudeLELOUP]

T'inquiète, c'est plus simple que je ne pensais.

Je vérifie et je te reviens.

[ClaudeLELOUP]

Le processus doit être optimisé : je ne suis pas encore parvenu à attendre la fin du programme avec les données que tu m’as fournies.



Je vais manquer de disponibilité dans les prochains jours, dès que je peux, je m’y attèle.
Le processus est le suivant :
La table tTrains accueille le résultat, j’ai prévu une chaine de 20 causes/effets.
Au départ, on garnit les 2 premières colonnes avec la requête rW1W2 (109 lignes).
Ensuite on lit la table enregistrement par enregistrement pour créer la colonne suivante.
Pour ce faire, on cherche tous les effets possibles pour la cause mentionnée dans la colonne juste à gauche.
On prend la précaution de négliger un effet qui serait, sur cette ligne, déjà mentionné dans l’une des colonnes à sa gauche.
Si la cause est susceptible d’engendrer plusieurs effets éligibles, on duplique l’enregistrement autant que nécessaire.
La table tTrains grossit donc au fur et à mesure : à l’issue du traitement de la 8e colonnes, les 109 lignes sont devenues 562 000 !
Le processus s’arrête quand le programme constate que toute la colonne qu’il vient de traiter est restée vide (pas encore eu le cas avec des données réelles !).
Je voudrais que tu jettes un œil sur le résultat actuel, pour voir si on est sur la bonne voie, ou bien si on doit reconsidérer l’approche en raison de nombre de combinaisons.
Le résultat actuel est ici : http://claudeleloup.developpez.com/&...0v28052014.mdb

[michael_g]

Bonjour,

Merci pour ce nouveau fichier.
Le résultat actuel n'a pas de sens "physique". D'une part parce que le nombre de combinaisons explose totalement (562 000, c'est monstrueux !) et d'autre part parce que les successions de wagons que le programme nous donne n'existent pas tous. Par exemple, prenons le premier (le n°2052575) : CCS_SS_2 --> CCS_SS_1 --> PCC_SS --> I_SS_6 --> I_SS_2 --> I_SS_5 --> G_SS --> I_SS_7. Cette chaîne n'existe pas dès la connexion entre le wagon 2 (CCS_SS_1) et le wagon 3 (PCC_SS) car, quand tu reprends la table initiale AMDEsout, on constate qu'aucun des effets de CCS_SS_1 n'est une cause de PCC_SS !
D'ailleurs, en regardant de plus près, dans la version précédente de tTrains dans laquelle on avait des trains contenant des wagons identiques, certains trains non plus n'existaient pas (au delà de la répétition successive de wagons qui n'avait elle-même pas de sens physique).
De plus, les trains ne devraient à mon avis pas faire plus de quelques wagons. Peut-être 5 ou 6 pour les plus grands trains, mais je suis convaincu que la majorité sera des trains courts. Beaucoup de trains (et encore, quand je dis beaucoup, ça devrait mais peu de wagons dans chacun d'eux ! Le fait donc que le programme arrive déjà jusqu'à 8 wagons ne me semble pas cohérent du tout.

Mais, en y pensant, y a-t-il une étape qui permet de ne prendre que "les effets qui sont des causes" à chaque remplissage d'une nouvelle colonne ? Tu as bien fait ça dans la requête rW1W2, mais je me demande si ton programme fait ça et s'il ne recherche pas à chaque fois dans toutes les "causes" et non "les effets qui sont des causes". Parce que d'après moi, la requête "les effets qui sont des causes" qui devrait être faite à chaque recherche de nouveau wagon devrait donner très vite très peu de résultats. Je veux dire par là que le nombre d'enregistrements dans "les effets qui sont des causes_1", "les effets qui sont des causes_2" puis "les effets qui sont des causes_3" doit drastiquement réduire.

Sinon, à part cette réflexion, je t'avoue que pour le moment, je ne vois pas pourquoi le résultat n'est pas du tout réaliste...

[ClaudeLELOUP]

Bonjour,

Mais, en y pensant, y a-t-il une étape qui permet de ne prendre que "les effets qui sont des causes" à chaque remplissage d'une nouvelle colonne ? Tu as bien fait ça dans la requête rW1W2, mais je me demande si ton programme fait ça et s'il ne recherche pas à chaque fois dans toutes les "causes" et non "les effets qui sont des causes".

Non, je cherche dans les effets... mais tous les effets, quels qu'ils soient. Il faut peut-être distinguer une hiérarchie dans les effets.

Essaie de prendre un cas réel et construis la réponse. Vérifie ensuite ce qu'aurait fait le programme en te servant uniquement de la requête rLesEffetsQuiSontDesCauses. Et n'oublie pas que si l'effet se trouve sur plusieurs lignes de la requête, on démultiplie. C'est sans doute là qu'est l'os. (Y a pas d'hélice hélas...)

[michael_g]

Non, je cherche dans les effets... mais tous les effets, quels qu'ils soient.

Et bien c'est peut-être à ce niveau là que ça coince et que ça nous "invente" des relations de causalité qui n'existent pas (qui se traduit par des successions de wagons qui n'ont pas lieu d'être). Je pense vraiment qu'il faudrait que le programme, lors de la construction de chaque nouvelle colonne, n'aille pas piocher dans tous "les effets" mais bien dans "les effets qui sont des causes".

Et n'oublie pas que si l'effet se trouve sur plusieurs lignes de la requête, on démultiplie. C'est sans doute là qu'est l'os.

Exact, et c'est tout l’intérêt de notre travail ! Mais il est possible que ceci interfère d'une certaine façon... que j'ai dû mal à imaginer.

[ClaudeLELOUP]

D’instinct, donc à vérifier.

Quand on traite la cause qui se trouve dans le dernier wagon (Wn) est éligible comme effet
- celui qui ne se trouve pas déjà dans les colonnes le plus à gauche (de W1 à Wn-1) (ce que le programme fait déjà)
mais en plus
- la cause qui le génère, ne peut pas déjà figurer dans les colonnes W1 à Wn-2.

[michael_g]

Tout à fait d'accord pour l'ajout de la seconde condition.

[ClaudeLELOUP]

Ça tourne depuis 14:42.
La colonne 9 est en cours depuis 16:26.
Ce n'est pas bon signe !

[ClaudeLELOUP]

Bonjour,







À l’issue de la 10e colonne : 2 722 808 combinaisons !

Dans tTampon, tu peux voir la 11e colonne pour les enregistrements traités jusqu’à l’interruption.

Quelque chose nous échappe dans le raisonnement.
Peux-tu, en examinant quelques cas concrets, dire pourquoi il est impossible d’avoir une chaîne ?
Cela nous permettra alors d’affiner le choix du wagon suivant : tel effet n’est possible que
- s’il n’a pas encore été signalé ;
-si sa cause n’a pas encore été traitée ;
- si…

Désolé de ne plus pouvoir intervenir dans cette discussion durant probablement une huitaine de jours.
Le fichier est ici : http://claudeleloup.developpez.com/&...0v28052014.zip

[michael_g]

Bonjour,

Effectivement il y a clairement un problème quand on voit ce que donne le programme. Il ne devrait pas tourner autant de temps et sortir ce nombre faramineux de combinaisons.

J'essaie de reprendre le raisonnement, comme conseillé, sur des cas concrets pour déterminer une liste de conditions à appliquer dans la formation des "trains" à partir des différents "wagons". Je ne suis pas parvenu à de nouvelles conditions encore mais j'y réfléchis et te reviens dès que possible...

[ClaudeLELOUP]

Bonjour,

Prends ton temps : il ne pleut pas encore... !