Discussion :

[Félix Guillemot]

Bonjour

Vu que tout le monde se tire la bourre sur les temps de résolution...
et vu que la rapidité sera un des éléments pris en compte
et vu que je n'ai pas le temps de me mettre à l'assembleur
Quel est le temps raisonnable à ne pas dépasser pour une grille selon son niveau
Mon solveur est loin d'être une formule 1
Et j'ai encore pas mal de méthode à coder, même si j'ai quelques pistes pour éviter des boucles inutiles

Ne t'en fais pas, l'assembleur ne fait pas tout, d'après Franck, c'est même inutile. Mets toi à la place de l'utilisateur, il ne faut pas qu'il ait le temps de se faire cuire un oeuf en attendant la solution. Disons que si tu veux être dans les bons solvers, il faut que ça soit quasi immédiat, allez pas plus d'une seconde.
Après, il est vrai que les participants se sont focalisés sur le concours de nano-secondes, pourquoi pas après tout, ça ne me dérange pas si ça amuse, c'est le but.
Maintenant, de vous à moi, que ça mette 1ms ou 0.1ms, je m'en fiche complètement, pour mon cerveau, ça revient au même !

L'optimisation est un exercice à part entière, et certains ont un savoir faire indéniable.
Personnellement, lorsque je réalise des logiciels pour mes clients, il faut que ça aille vite ou du moins que la vitesse ne les retarde pas dans leur travail.
Si un traitement trsè lourd commence à prendre du temps, là je fais un effort d'optimisation, mais pas quand le temps d'exécution est immédiat !

Donc je fournis l'effort quand c'est nécessaire, sans en faire une maniaquerie.
D'une manière générale, il vaut mieux optimiser son code au mieux pour ne pas à avoir à le faire ensuite quand on se rend compte un beau jour que les temps sont catastrophiques, donc je programme proprement quand même
C'est pour cela que mon solver met entre 1 et 80ms et voila, je m'en fiche. Si je n'ai que ça à faire, je me pencherai sur la question en détail.

Mais il y a d'autres aspects de l'application : son ergonomie, sa maintenabilité, son esthétisme (pourquoi pas hein ?).

Donc voila ma réponse à ce sujet.

Tout est une question d'équilibre dans la vie, la voie du milieu, pour ceux qui ont lu l'Alchimiste...

Félix.

[Félix Guillemot]

Mick

Voila comment a priori les joueurs résolvent Ai
Ils sont bien sur obligés de faire des hypothèses
Le problème est de savoir laquelle

Il a plusieurs méthodes mais la plus 'efficace' est celle la: tu cherche sur le grille le sous-ensembles qui a le moins de candidat pour AI c'est C3 . Donc ils posent arbitrairement 2 en case 3 puis passent en C12,C39....
C'est un EXEMPLE la méthode n'est pas obligatoire ou systematique .

Boris

Je suis désolé Boris, mais c'est insuffisant, ça on le savait déjà, cherche un peu plus...

[Félix Guillemot]

Tenez une petite grille sympathique nommée Easter Monster:


C'est une grille à solution unique. Elle est à mon avis aussi complexe (peut-être plus) qu'AI Escargot.

@+ Claudius

A priori, elle pose moins de problème à mon algo que AI Escargot (30ms contre 70ms)

Mais méthode profonde, hélas

[Cl@udius]

Pour ma part:

• AI Escargot: 17 ms
• Easter Monster: 34 ms

J'en conclus donc qu'il sera très intéressant de comparer nos différents algos.

[FullSpeed]

Merci SHAI

Mais comment on lit le résultat ?
J'obtiens 325669871 . J'en fais quoi pour le mettre en millisecondes



ASM il faut faire attention avec son usage. Il est parfois inutile c'est parfaitement vrai car les compilateur sont de plus en plus performants
Mais il reste essentiel pour acceder a des technologies specifisue
Par exemple si tu veux acceder au SSE2 ou 3 il' n'y a a pas d'ointerfacage avec Delphi donc tu es obligé de passer en ASM

Mais le recours a l'ASM systématique n'est pas obligatoire.
Resservons le à des accès à des technologies inaccessibles

Boris

[Rekin85]

Bonjour à tous ces balaises du sudoku !

Je ne participerai pas au défi en cours car je n'ai aucune attirance pour ce genre de jeu. Mais je reconnais que je suis un lecteur assidu de cette discussion particulièrement intéressante où l'on voit poindre un véritable concours d'ingéniosités. Bravo à tous, MAIS... une certaine dérive commence aussi à poindre : "j'arrive à faire pipi plus haut que toi..."

