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.