À noter que cell·eux qui prennent leur retraite le plus tard sont les politicien·nes et les hommes/femmes d'affaire. Car 1/ leur métier n'est pas pénible 2/ leur métier leur confère un statut social 3/ leur métier leur payent la plupart de leurs frais qu'ils·elles devraient payer de leur poche une fois à la retraite 4/ ça leur permet de prétendre montrer l'exemple, valeur travail, blabla.
Posté par steph1978 .
En réponse au journal Advent of Code 2025.
Évalué à 2 (+0/-0).
Dernière modification le 11 décembre 2025 à 16:16.
Bonne tranche de rigolade aujourd'hui. On est sur du parcours de graphes.
Première partie implémentée en deux minutes, sans erreurs, directement sur l'input et hop une étoile. On commence à être rôdé.
Partie deux, sur ce bon élan, j'adapte ma solution pour partir d'un autre nœud et ne compter que les chemins qui contiennent les nœuds imposés. Trivial. Je vais faire la journée 11 en moins de dix minutes.
Sauf que le script ne me rend pas la main. Et là, je me dis que je me suis fait avoir.
Je trace le graphe avec Graphviz et je vois l'étendue des dégâts. Le nœud de départ de la première partie est tout près du nœud de sortie. Mais pour la seconde partie, il est très très loin. Donc la combinatoire explose.
Je tente une mise en cache, mais ça ne semble rien améliorer.
J'ai donc exploité la structure du graphe proposé qui 1/ est acyclique, 2/ présente des "couches". J'ai donc calculé un graph plus simple avec seulement les nœuds qui matérialisent les couches et le cout pour passer de l'un à l'autre. Puis lancé le calcul du nombre de chemins sur ce graphe plus simple (18 nœuds versus 644).
Forcément, ça m'a pris une bonne paire d'heures.
Je ne sais pas s'il y avait plus malin à faire ; je lirai avec plaisir d'autres solutions.
Je me doutais un peu que l'input avait un pattern particulier qui devrait permettre d'être plus efficace qu'avec un input plus aléatoire. Qqun a senti la même chose et l'a fait.
Au moins deux fois trop de calculs, mais l'optimisation ne valait pas la peine, ça reste très rapide.
Partie 1 et 2
fromshapely.geometry.polygonimportPolygonfromshapely.geometryimportPointfromitertoolsimportproductasprodP=[tuple(map(int,line.split(",")))forlineinopen(0).read().strip().split('\n')]shape=Polygon(P)ans1=ans2=0for(a,b),(c,d)inprod(P,P):if(a,b)>=(c,d):# avoid comapring a pair twicecontinuearea=(1+abs(a-c))*(1+abs(b-d))ans1=max(ans1,area)ifarea<=ans2:# avoid more computation if not a new maxcontinuerect=Polygon([(a,b),(a,d),(c,d),(c,b)])ifshape.contains(rect):ans2=areaprint(ans1,ans2)
Pas trop d'intérêt à compacter le code puisque je n'ai pas implémenté le gros morceau qu'est le contains.
Beaucoup moins académique que Guillaume, très itératif, les deux parties en 22 lignes:
boxes=[tuple(map(int,line.split(",")))forlineinopen(0).read().strip().split('\n')]clusters=dict()forc,(_,(i,j))inenumerate(sorted(((x-l)**2+(y-m)**2+(z-n)**2,(i,i+1+j))fori,(x,y,z)inenumerate(boxes)forj,(l,m,n)inenumerate(boxes[i+1:]))):icl=[[kfor(k,v)inclusters.items()ifiinv]or["ALONE"]][0][0]jcl=[[kfor(k,v)inclusters.items()ifjinv]or["ALONE"]][0][0]match(icl=="ALONE",jcl=="ALONE",icl==jcl):case(False,False,False):# both belongs to different clusters, merge clustersclusters[f'{i}_{j}']=clusters[icl]|clusters[jcl]delclusters[icl]delclusters[jcl]case(False,True,_):clusters[icl].add(j)case(True,False,_):clusters[jcl].add(i)case(True,True,_):# both out of clusters, create a new cluster with themclusters[f'{i}_{j}']={i,j}# else (False, False, True), i and j are in the same clusterifc==1000:s=sorted(map(len,clusters.values()))print(s[-1]*s[-2]*s[-3])ifc>1000andlen(clusters)==1:print(boxes[i][0]*boxes[j][0])# 5267 connsbreak
J'étais ravi d'ouvrir un problème en 3D, ça fait des jolies illustrations.
J'ai trouvé rapidement l'algo mais j'ai perdu énormément de temps sur:
1/ une mauvaise lecture du calcul qu'il fallait produire pour la première partie ; my bad
2/ le fait qu'il fallait compter comme un connexion le fait de ne rien faire :/
à force de tâtonner, j'ai finit par incrémenter dans tous les cas pour voir et je suis tombé sur la solution ; pas agréable
Première partie très simple, pour chaque line, à chaque fois qu'on split, incrémenter de 1.
Seconde partie, je n'ai pas vu la technique de programmation dynamique que vous évoqués.
J'ai vu un parcours de graphe.
Par flemme de l'implémenter moi même, j'ai voulu le faire avec une lib. Grosse erreur, elle a tournée pendant des plombes et de retour de promenade, je l'ai killé (heureusement que c'est l'hiver et qu'on chauffe).
J'ai finalement implémenté moi même et ça s'est bien passé. Pour éviter l'explosion combinatoire, j'ai utilisé un cache.
Je ne suis pas très fan du problème de ce jour. Je préfère les problèmes avec des astuces algorithmiques (enfin, il y en a peut-être mais je ne les ai pas vu).
Tout pareil.
Je mets le code de la partie 1, c'est le moins laid des deux:
I=open(0).read().strip().split("\n\n")R=[i.split("-")foriinI[0].split("\n")]R=sorted((int(a),int(b))for(a,b)inR)ans=0t=R[0]# tailforrinR[1:]:(a,b)=t(c,d)=rifa<=c<=b:# if can merget=(a,max(b,d))# extendelse:# count rangeans+=b-a+1t=r(a,b)=tans+=b-a+1print(ans)
C'était un produit déjà compliqué à l'époque. La migration v2 vers v3 avait été très pénible. Et là on peut constater qu'ils prennent un virage très entreprise donc plus vraiment intéressant pour du selfhosting.
Va falloir que je me trouve un autre object storage …
# c'est quoi ?
Posté par steph1978 . En réponse au lien USA: les touristes sans visas devront fournir l’historique de leurs médias sociaux. Évalué à 2 (+0/-0). Dernière modification le 12 décembre 2025 à 23:17.
C'est quoi "leurs média sociaux" ?
Autant j'ai un passeport à mon nom autant je n'ai aucun compte facebook/insta/snap/tiktok/x/bluesky/mastodon à mon nom.
[^] # Re: moi je lui demande de ré-ecrire moncode
Posté par steph1978 . En réponse au journal Je lis du code généré. Évalué à 3 (+1/-0).
Et 43% des statistiques sont complètement inventées.
# saleté de cerveau
Posté par steph1978 . En réponse au lien A Lisp Interpreter Implemented in Conway's Game of Life. Évalué à 4 (+2/-0).
Mon cerveau a lu à l'envers : un jeu de la vie de Conway en Lisp. Moui, pas ouf.
Mais non c'est un lisp en jeu de la vie de Conway.
Je savais que le jeu de la vie était Timuring complete. Donc pourquoi pas un interpréteur Lisp.
Ce qui est balaise, c'est de trouver la bonne configuration de départ.
[^] # Re: Pour bien tordre la question dans tous les sens
Posté par steph1978 . En réponse au lien corolaire : vit-on plus longtemps parce qu’on part à la retraite plus tôt ?. Évalué à 4 (+3/-1).
À noter que cell·eux qui prennent leur retraite le plus tard sont les politicien·nes et les hommes/femmes d'affaire. Car 1/ leur métier n'est pas pénible 2/ leur métier leur confère un statut social 3/ leur métier leur payent la plupart de leurs frais qu'ils·elles devraient payer de leur poche une fois à la retraite 4/ ça leur permet de prétendre montrer l'exemple, valeur travail, blabla.
[^] # Re: Jour 11
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
451 microsecondes pour les deux parties en version compilée.
[^] # Re: Jour 11
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0). Dernière modification le 11 décembre 2025 à 18:38.
Bon, je sais pas ce que j'ai merdé mais c'est en effet trivial, en 10 lignes:
En 13MB et 0.05s
[^] # Re: Jour 11
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
# Jour 11
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0). Dernière modification le 11 décembre 2025 à 16:16.
Bonne tranche de rigolade aujourd'hui. On est sur du parcours de graphes.
Première partie implémentée en deux minutes, sans erreurs, directement sur l'input et hop une étoile. On commence à être rôdé.
Partie deux, sur ce bon élan, j'adapte ma solution pour partir d'un autre nœud et ne compter que les chemins qui contiennent les nœuds imposés. Trivial. Je vais faire la journée 11 en moins de dix minutes.
Sauf que le script ne me rend pas la main. Et là, je me dis que je me suis fait avoir.
Je trace le graphe avec Graphviz et je vois l'étendue des dégâts. Le nœud de départ de la première partie est tout près du nœud de sortie. Mais pour la seconde partie, il est très très loin. Donc la combinatoire explose.
Je tente une mise en cache, mais ça ne semble rien améliorer.
J'ai donc exploité la structure du graphe proposé qui 1/ est acyclique, 2/ présente des "couches". J'ai donc calculé un graph plus simple avec seulement les nœuds qui matérialisent les couches et le cout pour passer de l'un à l'autre. Puis lancé le calcul du nombre de chemins sur ce graphe plus simple (18 nœuds versus 644).
Forcément, ça m'a pris une bonne paire d'heures.
Je ne sais pas s'il y avait plus malin à faire ; je lirai avec plaisir d'autres solutions.
[^] # Re: jour 9
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Je me doutais un peu que l'input avait un pattern particulier qui devrait permettre d'être plus efficace qu'avec un input plus aléatoire. Qqun a senti la même chose et l'a fait.
Voici
[^] # Re: jour 9
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0). Dernière modification le 09 décembre 2025 à 11:54.
Partie 1 en 2 lignes
Au moins deux fois trop de calculs, mais l'optimisation ne valait pas la peine, ça reste très rapide.
Partie 1 et 2
Pas trop d'intérêt à compacter le code puisque je n'ai pas implémenté le gros morceau qu'est le
contains.# jour 9
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0). Dernière modification le 09 décembre 2025 à 11:25.
Partie 1 triviale.
Partie 2, j'ai triché en ayant recours à la bibliothèque
shapelyqui permet de faire, entre autres, des opérations sur les polygones.Le code dans le commentaire ci-dessous que vous pouvez plier (
[-]) pour éviter le spoil.[^] # Re: Jour 8
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
[^] # Re: Jour 8
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Beaucoup moins académique que Guillaume, très itératif, les deux parties en 22 lignes:
# Jour 8
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
J'étais ravi d'ouvrir un problème en 3D, ça fait des jolies illustrations.
J'ai trouvé rapidement l'algo mais j'ai perdu énormément de temps sur:
1/ une mauvaise lecture du calcul qu'il fallait produire pour la première partie ; my bad
2/ le fait qu'il fallait compter comme un connexion le fait de ne rien faire :/
à force de tâtonner, j'ai finit par incrémenter dans tous les cas pour voir et je suis tombé sur la solution ; pas agréable
La deuxième partie après cela était triviale.
[^] # Re: Jour 7
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Exactement
Il propose
all_simple_path(source, destination)et je voulais juste les compter mais du coup, ça explose en combinatoire.Je suis tristement pas très familier de cette technique mais de ma compréhension, un algo récursif avec mise en cache, ça s'en rapproche grandement.
[^] # Re: Jour 7
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Première partie très simple, pour chaque line, à chaque fois qu'on split, incrémenter de 1.
Seconde partie, je n'ai pas vu la technique de programmation dynamique que vous évoqués.
J'ai vu un parcours de graphe.
Par flemme de l'implémenter moi même, j'ai voulu le faire avec une lib. Grosse erreur, elle a tournée pendant des plombes et de retour de promenade, je l'ai killé (heureusement que c'est l'hiver et qu'on chauffe).
J'ai finalement implémenté moi même et ça s'est bien passé. Pour éviter l'explosion combinatoire, j'ai utilisé un cache.
[^] # Re: jour 5
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 4 (+2/-0). Dernière modification le 06 décembre 2025 à 15:58.
Et comme le jour 6 ne m'a pas plu, je me suis vengé avec cette version de la partie 2 du jour 5 en une ligne de 199 caractères :
🏌️
[^] # Re: Jour 6
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Tout pareil.
Je mets le code de la partie 1, c'est le moins laid des deux:
[^] # Re: jour 5
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 4 (+2/-0). Dernière modification le 05 décembre 2025 à 20:56.
Et en 4 lignes en utilisant
reduce:Pour comprendre, l'accumulateur est, à tout moment de la réduction, un tuple[la somme accumulé, le max atteint].
[^] # Re: jour 5
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Tu ne crois pas si bien dire.
Les deux parties en 11 linges :
[^] # Re: jour 5
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Partie 1:
Partie 2
# jour 5
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0). Dernière modification le 05 décembre 2025 à 09:48.
Pas sur de voir une différence de difficulté entre ces cinq premiers jours.
Aujourd'hui, première partie en oneshot. Par contre j'ai trop ramé pour faire l'algo de fusion des intervalles alors que c'est tout bête au final 😕
Je mets le code dans le commentaire en dessous. Vous pouvez le fermer en appuyant sur [-] pour éviter le spoil.
[^] # Re: Jour 4
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Je te confirme que c'est plus rapide. C'était ma première version, celle avec laquelle j'ai validé les étoiles.
Mais ça ne tient pas en 6 lignes 😄
[^] # Re: Jour 4
Posté par steph1978 . En réponse au journal Advent of Code 2025. Évalué à 4 (+2/-0).
Très bon jour.
Première partie en one shot, sans passer par l'exemple ; deuxième partie en 1 essai ; en moins de 10 minutes.
Je suis passé par des sets, très facile à manipuler en python et plutôt efficaces en perf.
Voici le code, un peu refactoré pour tenir en 6 lignes:
Cela prend 16MB de RAM et 0.7s de CPU.
# dommage
Posté par steph1978 . En réponse au lien Minio ferme les portes. Évalué à 3 (+1/-0).
C'était un produit déjà compliqué à l'époque. La migration v2 vers v3 avait été très pénible. Et là on peut constater qu'ils prennent un virage très entreprise donc plus vraiment intéressant pour du selfhosting.
Va falloir que je me trouve un autre object storage …