Je n'attaque personne, je m'explique. De l'ensemble des échanges ici présents on peut distinguer l'affinement du cahier des charges de ce défi : tout est pris en compte à ce qu'il paraît : l'ergonomie, le look, la propreté du code, sa portabilité, etc, etc... Fi de la vitesse surtout ? Or il semble bien que les compétiteurs ne s'apostrophent souvent que sur ce seul critère et je dis que c'est un peu normal. Pour ma part je suis nul en design et chiader une interface d'utilisateur version Coco Chanel, je suis forcément perdant, mais si d'évidence on me chatouillait sur l'algorithmique, là je serais capable de bien des prouesses, peut-être (à condition d'être motivé et inspiré...).

N'aurait-il pas été tout aussi judicieux de limiter ce défi-concours à la programmation des algorithmes de résolution des grilles ? Quitte à imposer l'interfaçage d'entrées-sorties ?

N.B. Comme je ne suis que spectateur, mon avis n'a aucune importance, bien sûr. Participer voudrait dire qu'on accepte le réglement, c'est l'évidence sportive.

[Franck SORIANO]

Franck tu poses le problèmes des treads
Celles ci font parties integrante de Dephi donc leur usage est surement autorisé
Le problème se pose avec les multi coeur
Ta tread a de forte chance de se retrouver sur un coeur inactif
et la en toute honnêteté tu vas te servir de plusieurs processeurs
et fausser les chronométrage.

Je ne vois pas trop ce qui te perturbe. Evidemment j'utilise plusieurs coeurs et un seul processeur (ma machine est un Core 2 Quad, 1 seul processeur et 4 coeurs), c'est bien le but du multi-threading, faire plusieurs calculs en même temps.
Pour mesurer le temps, c'est très simple. La solution a déjà été donnée au début de la discussion et expliquée par ShaiLeTroll :
- Dans le thread principal, avant de lancer la recherche tu mesures une date avec QueryPerformanceCounter.
- Tu lances la résolution de la grille en appelant la méthode qui va bien de ton solveur. Ce dernier fait ce qu'il veut pour faire la résolution, en utilisant le multi-threading ou pas. Lorsqu'il a terminé il te rend la main.
- Lorsque la résolution est terminée, tu lis à nouveau la date avec QueryPerformanceCounter et tu convertis le résultat du calcul en unité de temps en te servant de QueryPerformanceFrequency.

C'est la technique la plus simple pour avoir facilement un chrono un rien précis et fiable.
Maintenant dans la vrai vie, je travaille différemment : Je passe par Event Tracing for Windows (ETW) (cf: ma signature et tous mes articles). Mon programme est instrumenté pour générer des traces : Une petite trace au début du traitement, une autre à la fin du traitement, puis tu lances l'appli et tu regardes la trace qui s'affiche en temps réel.
Chaque message est horodaté avec une précision de 100 ns. Tu te retrouve ainsi avec un profil d'exécution très précis de ton traitement, qui te permet à la fois de voir ce qui se passe à l'intérieur de ton appli, et voir ton algorithme qui se déroule, tout en mesurant les temps d'exécution...
Pour optimiser ou débugger une appli en production, il n'y a pas mieux. D'ailleurs depuis Windows Vista, pratiquement tous les services et API systèmes sont instrumentés avec ETW !

Ce n'est pas une intuuition pour moi, c'est une quasi certitude (disons que je laisse 0.0001% de chance au cas où ) : Si un sudoku n'a qu'une solution, il DOIT pouvoir être résolu avec une méthode logique, et c'est précisément là qu'il y a un enjeu dans ce défi.

Moi personnellement, je pense plutôt la chose suivante : prenons le cas d'une démonstration mathématique.
Partant de A on sait démontrer B.
Partant de B on sait démontrer C.
Partant de C on sait démontrer A.
Donc au final on aura A => B => C => A.

Seulement même si à la fin le tout arrive a tenir ensemble, ça ne veut pas dire que A est vrai, B est vrai et C est vrai, car si les trois sont faux, la boucle d'implication n'est pas vrai.

Pour moi le Sudoku c'est la même chose...

[Franck SORIANO]

N'aurait-il pas été tout aussi judicieux de limiter ce défi-concours à la programmation des algorithmes de résolution des grilles ? Quitte à imposer l'interfaçage d'entrées-sorties ?

