Version imprimable
Merci de ta réponse,
Dès que j'aurais accès à mon code, je le mettrai, j'imagine que ce sera en effet beaucoup plus simple :)
Edit: petite question, en effet \r\n est le saut de ligne, doit il être considéré comme un seul et unique caractère ou bien comme l'enchainement de \r et \n? J'ai peut être mal interprété l'info donné dans le sujet du projet.
Alors, voilà ce que j'avais fait comme code. Je n'ai pas encore cherché à optimiser quoique ce soit, et je pensais créer quelques méthodes pour faciliter entre autre la lecture. C'est ne quelque sorte une étape "brouillon" (je n'ai pas encore vraiment de méthode:( pas eu ce genre de cours).
En lisant cela je me rend compte d'une erreur, lorsque tampon et lu sont égaux j'incrémente mon nombre d'espaces alors que je ne devrais pas. C'est peut être là l'erreur rencontrée, en effet, si je compte un space en plus alors je sors de mon while, et automatiquement je vais avoir la String pixel qui sera splitée en un tableau de 2 cases au lieu de trois. Ai je tort? EDIT: bah oui j'ai tort, j'ai tampon!=' '...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
Et donc j'ai bien l'erreur: ArrayIndexOutOfBoundsException: 2 (donc l'index 2 est trop grand, non?)
Toutes remarques sera utiles sur ce bout de code, même si je sais bien que ce n'est pas très jolie/très propre (mais j'y travaille :D )
Salut,
C'est le moins qu'on puisse dire : c'est tortueux, et difficile à lire :o. Difficile à exécuter de tête déjà et sans savoir ce que c'est censé faire, difficile de le deviner. Le plus court chemin entre 2 points c'est la ligne droite (si on exclut les pont d'einstein-rosen ;)) :PCitation:
Envoyé par DobbyNouze
Quant à l'optimisation, on en est loin, mais c'est pas la priorité.
Un principe de base : découper le problème principal en problèmes plus élémentaires liés au problème principal, en limitant les interactions entre sous problème, sans s'ajouter de nouveaux problèmes.Citation:
Envoyé par DobbyNouze
Ensuite éviter les changements d'état inutiles, comme les combines de convertir un \n en espace, ou la combine de tampon, que tu es obligé d'initialiser à 'x', genre tu introduis dans le problème une valeur incongrue, qui n'existait pas à l'origine (bon ça complique pas grand chose, mais c'est pour le principe)
Tu dois lire un fichier, une partie taille d'image, une partie max couleur, appelons ça entête, ça fait déjà un sous problème, divisable en 2 autres sous problèmes.
Tu dois lire des couleurs, les regrouper par trois, pour en faire des points, regrouper les points en segment, en testant la rupture entre points lus
Chaque sous problème peut devenir une méthode de la classe, de manière ensuite à travailler sur chaque problème séparément
Bon je vais avoir du mal à voir ce que ça fait sur tes fichiers puisque je ne les ai pas, mais on va essayer de voir 2 ou 3 choses en analysant le code.
ce n'est pas un tampon, appelle cette variable precedentCaractereLu ce sera plus logiqueCode:char tampon='x'; //permet de garder une trace du dernier caractère lu
pourquoi déclarer ces variables ici, alors que tu ne les utilises que bien plus tard et que tu ne t'en sers pas entre itération,Code:int red, green, blue;
On cherche pas à optimiser, mais un StringBuilder serait mieux (de toute manière c'est que java utilisera pour faire ta concaténation String + char)Code:String pixel=new String();
comme je le disais tu oublies le \r. (sauf si tu n'es pas sous windows)Code:
2
3
4
5
la description du fichier ppm n'en parle pas, certes, mais comment être sur qu'il n'y en a pas.
en plus le fait qu'une ligne fait maximum 70 caractères n'est pas traité (a moins qu'une couleur n'est jamais coupée en 2, mais la description de format n'est pas suffisamment précise pour exclure ce cas
Code:
2
3
4
5
tu ajoutes tous les caractères y compris les espaces lus en double (ou plus)Code:
2
tu ne devrais pas ajouter les espaces que tu ne comptes pas
ici on voit que cet ajout d'espaces dans pixel complique le traitement,
si tu avais une classe pixel ou l'espace n'est pas ajouté, mais sert juste à dire il y a une rupture qui fait qu'on a une nouvelle couleur,tu n'aurais pas à gérer ni le retour chariot (à ignorer), ni les espaces consécutifs
donc en gros on a dans pixel un truc comme çaCode:tampon=lu;
[1][5][ ][ ][5][ ][0][ ]
avec ça ton tableau valeurs sera
valeurs[0]="15"
valeurs[1]="" donc problème
valeurs[2]="5"
valeurs[3]="0"
tu fais ça dès que space=3, donc à priori on devrait pas avoir de tableau de taille inférieure à 3. sans déboguer et sans tracer, difficile de voir ou se situe le problème :Code:String[] valeurs=pixel.trim().split(" ");
le premier cas que je vois de prime abord c'est c==-1 avant qu'on ait space==3. mais ça voudrait dire que soit le fichier contient moins de couleur que nécessaire ou qu'on perd des couleur pendant la lecture
le second c'est pas rapport à la garantie qu'on ait au moins une espace avant et au moins une espace après chaque couleur, voici un début de matrice :
15 0 0 15 0 0 ...
je mets des _ à la place des espaces pour qu'on les voit)
_15_0_0__15__0_0_ ...
donc le premier pixel des deux va être
_15_0_ space==3,
donc (ton trim virant les whitespaces avant et après) valeurs serait [15][0], donc bien 2 valeurs
c'est ton système de comptage d'espaces qui pose problème dès le second point s'il y a plus d'une espace entre les 2 points, et en particulier le tout premier (je vois même pas comment ça peut marcher même avec tes fichiers fait sous notepad, à moins que tu ne mettes pas d'espace en début de ligne)
c'est particulièrement vrai au premier passage à la ligne, ou tu introduis une espace supplémentaire en remplaçant le \n par ' ',
il ne faut pas compter les espaces entre les points en gros
a part en déboguant ou en traçant difficile de voir ou se situe le problème, et j'ai pas mon pc de codage sous la main pour le moment.
ajout un System.println(pixel) avant ton split et tu verras immédiatement
oui tu lis valeurs[2] alors que la taille du tableau est 2Citation:
Envoyé par DobbyNouze
Alors merci beaucoup pour ta réponse.
J'avoue m'être laissé impressionné par le sujet, et face aux connaissances que j'ai pour le moment, la manipulation "lecture" du fichier n'est pas encore quelque chose d'ancrer (ça tombe comme ça avec le projet). D'où ma difficulté à bien séparer les pb en sous pb.
Je lirai à tête reposé tes commentaires. Sinon, j'ai fait une trace me donnant les valeurs des variables utilisées et notamment pixel.
Bizarrement avant le plantage l'affichage est bizarre. Je demande l'affichege de la chaine "pixel= "+pixel. Et en fait cette ligne au niveau de "pixel= " est peu à peu effacée et remplacée par la valeur de la chaine pixel.
Je pourrai joindre une copie d'écran ce soir :)
Encore merci de ta réponse, j'espère m'en sortir avec cela. Je vais prioritairement traiter les sous problèmes et donc revoir tout le code de cette partie entre deux révisions :)
Je viens de relire un peu tout ça, et notamment ton post précédent. Je commence à y voir plus clair, vivement ce soir que je puisse coder tout ça.
Je ne connaissais pas le StringBuilder, mais ça me parait plus facile du coup :) mais reste à voir si j'y arrive comme il faut. Tu m'as donné de bonnes pistes, et je vais essayer de sortir le code sans trop "pomper" ce que tu m'as donner. histoire de faire un vrai travail :)
Par contre je ne saisi absolument pas cette méthode:
Peux tu m'en dire plus?Code:
2
3
4
5
6
7
Après ai je bien compris l'utilisation avec le StringBuilder. Je vais lire au final les valeurs de chaque composante une par une et donc les enregistrer une par une dans ma classe pixel. Puis on attaque un nouveau pixel, qui sera soit enregistré dans le même segment ou non.
Comme tu le sais, nous devons intégrer dans une liste chainée les segments. Chaque segment correspondant donc à "un groupe de pixel de même valeur et contigus". Est ce bien d'avoir au final une classe pixel, une classe segment et ensuite la classe ListeSegment? On part du plus simple au plus "complet" d'une certaine façon.
j'ai implémenté la méthode hashCode parce que j'ai implémenté la méthode equals : le contrat de la méthode equals (voir javadoc de la méthode) indique que si a.equals(b) est true, a.hashCode()==b.hashCode() doit être vrai (l'inverse n'est pas obligatoire).
en fait, le but de hashCode est d'avoir un moyen de prétestéer une egalité possible très rapidement : c'est utilisé dans la plupart des List, Set et Map par exemple.
ici l'algo est un algo classique de calcul de hashcode. Habituellement, j'utilise plutôt la classe fournie en pièce jointe.
StringBuilder est une classe qui permet de gérer les chaines à construire progressivement (c'est une classe qui est arrivé avec java 5 : avant il y avait StringBuffer qui fait la même chose, mais qui est synchronisé, ce qui est inutile pour notre cas, et comme c'est consommateur de temps, autant utiliser StringBuilder.Citation:
Après ai je bien compris l'utilisation avec le StringBuilder. Je vais lire au final les valeurs de chaque composante une par une et donc les enregistrer une par une dans ma classe pixel. Puis on attaque un nouveau pixel, qui sera soit enregistré dans le même segment ou non.
l'usage :
tu créé un StringBuilder :
tu peux indiquer une taille initiale :Code:StringBuilder couleur=new StringBuilder();
le principe c'est que cette classe utilise un tableau de char en interne, qu'elle va agrandir au besoin, ce qui est potentiellement couteux. Lorsqu'on est capable d'estimer une taille, autant initialiser le tableau à la bonne taille, pour éviter les création et copie de tableauCode:StringBuilder couleur=new StringBuilder(15);
ici on peut estimer que la taille du buffer est de 3 x la taille d'un pixel, plus les espaces éventuels (2) si tu stocke le pixel entier dans le buffer,
la taille d'un pixel est le nombre de digit nécessaire pour stocker la couleur la plus grande, lue dans l'entête, mais tu peux partir sur 3 (ce qui permet des couleurs de 0 à 999).
ensuite, ajouter un caractère :
facile, non ?Code:couleur.append(lu);
quand tu récupères tes couleurs :
il vaut mieux réinitialiser le buffer que d'en créé un nouveau :Code:couleur.toString().split(' ');
ceci va uniquement remettre à jour le compteur interne de caractère, sans toucher au tableau, on économise ainsi beaucoup de réservation de mémoire, de copie de bloc mémoire, etc...Code:couleur.setLength(0);
De mon point vue, et j'aurais probablement de longues discussions avec des opposants la dessus ;) il est toujours bien de faire une classe plutôt que de faire des traitements alambiqués avec des types de bases, de multiples variables à état, etc... ça permet de simplifierCitation:
Est ce bien d'avoir au final une classe pixel, une classe segment et ensuite la classe ListeSegment?
on sait qu'on stocke trois composants de couleurs par pixel, à chaque fois qu'on tombe sur un whitespace dans le fichier on a la fin d'un composant, sinon on ajoute un nouveau digit au composant,
à chaque fois qu'on à la fin d'un composant, on le stocke et on traite le suivant.
l'algo est hyper simple et le mettre dans une classe à part permet de largement simplifier la mécanique de parsing (on passe en fait d'un algo d'analyse de flux à un algo à "états métier", qui sont la traduction direct de l'ennoncé du problème).
pour ne pas traiter plusieurs whitespace, on peut considérer qu'on ajoute jamais un whitespace au buffer (au StringBuilder), mais que quand on tombe dessus, on doit simplement regarder si une valeur est en attente de finalisation dans le buffer, et si c'est le cas ajouter cette valeur à la liste des valeurs déjà lues, puis réinitialiser le buffer (et dans le cas contraire ne rien faire)
quand on a lu trois valeurs, on peut traiter l'ajout a la liste de segment, qui se traduit comme tu l'a fait : s'il y a rupture dans les valeurs de composant, création d'un nouveau segment, sinon incrément de la taille du segment courant
bien sur tu peux aussi gérer ton pixel avec un tableau de trois entiers et un index que tu incrémentes et que tu compares à 3, à la place de la classe pixel. Le fait de faire des classes permet souvent une meilleur compréhension lorsqu'on revient sur le code : ici le but est de résoudre un problème unique. Inutile de faire des classes pour faire des classes. C'est également un moyen de prendre l'habitude de découper les problèmes en problèmes plus simples et localisés. Mais j'y vois surtout un autre avantage dans le cas d'un exercice : la facilité de lecture du code, pour le correcteur, qui en théorie devrait apprécier, sauf si son système de correction vise uniquement à exécuter le code et à regarder le résultat, auquel cas, tu peux écrire un algo spaguettis aboslument imbitable sans utiliser de classes, ça changera pas grand chose, si ton but est juste la note finale ;
bémol, l'utilisation d'une classe toute faite peut faire penser au prof que tu as tout pompé sans rien comprendre... a toi de voir... en particulier ne reprend pas de méthode de mes exemples si tu ne les utilises pas dans ton algo
par exemple, si tu continues à déterminer ta rupture par
ne reprend obligatoirement pas les méthodes equals et hashCode de Pixel, qui ne servent plusCode:else if(getLastSegment().samePixel(pixel.getRed(), pixel.getGreen(), pixel.getBlue())) //si les valeurs sont les mêmes que le dernier segment de la liste occurence ++
Wow, superbes explications :) encore un grand merci!
Oui je suis d'accord avec toi, ne pas pomper! Je souhaite rendre un code qui reste assez personnel, si je peux dire. Et comprendre ce que je fais, tout en acquérant une meilleure méthode, d'où ma venu sur le forum entre autre. Avis conseils sont bons à prendre. Quand je parle de code perso, c'est avant tout respecter mon niveau actuel par rapport à mes connaissances.
Je pense que ce soir, mon code sera donc amélioré et efficace :) Une fois cette partie faite, je pense que le reste se fera tout seul.
Encore merci de prendre ton temps pour ces explications :ccool:
C'est loin d'être fini, mais mon code est déjà plus lisible :) grâce à tes conseils.
Il faut que j'arrange encore deux ou trois points, mais j'y vois plus clair, ça me parait tellement plus évident d'un coup :)
J'espère pouvoir finir dimanche, et je te dirai ce qu'il en est.
Bon, faut quand même que je dise que ça y est la lecture des pixels et la saisie dans la liste chainée fonctionne jusqu'au bout :)
Une journée de repos avec une bonne nuit a bien aidée faut dire.
Maintenant, je vais m'attaquer à une fonction de lecture de l'entête qui soit "propre". Et aux fonctions de transformation de l'image.
Je pense que cet exercice et tes interventions m'ont débloqué pas mal de choses. Et j'ai appris aussi deux trois petites choses, du moins StringBuilder dont je me sers je pense de manière raisonnable dans mon code et surtout, je comprends ce que je fais! Le prof n'étant pas contre l'utilisation de classe et fonctions faisant partie de la biblio java.
Je te remercie encore. Je pense que le plus dur est fait pour moi, à part le crop de l'image :D mais bizarrement je suis moins inquiet.