Sans surprise, j'ai fait quelque chose de similaire, mais ce sont surtout les pièges qui étaient intéressants à relever.
Première partie
En premier lieu, si on raisonne en termes de tachyons et pas de chemins entiers, il faut résister à l'envie de travailler « en profondeur d'abord ». Il est tentant de dépiler un tachyon d'une pile, d'en ré-empiler deux juste derrière s'il traverse un splitter, et de refaire un tour de boucle tant que la pile n'est pas vide. Seulement, cela nous empêche de détecter la coalescence des tachyons émis simultanément à une même position (par deux splitters distincts distants d'exactement deux positions horizontales).
Ensuite, la question était en fait « combien de fois le rayon a-t-il été divisé ? ». La subtilité était que si un tachyon voyage d'une position à l'autre, le « rayon », lui, est considéré unique du point de départ à celui d'arrivée. Et cela a de l'importance parce si deux tachyons se retrouvant à la même position s'écrasent mutuellement pour n'en former qu'un seul, ils peuvent aussi se suivre et faire en sorte qu'un même splitter soit franchi plusieurs fois.
Par conséquent, puisque seul un splitter peut diviser un rayon, il fallait penser à faire le bilan du nombre de splitters atteints au moins une fois et pas seulement incrémenter un compteur chaque fois que l'on en franchit un.
C'est important parce que j'obtiens respectivement 21 et 22 cas avec les données d'exemple, mais 13245 et 1607 avec les données réelles, ce qui est très différent… le premier nombre dépassant largement celui des splitters en jeu.
Deuxième partie
La tentation était grande d'écrire directement une fonction récursive et de la lancer à partir du point de départ. Bien sûr, comme chaque année, on fait face à une explosion combinatoire et c'est une bonne chose ici (c'est aussi l'un des rares intérêts à utiliser des langages lents).
D'abord, il était tentant également d'écrire quelque chose comme :
if splitter:
return fn((x-1,y)) + fn((x+1,y)
else:
return fn((x,y+1))
… en particulier parce que c'est propre et concis, mais cela encombre quand même la pile sur un trajet en ligne droite pour rien et il ne faut pas attendre ici du langage qu'il détecte et optimise automatiquement la récursivité terminale, donc il était intéressant de mettre une boucle quand même.
Ensuite, la solution consiste surtout à ne pas recalculer plusieurs fois ce qui est déjà long à obtenir, donc à associer à chaque splitter le nombre de chemins qui en dérivent dès qu'on l'obtient et le renvoyer directement si on repasse dessus par la suite.
Ce qui donne de mon côté (en faisant abstraction des inits) :
hit_splitters = {}
# Fonction récursive
def number_of_ways(tachyon):
x,y = tachyon
while True:
tachyon = (x,y)
if not ((0 <= x < width) and (0 <= y)):
return 0
if y >= height:
return 1
c = split_map[y][x]
if c == "^":
if tachyon not in hit_splitters:
hit_splitters[tachyon] = number_of_ways((x-1,y)) \
+ number_of_ways((x+1,y))
return hit_splitters[tachyon]
if c not in ".S":
print("Unknown character:", c)
raise("Unknown character")
y += 1
# Lancement des parcours
total = number_of_ways(point_de_depart)
print("Splitters atteints :", len(hit_splitters))
print(" Total des chemins :", total)
Avec deux petites remarques :
la décomposition « x,y = tachyon » m'a conduit à une petite erreur d'inattention : lors de la rencontre avec un splitter, j'utilise la variable tachyon comme index pour hit_splitters mais à cause de la boucle décrite plus tôt, j'avais oublié qu'elle n'était plus forcément à jour. Donc j'enregistrais les points de départ de chaque tachyon et pas la position des splitters…
J'ai l'habitude d'écrire le total final après toutes les autres sorties mais dans ce cas précis, j'appelais la fonction directement depuis le print. Je ne comprenais donc pas pourquoi le nombre de splitters atteints, donné juste avant, était toujours nul… :-)
Ce sont des broutilles, bien sûr, mais ça montre à quel point une erreur légère peut devenir critique en environnement sensible, aéronautique ou nucléaire par exemple, même lorsque l'on a de la pratique et que l'on porte du soin à son algorithme principal, et pourquoi les méthodes formelles et preuves de programmes sont utiles dans ce type de situation.
C'est une des choses que j'aime le plus dans l'AoC. Même quand les exercices sont « simples », on reçoit régulièrement ce genre de piqûre de rappel alors qu'il est plus difficile d'y être confronté en contexte professionnel.
Même chose : j'avais déjà, il y a très longtemps, écrit une petite lib en contexte professionnel pour gérer des intervalles, donc ça m'a rappelé des souvenirs. Je ne l'ai pas reprise mais par contre, j'ai géré les recouvrements dès la première partie pour produire une liste triée et unifiée.
Pareil ensuite : recherche dichotomique dans la liste pour les ingrédients et quand est arrivée la phase 2, j'avais déjà tout sous la main.
En effet, je pensais à quelque chose de similaire également, mais je me demandais si le coût de construction du graphe ne compensait pas le gain engendré. En réalité non, puisque la seule première passe consiste déjà à faire quasiment tout ce travail puisqu'il faut examiner tous les nœuds et, pour chacun d'eux, l'état des huit voisins…
Ce qui est intéressant, c'est que c'est effectivement linéaire à partir du moment où l'on peut être certain que chaque nœud qui aura transité par la pile n'y aura été inséré puis supprimé qu'une seule fois. Car autrement, cela ressemblait un peu à la suite de Syracuse… :-)
Je profite d'un lever matinal pour m'attacher à la quatrième tâche. :-)
Rien de fondamentalement difficile ici. Ce qui est intéressant, en revanche, c'est la « carte » formée par l'érosion introduite par la seconde phase. https://imgur.com/a/aoc-2025-04-PiWHV2z
Pour le reste, il y aurait probablement de l'optimisation à faire si l'on travaillait sur de très grandes cartes, en circonscrivant des territoires pour éviter de la traiter entièrement à chaque passe, mais rien qui justifie cet investissement en l'état, je pense.
Je propose à mon tour mon approche de la deuxième partie du jour 3.
Même chose : j'évite l'approche récursive en faisant une seule passe sur chaque banc de pile. On a donc une complexité en n×m mais on peut la considérer linéaire si on part du principe que le nombre de piles à combiner est constant (2 dans la première phase, 12 dans la seconde).
Étant donné que d'une part, 20000 sera toujours supérieur à 19999, pour chaque pile dans le banc examiné, on a tout intérêt à remplacer la première pile qu'elle dépasse dans le jeu et invalider les suivantes.
La première ligne « continue » au début de la deuxième boucle sert à gérer la fin du banc de pile : lorsqu'il reste moins de douze piles à examiner dans le banc, on ne peut plus remplacer les premières (parce qu'il n'y en aurait plus assez pour remplir le jeu) mais il en reste suffisamment pour remplacer les dernières.
from functools import reduce
puzzle2_mode = True
row_count = 0
total = 0
battery_num = 12 if puzzle2_mode else 2
with open(input_file_name) as f:
row_count += 1
for l in f:
l = l.strip()
ll = len(l)
cells = [ 0 ] * battery_num
for i,n1 in enumerate(l):
n1 = int(n1)
for j,n2 in enumerate(cells):
if ll - i - battery_num + j < 0: continue
if n2 >= n1: continue
cells = cells[0:j] + [n1]
cells += [ 0 ] * (battery_num - len(cells))
break
jolts = reduce(lambda j,c: j*10+c, cells, 0)
total += jolts
print(l, cells, jolts)
print("Nombre de bancs :", row_count)
print("Total des jolts :", total)
Et effectivement, structurer ses données proprement a été, par les années passées également, un moyen efficace d'éliminer rapidement la plupart des bugs, alors même que l'on pense tous raisonnablement coder à peu près proprement par ailleurs. Ce qui est remarquable ici, c'est de voir avec quel brio les scripts sont conçus pour les révéler. Il s'agit de bien plus que de simples cas d'écoles à la difficulté progressive.
Honnêtement, je ne sais pas s'il a un système pour générer des données, ou s'il a un panel.
Surtout que les deux réponses sont possibles en fonction de l'avancée du jeu. Pour ce premier exercice, il est tout-à-fait possible d'écrire un générateur aléatoire.
Par contre, il semble à peu près certain que chaque jeu de donnée est généré une fois pour toute pour chaque compte. Chaque participant reste donc sur un même jeu, qui lui est propre.
Le jour 1 est facile comme chaque année mais la partie 2 demande un peu de réflexion si on cherche mieux que la solution naïve.
Absolument et comme toujours, il y a même un piège qui n'est pas bien caché mais dans lequel on risque quand même de tomber si l'on va trop vite. Cela ajouté au temps nécessaire pour dégripper un peu les neurones après une période d'interruption.
Même s'il n'est pas très sournois et qu'on le voit venir, on risque de se faire prendre si l'on rédige d'emblée des équations « un peu trop belles »…
Je recommande de temps en temps Learn Git Branching pour ceux qui débutent avec Git ou qui n'ont jamais totalement appréhendé la chose.
Même chose : plusieurs exercices présentés comme des petits jeux, une approche visuelle bien réalisée et une prise par la main qui, après nous faire découvrir une commande et ses formes conventionnelles, nous invite très rapidement à utiliser les raccourcis existants, voire à essayer nos propres stratégies pour voir si l'on peut « battre la machine » aux nombres de commandes saisies, comme au golf.
C'est à cela que je pense aussi, mais en tant qu'identifiant général plus que clé primaire réellement utilisées par une ou plusieurs tables, en fait.
Même en débutant en bases de données (situation dans laquelle on n'accède pas encore, en principe, aux développement des plateformes client), on utilise en général un ID numérique (généralement un nombre entier auto-généré) comme clé primaire et c'est lui que l'on partage au sein de la base. Ne serait-ce que pour pouvoir faire les modifs en question au besoin et également pour éviter que cette clé soit exposée en dehors de la base, à laquelle il est justement censé être propre. Si on ne le fait pas, cela nous oblige à recopier l'adresse entière dans toutes les tables qui l'utilisent comme clé étrangère.
PAR CONTRE, il est fort probable que l'on se serve effectivement de cette adresse pour pouvoir croiser plusieurs bases, en principe indépendantes entre elles. Et parfois, cette indépendance peut justement être imposée par le RGPD lui aussi.
Je te le confirme parce que le fichier ne mesure que 230 octets, c'est-à-dire moins long que le paragraphe que tu es en train de lire. J'ai pensé qu'il s'agissait d'un fichier tronqué (donc corrompu), mais la commande file indique « PNG image data, 32 x 32, 8-bit/color RGBA, non-interlaced ».
Ton lien retourne en fait cette image :
Donc soit c'est un contenu générique pour un lien brisé, soit ton interlocuteur a réussi à te transmettre l'icône du document à la place du document lui-même sans s'en rendre compte.
Merci infiniment pour ce travail de recherche et pour le partage. Étant exactement de la même époque, je n'aurais pas espéré retrouver moi-même ces documents d'époque.
Alors, j'ai fini par m'y remettre APRÈS les fêtes, car il me manque actuellement les deux parties du 21 (le numpad) et les secondes parties des 22 et 23. Et alors autant, chaque année, les premiers exercices de l'AoC apparaissent « bugués » jusqu'à ce qu'on lise les petites lignes et que l'on saisisse la subtilité, autant je sèche un peu sur la deuxième partie de celui-ci.
J'ai également constaté que le degré de chaque machine était exactement 13 partout. On ne peut pas rechercher un graphe K14 car il serait isolé du reste du réseau (mais pourquoi pas, après tout).
Un peu fatigué à ce stade, j'ai choisi de faire une exploration en n*(n-1)/2 pour comparer toutes les paires possibles et déterminer le nombre maximum de nœuds en commun pour chaque partie, puis voir si l'on peut retrouver une clique de cette taille, quitte à redescendre dans la négative. Et je suis également arrivé à 11 voisins.
En sélectionnant toutes les machines qui ont exactement onze voisins, et en triant ceux-ci dans chaque liste, j'obtiens ceci :
La diagonale correspond à la « connexion de loopback » (avec soi-même) qui bien sûr n'existe pas, et la colonne de droite est le nœud qui comble le trou en temps normal, qui permet de maintenir treize voisins et accessoirement maintient la connectivité avec le reste du réseau.
J'ai soumis « bk,du,dv,gm,hc,ny,ot,um,xl,ze,zy » (onze nœuds, donc) mais ce n'est pas la bonne réponse…
On remarque que les listes ci-dessus contiennent en fait onze nœuds et pas treize. En effet, la liste complète est en réalité
On remarque que les colonnes of et uy sont partagées par presque tous les nœuds sauf deux (matérialisés par les trous hors diagonale). Ces deux trous correspond précisément à un seul lien manquant entre ces deux machines, ce qui suffit à briser la clique.
J'ai malgré tout ajouté ces deux machines à la liste ci-dessus (en préservant l'ordre alphabétique), mais ce n'est pas la bonne réponse non plus.
À ce stade, je veux bien un indice si quelqu'un voit la faille.
Posté par Obsidian .
En réponse au journal Advent of code 2024.
Évalué à 3.
Dernière modification le 22 décembre 2024 à 18:13.
Après avoir naïvement tenté une approche récursive, qui donne malgré tout de bons résultats pour la première partie (durant laquelle il s'agit juste de savoir si un motif peut être composé ou non, donc où il suffit de s'arrêter à la première solution, qui arrive assez vite), j'ai fini par faire exactement la même chose :
Je viens de finir le 14ème jour à mon tour et en effet, le plus difficile dans la deuxième partie était de savoir ce que l'on cherche. Oui, certes, il y a bien une description claire de ce que c'est censé représenter, mais rien qui concerne la façon dont c'est construit dans les faits.
Ce qui était intéressant ici, c'est qu'en examinant les dimensions de la grille, on pouvait en déduire relativement facilement, de proche en proche, que tous les robots reviennent tous à leur position initiale en « largeur × hauteur » secondes, ni plus ni moins.
Ça permet de savoir qu'il y a 10403 images à examiner, ce qui est envisageable mais reste très long si on les fait défiler dans un fichier texte, par exemple. À raison d'une dizaine d'images par seconde, il y en aurait pour vingt bonnes minutes à condition de ne pas la rater quand elle passe…
On ne savait pas non plus si la figure était évidée ou pleine. Dans le second cas, il suffit de chercher une séquence de robots consécutifs suffisamment longue. Six à huit robots consécutifs dépassent largement ce que le hasard peut produire et si cette séquence existe, l'éditeur la trouvera forcément. C'est assurément cette voie qu'il faut suivre, à mon avis.
Malheureusement, pour une raison qui m'échappe un peu, et probablement en considérant le nombre limité de robots par rapport à la taille de la grille, j'ai estimé que la figure devait être constituée de segments non verticaux ni horizontaux et je suis parti directement sur l'examen des images. J'ai fini par générer un gros img.raw à peu près carré, l'ouvrir avec GIMP et chercher l'image dedans.
J'ai cherché le premier moment où toutes les positions de robots étaient distinctes.
C'était une bonne idée, même si elle n'était pas garantie car l'image n'utilise pas la totalité des robots sur la carte. Mais si on considère que les données initiales sont obtenus en partant du résultat, ça fait sens.
Rétrospectivement, on voit aussi que la fameuse colonne médiane peut apporter beaucoup d'infos également… :-)
Je suis arrivé à peu près aux mêmes conclusions, avec comme toujours de légères variantes dans l'approche.
Pour la première partie, étant donné que chaque signe était soit « + », soit « × », on pouvait utiliser du binaire pour les marquer et j'ai donc utilisé une boucle qui comptait de 0 à 1 << n pour obtenir les combinaisons, et on obtenait donc directement une fonction itérative plutôt que récursive.
En outre, en comptant de deux en deux, on peut forcer le bit0 à être toujours nul et donc à imposer un « + » sur le premier nombre, ce qui permet de l'ajouter directement à un accumulateur vide plutôt que faire une exception rien que pour lui.
Pour la deuxième partie, j'ai effectivement réécrit une fonction récursive mais là encore, étant donné que l'on traite des entiers strictement positifs, le cumul ne peut être que croissant étant donné les opérations à utiliser (ici +, - et ||). Donc, j'ai effectivement passé la cible à la fonction récursive parallèlement aux autres arguments et interrompu la procédure chaque fois qu'une « branche » dépassait la cible. C'est la même chose mais dans l'autre sens.
Cela me donne 240 microsecondes au lieu de 15 millisecondes avec une approche brute-force.
Tu as oublié de remettre les arguments à l'endroit en sortie… :-)
Dans la fenêtre du terminal, il y a juste à faire Ctrl + N ou alors cliquer sur "terminal" dans la barre de titre et sélectionner nouvelle fenêtre.
Si c'était le seul moyen de le faire, ça resterait un problème car ça aurait délégué la tâche au terminal lui-même et qu'il faudrait faire de même pour toutes les applications.
Heureusement, on peut aussi faire Ctrl+Clic pour forcer un nouvel appel à une application déjà lancée. C'est pratique avec d'autres applications comme les navigateurs web, entre autres.
D'une manière générale, il est toujours plus facile d'aborder les langages « au moment où ils apparaissent » pour des raisons relativement évidentes : on a d'abord le temps de s'habituer à un langage avant de passer au suivant et parce que le « langage suivant » en question est généralement produit pour aborder tout ce qu'il manquait dans le précédent ou y était mal conçu, ce qui rend alors les nouveautés beaucoup plus faciles à assimiler. En conséquence, faire le chemin inverse est toujours plus difficile.
Par contre, effectivement, il faut se méfier avec le C++ parce que l'on pense souvent le maîtriser, même en toute bonne foi, alors que c'est souvent loin d'être le cas.
On pourrait dire la même chose de tous les langages, bien sûr, mais celui-ci est non seulement beaucoup plus vaste qu'on l'imagine, mais on peut raisonnablement penser qu'on en maîtrise déjà la plupart si on maîtrise le C. Par ailleurs, si on l'a appris dans les années 1980, 1990 ou 2000, alors on n'imagine pas non plus ce qu'a été la révision C++11 en particulier, surtout comparée aux suivantes qui ressemblent plus à des mises à niveau plus ordinaires. Certains disent que c'est quasiment un nouveau langage. Ce n'est pas les mots que j'aurais choisis. Je dirais plutôt qu'il a été enrichi de pas loin de 50 % (à la louche) de son volume précédent.
Beaucoup de développeurs C++, lorsqu'on leur demandent conseil, prescrivent d'emblée « rien en dessous de C++11 » et je pense que c'est sage. En général, aujourd'hui, je pose moi-même mes prérequis à C++11 par défaut (donc pas moins) et je ne monte au dessus que lorsque c'est nécessaire ou que j'ai vraiment envie de pratiquer les nouveautés suivantes.
[^] # Re: Jour 7
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Sans surprise, j'ai fait quelque chose de similaire, mais ce sont surtout les pièges qui étaient intéressants à relever.
Première partie
En premier lieu, si on raisonne en termes de tachyons et pas de chemins entiers, il faut résister à l'envie de travailler « en profondeur d'abord ». Il est tentant de dépiler un tachyon d'une pile, d'en ré-empiler deux juste derrière s'il traverse un splitter, et de refaire un tour de boucle tant que la pile n'est pas vide. Seulement, cela nous empêche de détecter la coalescence des tachyons émis simultanément à une même position (par deux splitters distincts distants d'exactement deux positions horizontales).
Ensuite, la question était en fait « combien de fois le rayon a-t-il été divisé ? ». La subtilité était que si un tachyon voyage d'une position à l'autre, le « rayon », lui, est considéré unique du point de départ à celui d'arrivée. Et cela a de l'importance parce si deux tachyons se retrouvant à la même position s'écrasent mutuellement pour n'en former qu'un seul, ils peuvent aussi se suivre et faire en sorte qu'un même splitter soit franchi plusieurs fois.
Par conséquent, puisque seul un splitter peut diviser un rayon, il fallait penser à faire le bilan du nombre de splitters atteints au moins une fois et pas seulement incrémenter un compteur chaque fois que l'on en franchit un.
C'est important parce que j'obtiens respectivement 21 et 22 cas avec les données d'exemple, mais 13245 et 1607 avec les données réelles, ce qui est très différent… le premier nombre dépassant largement celui des splitters en jeu.
Deuxième partie
La tentation était grande d'écrire directement une fonction récursive et de la lancer à partir du point de départ. Bien sûr, comme chaque année, on fait face à une explosion combinatoire et c'est une bonne chose ici (c'est aussi l'un des rares intérêts à utiliser des langages lents).
D'abord, il était tentant également d'écrire quelque chose comme :
if splitter:
return fn((x-1,y)) + fn((x+1,y)
else:
return fn((x,y+1))
… en particulier parce que c'est propre et concis, mais cela encombre quand même la pile sur un trajet en ligne droite pour rien et il ne faut pas attendre ici du langage qu'il détecte et optimise automatiquement la récursivité terminale, donc il était intéressant de mettre une boucle quand même.
Ensuite, la solution consiste surtout à ne pas recalculer plusieurs fois ce qui est déjà long à obtenir, donc à associer à chaque splitter le nombre de chemins qui en dérivent dès qu'on l'obtient et le renvoyer directement si on repasse dessus par la suite.
Ce qui donne de mon côté (en faisant abstraction des inits) :
Avec deux petites remarques :
x,y = tachyon» m'a conduit à une petite erreur d'inattention : lors de la rencontre avec un splitter, j'utilise la variable tachyon comme index pour hit_splitters mais à cause de la boucle décrite plus tôt, j'avais oublié qu'elle n'était plus forcément à jour. Donc j'enregistrais les points de départ de chaque tachyon et pas la position des splitters…Ce sont des broutilles, bien sûr, mais ça montre à quel point une erreur légère peut devenir critique en environnement sensible, aéronautique ou nucléaire par exemple, même lorsque l'on a de la pratique et que l'on porte du soin à son algorithme principal, et pourquoi les méthodes formelles et preuves de programmes sont utiles dans ce type de situation.
C'est une des choses que j'aime le plus dans l'AoC. Même quand les exercices sont « simples », on reçoit régulièrement ce genre de piqûre de rappel alors qu'il est plus difficile d'y être confronté en contexte professionnel.
[^] # Re: jour 5
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Ce qui prouve encore une fois qu'en Python, il y a toujours moyen de faire plus concis que ce que l'on a réussi à faire jusque là :-)
[^] # Re: jour 5
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Même chose : j'avais déjà, il y a très longtemps, écrit une petite lib en contexte professionnel pour gérer des intervalles, donc ça m'a rappelé des souvenirs. Je ne l'ai pas reprise mais par contre, j'ai géré les recouvrements dès la première partie pour produire une liste triée et unifiée.
Pareil ensuite : recherche dichotomique dans la liste pour les ingrédients et quand est arrivée la phase 2, j'avais déjà tout sous la main.
[^] # Re: Jour 4
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
En effet, je pensais à quelque chose de similaire également, mais je me demandais si le coût de construction du graphe ne compensait pas le gain engendré. En réalité non, puisque la seule première passe consiste déjà à faire quasiment tout ce travail puisqu'il faut examiner tous les nœuds et, pour chacun d'eux, l'état des huit voisins…
Ce qui est intéressant, c'est que c'est effectivement linéaire à partir du moment où l'on peut être certain que chaque nœud qui aura transité par la pile n'y aura été inséré puis supprimé qu'une seule fois. Car autrement, cela ressemblait un peu à la suite de Syracuse… :-)
# Jour 4
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Je profite d'un lever matinal pour m'attacher à la quatrième tâche. :-)
Rien de fondamentalement difficile ici. Ce qui est intéressant, en revanche, c'est la « carte » formée par l'érosion introduite par la seconde phase.
https://imgur.com/a/aoc-2025-04-PiWHV2z
Pour le reste, il y aurait probablement de l'optimisation à faire si l'on travaillait sur de très grandes cartes, en circonscrivant des territoires pour éviter de la traiter entièrement à chaque passe, mais rien qui justifie cet investissement en l'état, je pense.
[^] # Re: Jour 3
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Je propose à mon tour mon approche de la deuxième partie du jour 3.
Même chose : j'évite l'approche récursive en faisant une seule passe sur chaque banc de pile. On a donc une complexité en n×m mais on peut la considérer linéaire si on part du principe que le nombre de piles à combiner est constant (2 dans la première phase, 12 dans la seconde).
Étant donné que d'une part, 20000 sera toujours supérieur à 19999, pour chaque pile dans le banc examiné, on a tout intérêt à remplacer la première pile qu'elle dépasse dans le jeu et invalider les suivantes.
La première ligne « continue » au début de la deuxième boucle sert à gérer la fin du banc de pile : lorsqu'il reste moins de douze piles à examiner dans le banc, on ne peut plus remplacer les premières (parce qu'il n'y en aurait plus assez pour remplir le jeu) mais il en reste suffisamment pour remplacer les dernières.
[^] # Re: Jour 1
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Ça me rassure de ne pas être tout seul. :-)
Et effectivement, structurer ses données proprement a été, par les années passées également, un moyen efficace d'éliminer rapidement la plupart des bugs, alors même que l'on pense tous raisonnablement coder à peu près proprement par ailleurs. Ce qui est remarquable ici, c'est de voir avec quel brio les scripts sont conçus pour les révéler. Il s'agit de bien plus que de simples cas d'écoles à la difficulté progressive.
[^] # Re: Jour 1
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Surtout que les deux réponses sont possibles en fonction de l'avancée du jeu. Pour ce premier exercice, il est tout-à-fait possible d'écrire un générateur aléatoire.
Par contre, il semble à peu près certain que chaque jeu de donnée est généré une fois pour toute pour chaque compte. Chaque participant reste donc sur un même jeu, qui lui est propre.
[^] # Re: Jour 1
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
_o/
Absolument et comme toujours, il y a même un piège qui n'est pas bien caché mais dans lequel on risque quand même de tomber si l'on va trop vite. Cela ajouté au temps nécessaire pour dégripper un peu les neurones après une période d'interruption.
Même s'il n'est pas très sournois et qu'on le voit venir, on risque de se faire prendre si l'on rédige d'emblée des équations « un peu trop belles »…
[^] # Re: Décroissance vaincra !
Posté par Obsidian . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Il s'agit donc d'une vérification récursive. :-)
# Learn Git Branching
Posté par Obsidian . En réponse au journal new skills linux. Évalué à 8.
Je recommande de temps en temps Learn Git Branching pour ceux qui débutent avec Git ou qui n'ont jamais totalement appréhendé la chose.
Même chose : plusieurs exercices présentés comme des petits jeux, une approche visuelle bien réalisée et une prise par la main qui, après nous faire découvrir une commande et ses formes conventionnelles, nous invite très rapidement à utiliser les raccourcis existants, voire à essayer nos propres stratégies pour voir si l'on peut « battre la machine » aux nombres de commandes saisies, comme au golf.
[^] # Re: rectificatif : on peut maintenant changer d'e-mail chez Leroy Merlin
Posté par Obsidian . En réponse au journal changement d'adresse e-mail : des vertes et des pas mures. Évalué à 10.
C'est l'effet LinuxFr… ;-)
[^] # Re: Identifiant
Posté par Obsidian . En réponse au journal changement d'adresse e-mail : des vertes et des pas mures. Évalué à 8.
C'est à cela que je pense aussi, mais en tant qu'identifiant général plus que clé primaire réellement utilisées par une ou plusieurs tables, en fait.
Même en débutant en bases de données (situation dans laquelle on n'accède pas encore, en principe, aux développement des plateformes client), on utilise en général un ID numérique (généralement un nombre entier auto-généré) comme clé primaire et c'est lui que l'on partage au sein de la base. Ne serait-ce que pour pouvoir faire les modifs en question au besoin et également pour éviter que cette clé soit exposée en dehors de la base, à laquelle il est justement censé être propre. Si on ne le fait pas, cela nous oblige à recopier l'adresse entière dans toutes les tables qui l'utilisent comme clé étrangère.
PAR CONTRE, il est fort probable que l'on se serve effectivement de cette adresse pour pouvoir croiser plusieurs bases, en principe indépendantes entre elles. Et parfois, cette indépendance peut justement être imposée par le RGPD lui aussi.
[^] # Re: ni iso ni pdf
Posté par Obsidian . En réponse au message Demande de service de récupération d'iso. Évalué à 6.
Je te le confirme parce que le fichier ne mesure que 230 octets, c'est-à-dire moins long que le paragraphe que tu es en train de lire. J'ai pensé qu'il s'agissait d'un fichier tronqué (donc corrompu), mais la commande
fileindique « PNG image data, 32 x 32, 8-bit/color RGBA, non-interlaced ».Ton lien retourne en fait cette image :
Donc soit c'est un contenu générique pour un lien brisé, soit ton interlocuteur a réussi à te transmettre l'icône du document à la place du document lui-même sans s'en rendre compte.
# Une petite mine d'or…
Posté par Obsidian . En réponse au journal La thèse de Jean Gastinel: conception et intégration d'un terminal alphanumérique (1977). Évalué à 7.
Merci infiniment pour ce travail de recherche et pour le partage. Étant exactement de la même époque, je n'aurais pas espéré retrouver moi-même ces documents d'époque.
Je m'empresse de la lire.
# π
Posté par Obsidian . En réponse au lien Pétition pour surnommer Pithon la version 3.14 de Python. Évalué à 10.
Une pithition, alors…
[^] # Re: oublie ton prompt...
Posté par Obsidian . En réponse au journal [HS] Le "cloud interne", c'est quoi donc ?. Évalué à 3.
'faut juste éviter de passer au dessus du Darfour…
[^] # Re: jour 23 - cracra
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 2.
Alors, j'ai fini par m'y remettre APRÈS les fêtes, car il me manque actuellement les deux parties du 21 (le numpad) et les secondes parties des 22 et 23. Et alors autant, chaque année, les premiers exercices de l'AoC apparaissent « bugués » jusqu'à ce qu'on lise les petites lignes et que l'on saisisse la subtilité, autant je sèche un peu sur la deuxième partie de celui-ci.
J'ai également constaté que le degré de chaque machine était exactement 13 partout. On ne peut pas rechercher un graphe K14 car il serait isolé du reste du réseau (mais pourquoi pas, après tout).
Un peu fatigué à ce stade, j'ai choisi de faire une exploration en n*(n-1)/2 pour comparer toutes les paires possibles et déterminer le nombre maximum de nœuds en commun pour chaque partie, puis voir si l'on peut retrouver une clique de cette taille, quitte à redescendre dans la négative. Et je suis également arrivé à 11 voisins.
En sélectionnant toutes les machines qui ont exactement onze voisins, et en triant ceux-ci dans chaque liste, j'obtiens ceci :
La diagonale correspond à la « connexion de loopback » (avec soi-même) qui bien sûr n'existe pas, et la colonne de droite est le nœud qui comble le trou en temps normal, qui permet de maintenir treize voisins et accessoirement maintient la connectivité avec le reste du réseau.
J'ai soumis « bk,du,dv,gm,hc,ny,ot,um,xl,ze,zy » (onze nœuds, donc) mais ce n'est pas la bonne réponse…
On remarque que les listes ci-dessus contiennent en fait onze nœuds et pas treize. En effet, la liste complète est en réalité
On remarque que les colonnes of et uy sont partagées par presque tous les nœuds sauf deux (matérialisés par les trous hors diagonale). Ces deux trous correspond précisément à un seul lien manquant entre ces deux machines, ce qui suffit à briser la clique.
J'ai malgré tout ajouté ces deux machines à la liste ci-dessus (en préservant l'ordre alphabétique), mais ce n'est pas la bonne réponse non plus.
À ce stade, je veux bien un indice si quelqu'un voit la faille.
[^] # Re: jour 19 - on souffle
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 3. Dernière modification le 22 décembre 2024 à 18:13.
Après avoir naïvement tenté une approche récursive, qui donne malgré tout de bons résultats pour la première partie (durant laquelle il s'agit juste de savoir si un motif peut être composé ou non, donc où il suffit de s'arrêter à la première solution, qui arrive assez vite), j'ai fini par faire exactement la même chose :
En Python sur une machine de 2008, j'obtiens 0m0,182s avec l'affichage des résultats dans un terminal Gnome.
[^] # Re: 14ème jour
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 4.
Je viens de finir le 14ème jour à mon tour et en effet, le plus difficile dans la deuxième partie était de savoir ce que l'on cherche. Oui, certes, il y a bien une description claire de ce que c'est censé représenter, mais rien qui concerne la façon dont c'est construit dans les faits.
Ce qui était intéressant ici, c'est qu'en examinant les dimensions de la grille, on pouvait en déduire relativement facilement, de proche en proche, que tous les robots reviennent tous à leur position initiale en « largeur × hauteur » secondes, ni plus ni moins.
Ça permet de savoir qu'il y a 10403 images à examiner, ce qui est envisageable mais reste très long si on les fait défiler dans un fichier texte, par exemple. À raison d'une dizaine d'images par seconde, il y en aurait pour vingt bonnes minutes à condition de ne pas la rater quand elle passe…
On ne savait pas non plus si la figure était évidée ou pleine. Dans le second cas, il suffit de chercher une séquence de robots consécutifs suffisamment longue. Six à huit robots consécutifs dépassent largement ce que le hasard peut produire et si cette séquence existe, l'éditeur la trouvera forcément. C'est assurément cette voie qu'il faut suivre, à mon avis.
Malheureusement, pour une raison qui m'échappe un peu, et probablement en considérant le nombre limité de robots par rapport à la taille de la grille, j'ai estimé que la figure devait être constituée de segments non verticaux ni horizontaux et je suis parti directement sur l'examen des images. J'ai fini par générer un gros
img.rawà peu près carré, l'ouvrir avec GIMP et chercher l'image dedans.C'était une bonne idée, même si elle n'était pas garantie car l'image n'utilise pas la totalité des robots sur la carte. Mais si on considère que les données initiales sont obtenus en partant du résultat, ça fait sens.
Rétrospectivement, on voit aussi que la fameuse colonne médiane peut apporter beaucoup d'infos également… :-)
[^] # Re: 7ème jour, un peu de répit
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 2.
Je suis arrivé à peu près aux mêmes conclusions, avec comme toujours de légères variantes dans l'approche.
Pour la première partie, étant donné que chaque signe était soit « + », soit « × », on pouvait utiliser du binaire pour les marquer et j'ai donc utilisé une boucle qui comptait de
0à1 << npour obtenir les combinaisons, et on obtenait donc directement une fonction itérative plutôt que récursive.En outre, en comptant de deux en deux, on peut forcer le bit0 à être toujours nul et donc à imposer un « + » sur le premier nombre, ce qui permet de l'ajouter directement à un accumulateur vide plutôt que faire une exception rien que pour lui.
Pour la deuxième partie, j'ai effectivement réécrit une fonction récursive mais là encore, étant donné que l'on traite des entiers strictement positifs, le cumul ne peut être que croissant étant donné les opérations à utiliser (ici
+,-et||). Donc, j'ai effectivement passé la cible à la fonction récursive parallèlement aux autres arguments et interrompu la procédure chaque fois qu'une « branche » dépassait la cible. C'est la même chose mais dans l'autre sens.Tu as oublié de remettre les arguments à l'endroit en sortie… :-)
[^] # Re: Ctrl + N
Posté par Obsidian . En réponse au message Pourquoi GNOME est devenu un logiciel privateur de liberté ?. Évalué à 3.
Si c'était le seul moyen de le faire, ça resterait un problème car ça aurait délégué la tâche au terminal lui-même et qu'il faudrait faire de même pour toutes les applications.
Heureusement, on peut aussi faire Ctrl+Clic pour forcer un nouvel appel à une application déjà lancée. C'est pratique avec d'autres applications comme les navigateurs web, entre autres.
[^] # Re: Apprend les deux ! Et commence par le C !
Posté par Obsidian . En réponse au message technos cloud, rust.. Quid d'apprendre le C aujourd'hui?. Évalué à 3. Dernière modification le 04 août 2024 à 16:29.
D'une manière générale, il est toujours plus facile d'aborder les langages « au moment où ils apparaissent » pour des raisons relativement évidentes : on a d'abord le temps de s'habituer à un langage avant de passer au suivant et parce que le « langage suivant » en question est généralement produit pour aborder tout ce qu'il manquait dans le précédent ou y était mal conçu, ce qui rend alors les nouveautés beaucoup plus faciles à assimiler. En conséquence, faire le chemin inverse est toujours plus difficile.
Par contre, effectivement, il faut se méfier avec le C++ parce que l'on pense souvent le maîtriser, même en toute bonne foi, alors que c'est souvent loin d'être le cas.
On pourrait dire la même chose de tous les langages, bien sûr, mais celui-ci est non seulement beaucoup plus vaste qu'on l'imagine, mais on peut raisonnablement penser qu'on en maîtrise déjà la plupart si on maîtrise le C. Par ailleurs, si on l'a appris dans les années 1980, 1990 ou 2000, alors on n'imagine pas non plus ce qu'a été la révision C++11 en particulier, surtout comparée aux suivantes qui ressemblent plus à des mises à niveau plus ordinaires. Certains disent que c'est quasiment un nouveau langage. Ce n'est pas les mots que j'aurais choisis. Je dirais plutôt qu'il a été enrichi de pas loin de 50 % (à la louche) de son volume précédent.
Beaucoup de développeurs C++, lorsqu'on leur demandent conseil, prescrivent d'emblée « rien en dessous de C++11 » et je pense que c'est sage. En général, aujourd'hui, je pose moi-même mes prérequis à C++11 par défaut (donc pas moins) et je ne monte au dessus que lorsque c'est nécessaire ou que j'ai vraiment envie de pratiquer les nouveautés suivantes.
[^] # Re: Réalité virtuelle
Posté par Obsidian . En réponse à la dépêche Les prochaines fonctionnalités de Firefox dévoilées. Évalué à 1.
Je suis surpris que l'Hybridpunk n'existe pas encore…
[^] # Re: Réalité virtuelle
Posté par Obsidian . En réponse à la dépêche Les prochaines fonctionnalités de Firefox dévoilées. Évalué à 4.
… est en première base ?