Ou est le défi ? Si on donne les algos et qu'on dit : implémenter les, ce n'est plus qu'un cas d'école ! Il n'y a plus a réfléchir, ça devient un bête codage automatique d'une solution existante et analysée par quelqu'un d'autre... On ne voit ça qu'à l'école !

Il est bien plus intéressant de poser les choses tels qu'on les rencontre dans un context professionnel :
- Voilà le problème auquel on est confronté. On ne sait pas comment le résoudre, ni même s'il est simplement soluble.
- Débrouille toi pour trouver une solution qui permette de resoudre le problème tout est respectant les contraintes du plan qualité !

Après bien sûr, tu as toujours tendance à dévier sur tes goûts personnels, à favoriser des critères dont toi seul te préoccupe... et à la fin tu te prends une baffe parce que ton appli dont tu es super fier ne répond pas aux attentes des utilisateurs !
Un bon développeur c'est celui qui sait respecter son cahier des charges, faire ce qu'on lui demande, et si c'est un professionnel : à moindre coût (dev initial, maintenance, exploitation, déploiement...).

[Rekin85]

Ou est le défi ? Si on donne les algos et qu'on dit : implémenter les, ce n'est plus qu'un cas d'école ! Il n'y a plus a réfléchir, ça devient un bête codage automatique d'une solution existante et analysée par quelqu'un d'autre... On ne voit ça qu'à l'école !

Je me suis mal fait comprendre en partie, je crois : il ne s'agit pas de se contenter d'implémenter, il faut créer les algorithmes sur des idées personnelles. Je pousse à l'excès pour corroborer mes dires : certains ont parlé de méthodes machin ou truc. Alors je les implémente et je fais tout cela dans de la belle confiture d'interface. Et bien je n'ai rien créé, j'ai plagié...

Mais je répète, il ne faut pas s'attarder à mes avis : vive ce concours.

[ShaiLeTroll]

C'est pas mal, mais moi perso, je ne sais pas ce que sont les CoreCellDummies.
j'utilise aussi la langue anglaise dans les noms de procs etc, je pense que c'est le mieux dans ce monde et pour rester dans les standards.
Par contre, tu pourrais dire rapidement ce que fait ta fonction, commenter la déclaration du TByteDynArray.
je dis ça comme ça...

Tout à fait, faut que j'indique ce qu'est la propriété CellDummies ! C'est justement les fameux commentaires utiles ... en fait, je respecte les standards DelphiToDoc, j'ai juste mis les cartouches vite fait pour le moment

TByteDynArray, unité Types de Delphi 6 ou +
J'utilise pour ma part le Franglais

En fait mon interrogation portait plus sur l'utilisation de pointeur, de transtypage, ... mes chefs n'aiment pas du tout ...

Sinon Relaxe les Gars, moi je suis une quiche en Sudoku, je mets bien 10 minutes pour une grille facile sur Dr Kawashima DS, ... mes idées d'algo sont basé sur une approche totalement au feeling et ben la 1ère idée c'est passé, pour la résolution profonde, j'espère pareil ... ça sera pas rapide, mais j'espère faire un code plutôt court ... surtout pas trop de boucle, je m'y perdrais ...

[FullSpeed]

On est bien d'accord sur le multiteading: touit le monde peut d'en servir et essayez d'en tirer avantage
Ce qu je veux dire c'est que temps que ton code tourne sur un mono coeur
on se sert du multitraitement et TOUS les traitements sont effectués dans la meme unité
Au plus malin de savoir d'en servir

Quand tu passes en mufti cœur le multitraitement regarde si il a pas un coeur qui ne fait rien. Si oui il le charge de ta tache et tu te trouves avec du code qui s'execute dans deux ou plus UAL qui ne partagent que le cache
Au dela du gain de performance physique tu peux allez plus loin et inclure cette distribution dans ton algo.
Il 'marchera' moins bien sur les vieilles machines mais galopperas sur les ressentes.On est habitué

Ce n'est pas grave sauf pour celui qui n'a pas cette techno. Il ne peut pas faire d'essais et modifier sa logique. C'est juste un souci d'équilibrage il ne faudrait pas qu'un participant puisse se sentir lésé car il ne dispose pas de la derniere techno.

Je ne parles pas pour moi j'ai ce qu'il faut mais je pense a notre mick avec son 286 a 500 htz et 640 Ko (tu as des disquiettes 720 Ko?)

