Discussion :

[nicom1752]

Aucun problème j'y jetterai un oeil

[eyquem]

«En effet j'ai codé mon premier 'HelloWorld" en C++ quand j'avais 12 ans et ensuite quelques programme de calculs trigonométrique basiques (à l'époque je faisait des rêves avec <include iostream.h> ^^)»
Tu étais dans un pensionnat de garçons ?

«J'ai toujours été fasciné par la puissance d'un ordinateur.»
Idem fasciné. À certains moments, je regarde mon ordi avec frayeur et je me dit: «Lui, il m'a fait en 0.03 secondes ce que je mettrais 3 semaines à faire à la main (sans dormir)»

C'est sympa d'avoir affaire à quelqu'un d'enthousiaste comme toi..


-------------------


Bon, maintenant qu'on est au courant du contexte et du niveau que tu es censé avoir, les buts et chemins sont plus clairs.
Voici ce que je pense.

Les contraintes de l'évaluation et tes scrupules limitent les possibilités.
C'est d'ailleurs bien pour ces raisons que tu dis que je n'aime pas balancer du code prémaché sans laisser quelqu'un réfléchir et que je ne me suis pas précipité à débiter du code.

On va utiliser ce que tu as vu en cours et ce que tu es autorisé à raisonnablement découvrir par toi même dans les docs. Tu as quand même le droit d'utiliser des choses simples même si elles ne sont pas dans le cours , j'espère ?

Alors premier point tu as raison: il faut mettre les regex de coté pour le moment. De toutes façons ce n'est pas en apprenant les regex seulement qu'on apprend la programmation.

Je suis d'accord avec Matthieu B., il faut écrire ton code «avec des outils que tu maîtrises» , mais je suis d'accord à moitié seulement , parce que je ne partage pas cette idée :«ensuite je pense essayer de l'améliorer encore » et «Commence par modifier au fur et à mesure ton script ».
Personnellement je n'arrive pas à raisonner comme ça, j'ai besoin d'envisager les choses avec un certain regard global. Or je répète: ton code est mal parti algorithmiquement. Même si on abandonne les regex, il y a quand même moyen de traiter ton problème avec plus d'agilité.

Donc je pense qu'il faut viser dès le départ une qualité algorithmique suffisante et apprendre le mimimum requis des moyens nécessaires pour le faire, parce que d'après moi, les possibilites de changements qu'on peut faire dans un code sont de plus en plus restreintes à mesure que le développement du code est avancé. Et quand on veut réorienter un code sur d'autres options, ça nécessite la plupart du temps des reprises relativement profondes, sinon ce n'est que des petits changements mineurs.

Il y a donc des choses incontournables à maitriser si on veut faire un code un minimum correct, et il faut les acquérir si on ne les a pas.


-----------------------------------------


Et si on rentrait dans le vif du sujet ?

Tu as raison, on va travailler en liste de lignes, ce sera plus simple pour ce premier code que tu as à rendre.

Je n'arrive pas à trouver acceptable l'algorithme de découpage des articles que fait ta fonction La-Mal-Nommée.
Si tu me dis que votre prof vous force à itérer sur des lignes et les aggréger successivement les unes après les autres dans une variable que tu appelles cache avant de traiter les données qu'elles contiennent, alors là je dis stop. Je juge personnellement que c'est une horreur.

Une solution serait de te débrouiller pour faire du slicing de chaque article en entier c'est à dire savoir quel ensemble de lignes prendre d'un coup avec une instruction du genre li[j:k]
Le slicing est un truc fondamental à intégrer, on ne va pas attendre la fin du doctorat pour apprendre ça non ?
Tu peux déterminer les j et k de chaque article au moyen de find(), compte tenu que la première ligne d'un article commence par 'n: ' et la dernière par 'PMID: '

