Jour 5 (résumé)
Partie 1
Apparemment, il n'y a plus de sable pour filtrer l'eau de la source, donc la source a été coupée. Le lutin responsable était trop concentré sur ses plantations pour remarquer que le sable mettait longtemps à arriver.
Il a des problĂšmes dans ses plantations, et vous demande de l'aide. Il dispose d'un Almanach comme celui-ci :
seeds: 79 14 55 13
seed-to-soil map:
50 98 2
52 50 48
soil-to-fertilizer map:
0 15 37
37 52 2
39 0 15
fertilizer-to-water map:
49 53 8
0 11 42
42 0 7
57 7 4
water-to-light map:
88 18 7
18 25 70
light-to-temperature map:
45 77 23
81 45 19
68 64 13
temperature-to-humidity map:
0 69 1
1 0 69
humidity-to-location map:
60 56 37
56 93 4
Le principe est que sur la premiÚre ligne, on a les numéros des graines.
Sur chaque autre ligne, des groupes de 3 chiffres : le premier numéros de l'intervalle de numéros transformé de la graine qui possÚde un numéros compris dans l'intervalle dont le premier nombre est le deuxiÚme donnée, et la longueur de l'intervalle.
L'idée est d'appliquer la transformation à chaque fois aux numéros des graines pour pouvoir obtenir à la fin le numéros de la plus petite graine (transformé 7 fois).
LâĂ©noncĂ© est assez complexe et complet, je vous invite Ă aller le consulter directement.
Partie 2
Comme vous auriez put y arriver sans brûler votre RAM/CPU, on ajoute un petit détail : les numéros de graines vont par paires et forment un intervalle qui commence au premier nombre et finis le deuxiÚme nombre plus loin.
# Python sans brûlage de CPU ni explosion de RAM
Posté par alberic89 đ§ . Ăvalué à  1. DerniĂšre modification le 05 dĂ©cembre 2023 Ă 16:01.
Une solution dont je ne suis pas peux fier, puisquâelle est Ă©conome en ressource et prend moins d'une seconde Ă terminer. Et j'ai enfin commencĂ© Ă utiliser la POO :
L'informatique n'est pas une science exacte, on n'est jamais Ă l'abri d'un succĂšs
[^] # Re: Python sans brûlage de CPU ni explosion de RAM
Posté par alberic89 đ§ . Ăvalué à  1.
Au début, je m'étais dit naïvement :
AprĂšs m'ĂȘtre fait rappeler Ă l'ordre par mon OOM Killer, j'ai mis en place une solution plus simple qui applique directement les modifications aux numĂ©ros de graine et se souvenant s'il a dĂ©jĂ modifiĂ© cette valeur (pour Ă©viter de changer 3 fois par Ă©tape les numĂ©ros).
La partie 2 m'a donnée beaucoup plus de fil à retordre, car ce n'est pas simplement :
Mais l'OOM Killer proteste encore une fois, m'obligeant à finalement essayer de gérer des intervalles plutÎt que des valeurs. AprÚs beaucoup de débuggage et d'arrachage de cheveux, j'ai fini par trouver la recette qui s'exécute instantanément.
L'informatique n'est pas une science exacte, on n'est jamais Ă l'abri d'un succĂšs
# Le code que j'aurais aimé faire du premier coup.
Posté par Yth (Mastodon) . Ăvalué à  2.
Mon premier algo a fait fondre deux CPU en mĂȘme temps, sur deux machines diffĂ©rentes, avec partage du travail Ă faire, pour pondre le rĂ©sultat en pas loin de 40 minutes, avec PyPy.
Voici le second, celui qui fonctionne, qui prends moins d'un dixiÚme de seconde pour résoudre tout le problÚme, et de façon assez élégante en plus, juste en exploitant le
range()
de Python.C'est pour ça que dans l'algo prĂ©sentĂ©, j'utilise la mĂȘme mĂ©thode pour les deux exercices, avec des range de un Ă©lĂ©ment pour l'exercice 1, je n'ai pas codĂ© ça dĂšs le dĂ©but.
Et non, je ne posterai pas mon premier algo, trĂšs bien pour l'exo 1, mais trĂšs crado pour le 2 ^
Les données d'abord, je distingue les graines et le reste :
Les graines sont donc une liste de range().
Ensuite les transformations pour trouver les correspondances, on va avoir une classe avec deux listes : les range() source, et les opérations à appliquer sur chaque range, qui sont simplement un entier relatif à ajouter. Et puis les noms des éléments depuis et vers lesquels on transforme :
Pour les calculs en eux-mĂȘme, la mĂ©thode qui fait le travail est ajoutĂ©e Ă Map(), et la rĂ©solution est assez simple au bout du compte.
On calcule tout simplement les superpositions de deux range() : on va avoir un range d'éléments non traité avant un range de transformation, un range d'éléments non traités aprÚs un range de transformation, et enfin un range transformé. On boucle sur toutes les opérations disponibles, en remettant dans le pot les range non traités (avant et aprÚs) et en retournant (yield est ton ami) les range traités.
On n'oublie pas à la fin de retourner tous les range ayant échappés aux transformations, car ils restent identiques selon l'énoncé.
Le code est vraiment simple grùce aux itérateurs, avec yield, on ne se fatigue pas à construire une liste, à tester des trucs : on a une donnée finale ? yield, et on continue, elle est envoyée, et on ne s'en occupe plus.
Et on utilise les propriétés des
range()
, au début je voulais faire desif élément in range_operation
qui est immédiat, mais en fait on n'en a pas besoin. La seule subtilité c'est qu'un range est Vrai s'il contient en pratique des éléments, et Faux sinon, donc range(20, 10) c'est faux.if before
signifie donc simplement : si on a des éléments non traités avant.Enfin le résolution se fait à l'identique pour les deux parties, avec la bonne valeur initiale pour
values
:Pour info, faire les 7 moulinettes sur une liste de 850 millions d'Ă©lĂ©ments, mĂȘme avec PyPy, ça prend dans les dix/quinze minutes, et je parle pas de la RAM.
Comme quoi ça peut valoir le coup de regarder les donnĂ©es Ă traiter pour savoir oĂč on va se planter, avant de coderâŠ
Cela dit, un algo non optimisĂ©, mĂȘme Ă 45 minutes de calcul rĂ©parti sur deux machines (j'aurais pu aller plus vite en parallĂ©lĂ©lisant sur les multiples proc des machines, un range initial par exĂ©cution, en moins de 15 minutes c'Ă©tait pliĂ©), c'est plus rapide que de rĂ©inventer un algorithme, le coder, le valider.
Suivre le flux des commentaires
Note : les commentaires appartiennent Ă celles et ceux qui les ont postĂ©s. Nous nâen sommes pas responsables.