[Félix Guillemot]

Tout à fait, faut que j'indique ce qu'est la propriété CellDummies ! C'est justement les fameux commentaires utiles ... en fait, je respecte les standards DelphiToDoc, j'ai juste mis les cartouches vite fait pour le moment

TByteDynArray, unité Types de Delphi 6 ou +
J'utilise pour ma part le Franglais

En fait mon interrogation portait plus sur l'utilisation de pointeur, de transtypage, ... mes chefs n'aiment pas du tout ...

Sinon Relaxe les Gars, moi je suis une quiche en Sudoku, je mets bien 10 minutes pour une grille facile sur Dr Kawashima DS, ... mes idées d'algo sont basé sur une approche totalement au feeling et ben la 1ère idée c'est passé, pour la résolution profonde, j'espère pareil ... ça sera pas rapide, mais j'espère faire un code plutôt court ... surtout pas trop de boucle, je m'y perdrais ...

Moi personnellement, je n'ai contre la syntaxe qui utilse les ^ ou @ si ça se justifie...ici, j'en doute un peu mais bon...

PSudokuSolverDataStruct(FCores.Items[ACore])^

c'est pareil que FCores.Items[ACore] non ?

Pourquoi accéder au pointeur sur les datas puis aux datas de ce pointeur alors que tu as déjà les datas ?

Tu peux aussi faire StrToInt(IntToStr(5)) mais c'est pareil que 5

Bref, je pense que c'est un peu hors débat ici, mais je serais assez d'accord avec tes chef sur cet exemple précis.

Dans l'hygiène de code, je vois surtout l'indentation, l'utilisation de la casse, les commentaires, pas de routines de 4km, etc.

Je te propose de te rendre sur ce débat de developpez pour avoir mon avis sur la question...

ou encore mieux si tu veux mon avis : ici

Je ne suis pas forcément pour DelphiToDoc, pour des raisons que tu comprendras en me lisant.

A+

[Félix Guillemot]

Je me suis mal fait comprendre en partie, je crois : il ne s'agit pas de se contenter d'implémenter, il faut créer les algorithmes sur des idées personnelles. Je pousse à l'excès pour corroborer mes dires : certains ont parlé de méthodes machin ou truc. Alors je les implémente et je fais tout cela dans de la belle confiture d'interface. Et bien je n'ai rien créé, j'ai plagié...

Mais je répète, il ne faut pas s'attarder à mes avis : vive ce concours.

Ta remarque d'origine n'est pas déplacée, mais elle ne s'intéresse pas à tous les messages.
En effet, nous avons tout fait avec Franck pour rappeler les objectifs de ce défi, qui n'est pas un concous de "celui qui fait pipi le plus haut" comme tu l'écris si bien.
Si tu lis tous les threads également, tu verras que chacun y vas de sa méthode et qu'il y a une réflexion méthodologique, ce qui moi m'intéresse beaucoup plus déjà.
Donc, il ya de tout, ce qui fait plaisir, ce que ça fait couler de l'encre ou plutôt que ça use les claviers...
Ensuite, si tes goûts se portent plus sur l'optimisation qu'autre chose, c'est ton droit et d'ailleurs, nous l'avons inclus dans le jeu.
Il y a beaucoup de développeurs (dont moi) qui sont pluridisciplinaires et qui aiment l'esthétisme (du code et de l'interface), et qui aiment l'ergonomie, c'est un boulot à proprement dit, il y a des gens qui font des études d'ergonome.
Le métier de développeur est riche, il s'intéresse aussi aux autres, c'est à dire les utilisateurs, un challenge d'ouverture.
Il est également créatif, une de mes raisons principales de mon attirance pour ce métier, construire des outils qui sont utiles aux autres et qu'on peut clôner à l'infini, bref...tout un art qui ne se limite bien évidemment pas à la performance.

[Félix Guillemot]

Moi personnellement, je pense plutôt la chose suivante : prenons le cas d'une démonstration mathématique.
Partant de A on sait démontrer B.
Partant de B on sait démontrer C.
Partant de C on sait démontrer A.
Donc au final on aura A => B => C => A.

Seulement même si à la fin le tout arrive a tenir ensemble, ça ne veut pas dire que A est vrai, B est vrai et C est vrai, car si les trois sont faux, la boucle d'implication n'est pas vrai.

Pour moi le Sudoku c'est la même chose...