Mais c'est dommage de procéder ainsi alors que ton texte a une structure très fortement formatée: succession de blocs et de lignes vides.
Une ligne vide se détecte par if ligne=="": et quand on détecte une ligne vide, on sait qu'on passe à un autre bloc.
En fait les lignes vides sont comme des traits de séparation qui formatent de façon très définie le fichier.
C'est sur elles qu'ils faut appuyer le traitement du texte.
On doit donc immédiatement penser à parcourir la fichier du début à la fin pour détecter les blocs les uns après les autres et les envoyer dans des variables d'une façon logique les uns après les autres, c'est a dire sans attendre d'avoir parcouru tout un article

Chaque article est composé de:
- une ligne "support de publication (revue, date) qui commence par 'n: '
- ligne vide
- bloc "titre"
- ligne vide
- bloc "auteurs"
- ligne vide
- bloc "organisme de rattachement"
- ligne vide
- bloc "texte"
- éventuelle ligne vide suivie de
- éventuel bloc "Publication Types" quand il existe
- ligne blanche
- ligne "PMID indexation:
- ligne blanche
- nouvel article

Chaque article est donc encadré par deux lignes vides et contient 5 ou 6 lignes vides.

Pour parcourir une liste de lignes, on peut faire
for ln in li:
Mais certains blocs des articles sont composés de plusieurs lignes et on va avoir besoin des indices de début et de fin des blocs pour slicer la liste de lignes. Il vaut mieux donc faire

Code :

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

1
2
for i,line in enumerate(li):
    test sur line

Voila je te laisse coder le parcours du fichier avec ces indications pour faire ce qui suit:

- détection de la première ligne d'un article --> on enregistre l'indice de la ligne dans une variable
- on passe à la ligne suivante, si elle est vide on traite la ligne de titre (la précédente) pour en extraire les données du support de publication
- on passe à la ligne suivante, on repère son indice
- ligne suivante: si vide, on met la ligne précédente dans une variable Titre
- on passe à la ligne suivante, on repère son indice
- ligne suivante: si vide, on met la ligne précédente dans une variable Auteurs
- on passe à la ligne suivante, on repère son indice
- ligne suivante: si vide, on met la ligne précédente dans une variable Organisme de rattachement
- on passe à la ligne suivante, on repère son indice j
- on passe des lignes jusqu'à trouver une ligne vide, d'indice k
On découpe li[j:k] et on met ce morceau dans une variable Texte.
- on passe à la ligne suivante, normalement c'est la ligne PMID, on met cette ligne dans une variable PMID

Tout ceci étant à coder, pour obtenir directement lors du parcours du fichier les données de chaque article,
alors que dans ton code pour le même effet tu fais une accrétion de lignes, tu passes article_full à une fonction addtodict qui elle même doit passer la même valeur article_full à une deuxième fonction donnes_traitement() dans laquelle tu fais un traitement pour trouver les différentes données d'un article, pour cela en devant préalablement faire un traitement des lignes du textes pour en faire une seule chaine......

Bien sûr, les choses ne sont pas aussi simples:
- il peut y avoir un bloc "Publication Types" avant d'arriver à la ligne PMID.
- le titre n'est pas toujours sur une seule ligne, le bloc Auteurs prend parfois plus d'une ligne, de même pour la plupart des blocs Organisme de rattachement. C'est pour ça que j'ai écrit "on note l'indice de la ligne", parce qu'il se peut, si la ligne suivante n'est pas une ligne vide, qu'on doive faire un traitement de bloc jusqu'à trouver l'indice de la dernière ligne de ces blocs afin de faire un découpage comme pour le bloc Texte, quand c'est nécessaire. Mais je n'ai pas détaillé plus, c'est à toi d'écrire les lignes if nécessaires pour gérer ces cas.

Mais le principe est là et une fois qu'on voit l'objectif, il faut tenir mordicus dans la direction en recherchant au besoin les outils nécessaires pour y parvenir en simplifiant les choses.

Par exemple, à ce sujet, un tuyau:

Code :

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

