Nan, je comptais partir seulement de 1, 2 OU 3Gamall wrote:Ben oui, mais tu obtiendras toujours un composé de plusieurs atomes, et il faudra bien que tu les sépares... donc il nous faut....
comme mon prog actuel.Remarque mon prog actuel pourrait accepter en entrée n'importe quelle suite de 1, 2 et 3 (enfin tant qu'il y en a pas 4 pareils d'affilés sinon ça foirera genre 3111 au lieu de 41) de maximum 16 caractères avec une modif mineure. C'est à cause de mon stockage sur 2 bits : en fait j'ai 1 seul int pour une ligne, donc max 16 chiffres par ligne. Et je suis incapable de stocker autre chose que des 1, des 2 et des 3 (et des 0 mais là ça veut dire qu'il n'y a pas de chiffre
)(NB: cette remarque avait aussi pour but de te donner des indices concernant mon algo
)Héhé je suis le meilleur, je résouds des problèmes avant même qu'ils ne se posentGamall wrote:Ben en fait, cet épineux problème, je pense que tu as commencé à le résoudre hier
Bon sinon OK pour le reste, mais à mon avis pour une solution jolie, le mieux serait de se trouver le code Maple du type qui a démontré le théorème : il me semble qu'il fait ça (déterminer les atomes automatiquement).
Bah c'est pour toi alorsGamall wrote:la def, c'est une def de matheux, pas une def d'informaticien
Pour ma part je pense que je m'amuserai, une fois fait le prog "atomique" à ma façon, à lui adjoindre une sortie compressée avec un codage de Huffman bien adapté, histoire de perdre moins de temps en accès disque. Et puis un décodeur qui permettra de retrouver la suite de chiffres à partir du fichier compressé... Merci pour l'idée de la compression
Kaf'
(Pour le dico, je partirai de 3)