J'ai l'impression que tu fais allusion à un syllogisme, ce qui pour moi n'est pas le cas des méthodes de résolutions logiques que l'on essaye de trouver.
Si tu construis une Grille de Sudoku avec une et une seule solution, c'est que tu t'appuies sur des règles logiques pour que la grille réponde de ces règles.
Il ya bien une trame logique qui mène du néant, c'est à dire la grille vide vers cette combinaison.
Ce n'est pas parce qu'on ne trouve pas cette trame logique qu'elle n'existe pas.

Je pourrais aller plus loin dans ce débat mais ça serait dévoiler entièrment ma façon de voir les choses que tu connais en tant qu'organisateur, donc restons en là...

[FullSpeed]

Merci pour vos infos
J'ai maintenant le meme genre de resultat que vous
Cela rassure de pouvoir comparer: j'ai l'impression d'etre le seul a avoir code les contraintes....

Je répond au passage au visiteur et a ses remarques obligeantes:
tout le monde n'a visiblement pas choisi la meme voix. Chacun est allez vers une approche qui l'interclassait
A la fin on aura des implémentations sérieuses pour voir si l'une est meilleure quie l'autre Mais surtout on aura echangez autour d'un sujet qui nous intyeresse tous l'info

Boris

[ShaiLeTroll]

Moi personnellement, je n'ai contre la syntaxe qui utilse les ^ ou @ si ça se justifie...ici, j'en doute un peu mais bon...

PSudokuSolverDataStruct(FCores.Items[ACore])^

c'est pareil que FCores.Items[ACore] non ?

en fait FCores est une TList, donc Pointer non type, ... d'où le cast, cela peut être effectivement encapsulé dans une TCoreList ... ce que je ferais si j'ai le temps ...

Pourquoi accéder au pointeur sur les datas puis aux datas de ce pointeur alors que tu as déjà les datas ?

Hein ? oui sans savoir que FCores est une TList ta méprise est compréhensible

Je programme pas mal à l'ancienne, j'ai des objets qui souvent me servent que pour encaspuler des traitements sur un record interne ... ensuite je suis flémard, la solution de faire un pointer sur record, et pouf je pars dans un délire ...

Je vais lire ces sujets ...

[Félix Guillemot]

en fait FCores est une TList, donc Pointer non type, ... d'où le cast, cela peut être effectivement encapsulé dans une TCoreList ... ce que je ferais si j'ai le temps ...


Hein ? oui sans savoir que FCores est une TList ta méprise est compréhensible

Je vais lire ces sujets ...

J'avais bien vu que c'était une TList

Dans ce cas là, tu devrais écrire

TSudokuSolverDataStruct(FCores.Items[ACore])

[ShaiLeTroll]

PSudokuSolverDataStruct c'est un Pointeur de Record TSudokuSolverDataStruct ce n'est pas un objet, sinon j'aurais utiliser une TObjectList et non une TList ! Je te le dis à l'ancienne !
Avec ce que tu as écrit c'est "Transtypage Incorrect" garanti !
Je sais, je pourrais faire des objets à la place des records, je n'en ai pas toujours le réflexe ... je le ferais en phase de refactoring ...

Ah, un vrai record de D6 pas les speudo record\objet qu'y sont apparu en Delphi 200x que je n'ai pas encore testé d'ailleurs ...

[mick605]

Je ne parles pas pour moi j'ai ce qu'il faut mais je pense a notre mick avec son 286 a 500 htz et 640 Ko (tu as des disquiettes 720 Ko?)

J'ai dit ca moi ??? Si oui, je parlais surement de mon ancien PC ... La je suis sur un Core Duo avec 3Go de RAM 226 GHz Ca change ...

Mick

Voila comment a priori les joueurs résolvent Ai
Ils sont bien sur obligés de faire des hypothèses
Le problème est de savoir laquelle

Il a plusieurs méthodes mais la plus 'efficace' est celle la: tu cherche sur le grille le sous-ensembles qui a le moins de candidat pour AI c'est C3 . Donc ils posent arbitrairement 2 en case 3 puis passent en C12,C39....
C'est un EXEMPLE la méthode n'est pas obligatoire ou systematique .

J'avais vu pour cette hypothese ... En tout cas, il suffit de poser une hypothese sur une case qui a le moins de candidats possibles