1
2
3
4
>>> lista = ['vent','soleil','nuages','ocean']
>>> print '##'.join(lista)
vent##soleil##nuages##ocean
>>>

On peut remplacer '##' par un blanc ' ' ou rien du tout "".



J'ai mis en bleu des réflexions du genre de celles qui permettent de progresser vers un principe d'algorithme. Apprendre à programmer est à mon avis pour partie apprendre à se faire ce genre de réflexions qui opèrent comme des tilts dans le raisonnement.

Un de ces tilts que tu aurais dù avoir est le suivant:
Dans ton code, tu voulais déclencher la fonction addtodict() une fois parvenu au bout de la lecture d'un article, et donc tu t'es dit il faut que je détecte la fin d'un article.
Et là, truc bizarre, tu te dis, "détecter la fin d'un article est équivalent à détecter le début du suivant". Certes. Mais ça ne marche pas pour le dernier. Alors pourquoi s'obstiner dans cette idée ? Il faut aussi savoir faire marche arrière et se dire: si je veux détecter la fin d'un article et que je n'y arrive pas avec le debut du suivant, il FAUT que je trouve un moyen de détecter ...la FIN de l'article. À partir de là, le raisonnement qui n'est plus obsédé par ce qu'il y a ou n'y a pas après un article s'aperçoit que la ligne PMID fait très bien l'affaire, non? Bizarre cette façon de déplacer le problème légèrement et de rester coincé dans la difficulté ainsi créée



------------------------------


Il y a d'autres choses encore à voir. Mais l'une des plus importantes est celle-ci.Dans ton code, tu enregistres sous chaque clé 'title' un dictionnaire
{'article' : article_full,'donnees' : donnes_org,'keywords' : keywords_org}
Par conséquent, tu constitue un dictionaire constitué de 5744 fois un item du type
n:{'article' : article_full,'donnees' : donnes_org,'keywords' : keywords_org}
c'est à dire
que
ton dictionnaire threads (berk le nom) comporte une information qui est pour une partie la répétition de 5744 fois le mot 'article', pour une autre partie 5744 fois le mot 'donnees', et pour une troisieme part 5744 fois le mot 'keywords',
c'est à dire, si je ne me trompe pas 126 368 octets consacrés à contenir l'information "article,donnees,keywords" !
À quoi ça sert ?
Je te laisse réfléchir à la simplification à faire pour réduire le bourrage de ton dico.



Après tout ça , cela commencera à aller mieux. Et on passera à la fonction keywords_traitement()

[nicom1752]

C'est vrai que maintenant que tu le dis mon code ressemble à une usinagaz...
Le fait est que j'ai du commencer les révisions de mes partiels et que je n'ai pas pu repasser avant...

J'admet que ta méthode est très intéressante... C'est vrai que j'aurai pu procéder par comptage des lignes en fait, enfin de lignes blanche, je n'avais absolument pas vu cette possibilité, si bien que je me sens très bête de pas être revenu avant... (j'ai rendu mon devoir ce midi).

En fait c'est vrai que je me suis un peu mis des oeillères en abordant le code de cette façon. Je pense que je vais continuer à l'améliorer mais d'abors je veux (enfin) réussir quelque chose de concret en CGI. Mais réecrire mon code avec cette nouvelle technique va m'être bien utile si je veux créer moi même mes bases de données.
Voilà donc mon prochain objectif et de tuer php dans l'oeuf (en tout cas ds l'esprit ^^). Et je vous poste ce que j'ai finalement pondu (bon, je trouve ca pas trop mal, personnellement ), ici.


Merci à tous de votre aide et surtout pour les outils de test de code permettant de voir les vitesses de chaque fonctions, ca & changé ma vie
Pendant les vacances je réecris le code et je reviens avec encore plus mieux

Au fait si quelqu'un sait comment on peu arriver à ça, je suis preneur : http://www.google.com/support/a/bin/...er=53927&hl=fr