Je dois dire que je suis bluffé par ta maturité de réflexion à 18 ans !
Ton raisonnement est excellent, tu viens de redécouvrir un concept labyrinthique. Il est clair que si tu pars du coeur du labyrinthe, tu vas trouver la sortie alors qu'en passant par l'entrée, c'est plus complexe évidemment, ce n'est pas qu'une intuition, tu l'as raisonnée.

Merci !!

Imaginez que Mick trouve LA méthode logique qui manque pour vaincre AI Escargot et qu'ensuite on optimise le tout avec Full Speed ou Franck, je crois qu'on tient là un bel article, et je vous promets d'en faire la promotion !

Allez les gars, au boulot !!

Pourquoi AI Escargot 70ms ?
Ce n'est certainement pas par hasard que c'est la grille dite la plus dure du monde !

Non, ce que je voulais dire, c'est "qu'est ce qui change tant dans ta méthode de résolution" ? Tu poses plein d'hypotheses ?


OutOfRange > Je n'utilise pas du tout d'assembleur dans mon code, pour deux raisons :
- Je ne pense pas que ce soit utile ...
- Je sais pas m'en servir

... l'ergonomie, le look, la propreté du code, sa portabilité, etc, etc... Fi de la vitesse surtout ? Hors il semble bien que les compétiteurs ne s'apostrophent souvent que sur ce seul critère et je dis que c'est un peu normal.

Pas du tout, (enfin pour ma part), mais comment veux tu comparer les interfaces via un forum ?
"Ouah, a un moment j'ai mis un bouton ... trop bien"
Non serieusement, pour ma part, j'ai fait une interface simple et (je pense) complete, donc ...

N'aurait-il pas été tout aussi judicieux de limiter ce défi-concours à la programmation des algorithmes de résolution des grilles ? Quitte à imposer l'interfaçage d'entrées-sorties ?

Non, apres tout, ca fait partie du programme ... Quand on utilise un logiciel, on se soucie beaucoup de l'interface, elle doit donc être prise en compte
Je n'ai (moi non plus) jamais fais de design !

Moi personnellement, je pense plutôt la chose suivante : prenons le cas d'une démonstration mathématique.
Partant de A on sait démontrer B.
Partant de B on sait démontrer C.
Partant de C on sait démontrer A.
Donc au final on aura A => B => C => A.

Seulement même si à la fin le tout arrive a tenir ensemble, ça ne veut pas dire que A est vrai, B est vrai et C est vrai, car si les trois sont faux, la boucle d'implication n'est pas vrai.

Pour moi le Sudoku c'est la même chose...

Je ne raisonne pas comme toi. Partons sur une autre logique : si un "4" doit aller dans une case précise, il y a bien quelque chose qui oblige ce 4 a aller dans cette case. Ce quelque chose peut etre plus ou moins tordu, peut dépendre de plusieurs autres cases, mais oblige le "4" a aller ici et pas ailleurs.
C'est une autre maniere de voir les choses ...

Je pousse à l'excès pour corroborer mes dires : certains ont parlé de méthodes machin ou truc. Alors je les implémente et je fais tout cela dans de la belle confiture d'interface. Et bien je n'ai rien créé, j'ai plagié...

De toutes facons, les méthodes de résolution sont tres générales : si deux méthodes sont des Brutes Force, ca voudra pas dire que l'une est copie de l'autre. "Alors je les implémente" : ben c'est la que se situe la plus grande difficulté ...



Voila, bon je vais tester Easter Monster et je vous tient au courant !

Edit : Resultat : Aucun chiffre trouvé ou simplification ... c'est rare ... Je vais analyser cette grille !

Euh, d'apres un site, la grille donnée plus tot n'est pas Easter Monster :

Code :

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

1
2
3
4
5
6
7
8
9
100000089
000009002
000000450
007600000
030040000
900002005
004070000
500008010
060300000

Voila la "vraie" grille (je ne sais pas laquelle de ces grilles les la vraie, mais la deuxieme est dure aussi)

Je suis sur que vous allez aimer ce lien : http://www.stolaf.edu/people/hansonr...er_monster.htm

[FullSpeed]

En fait il n'ya que sur les vitesses que l'on peut discuter sans reveler nos petits secret
Autrement on aurait des mails genre
Moi j'ai trouve une idée origianele
Tu parles la mienne est mieux
Expliques:
Et tu me voles mon idée!..

Non des bons coup de mégahertz et de multicoeur ca c'est de la conversation, d'homme
Je me faisais une remarque: il y a pas l'air d'y avoir beaucoup de fille...
Boris