Mon cerveau lent a rampé sur les jeux de mots pas tous si laids.
Ici on ne parlera donc pas du mulot si cher à notre pré-pré-pré-président, mais du Mulet, Fondation de toute culture science-fictive, qui est l'exemple type du fait qu'un/e individu/e n'est pas une statistique, et peu foutre un bordel galactique ; à un/e.
D'autres plus geeks auraient pu suggérer comme constante de pondération l'équation suivante : X=a^n/t*H, d'où le titre de mon message, mais je m'égare.
Concernant la sous-espèce HSL, je peux confirmer une tendance dominante du gène « Libriste », mon exo-partenaire n'ayant rien comprise, mais ma progéniture étant parfaitement prête pour le laptop Manchot (j'entretiens patiemment leur inculture propriétaire).
Et ladite progéniture est aussi prête à mal dormir pour le plaisir d'avoir un félin qui ronronne en lui bouffant les orteils. Mais là, malheureusement d'un point de vue scientifique, pas de données de prévalence génique, c'était foutu des deux côtés.
Je tiens cependant à dire que ma myopie n'a pas évoluée depuis que j'ai découvert Linux, il y a plus de 26 ans, mais qu'après quelques années récentes passées à subir du Windows (et Virtualbox) de façon professionnelle, ma vue a fini par reprendre sa lente dégradation, mais sans apparition de presbytie. Heureusement, j'ai pu mettre fin à cette période douloureuse, j'espère qu'il n'est pas trop tard pour mes yeux, qui ont fortement saignés.
Mais je ne suis pas quadragénaire, j'ai juste eu 20 ans pour la deuxième fois, ce qui se voit à mon absence totale de calvitie, j'ai toujours l'ample et abondante chevelure de mes 19 ans.
À noter que malgré mes requêtes, ma Mère-Grand ne me tricote plus de pull, donc j'en suis réduit à avoir froid, et à froid, point de fusion - pour refaire une boucle gravitationnelle sur les possibles imposture scientifiques.
À sa décharge, l'an prochain elle pourra expérimenter un type de bug classique des sites et systèmes mal foutus qui ne codent l'année de naissance que sur deux chiffres, courage, plus que 13 mois à tenir et elle aura certainement droit à des promos sur les turbulettes.
Mon premier était un 386 à 4Mo !
Ensuite j'ai eu un 286, mais je ne sais plus à quelle quantité de RAM.
Puis un Pentium.
Et après j'ai bricol-acheté un K6-2 350 underclocké à 333, dont j''allouais une partie de la RAM à la carte graphique intégrée, mais je ne me souviens plus de la quantité…
Et ensuite j'ai récupéré un 486 DX4-100 avec 16Mo de RAM et un disque SCSI de 1Go, une vraie bombe !
Le plus ancien qui tourne encore est un laptop DELL inspiron 1501 de 2006, 2Go boosté plus tard à 4Go de RAM, avec le disque 3"5 remplacé aussi par un SSD, ce qui le rend toujours très utilisable.
J'en ai eu d'autres, des machines pros surtout, un NUC intel (i3-6400 2x2.3Ghz, 32Go de RAM) et des SoCs (Embedian, Odroid XU4, et HC4).
Et là j'ai un Shuttle XPC nano NA10H7, Ryzen 7 8x5.1Ghz, 64Go de RAM. Ça doit avoir plus de puissance et de RAM que toutes mes précédentes machines réunies.
Tu as le Fairphone, qui est parfaitement compatible LineageOS ou e/OS/.
Et c'est le plus réparable de tous les téléphones du monde.
L'un des rares où tu peux changer la batterie par exemple, mais aussi ton connecteur USB-C si tu le pètes accidentellement, ou même l'écran.
Sans avoir besoin de poste à souder, des décolleur de bidules collés, et d'outil complexes…
Solution alternative : https://commown.coop/
Qui va te louer un smartphone (dont Fairphone 4, 5 et 6), à tarif dégressif au fil des ans, ce qui incite à le garder longtemps, et qui prennent en charge toutes les réparations (avec franchise pour la destruction de l'écran ou la destruction totale, ou perte, du téléphone).
J'ai récemment changé la batterie du mien (un FP4, après plus de deux ans), devenue efficace à 70%, et en une semaine c'était fait.
Au pire, le téléphone ne te convient pas et tu le retournes, en fermant l'abonnement.
Pour la dernière phrase, tu t'es trompé, c'était « windows est prêt pour le desktop ».
Depuis windows 3.1 ça n'a pas changé, c'est toujours inutilisable et sans ergonomie.
La pollution aux particules fines provient en grande partie de l'usure des pneus, et des plaquettes de frein, on va juste supprimer les résidus de pétrole, ce qui est déjà bien.
La voiture individuelle prend un espace de dingue pour poser ces voitures sur le sol, et souvent il y a de vraies difficultés à la trouver cette place.
Ça coûte une blinde, le prix moyen des bagnoles a augmenté de 13k€ ces dix dernières années, la mienne m'a coûtée 11k€ neuve, et ça coûte terriblement cher en assurance, entretien, etc.
L'alternative c'est de remettre des transports en communs, qui peuvent facilement être nettement moins polluants, et plus économes. Ça coûte cher en infrastructures, mais c'est de la mutualisation, après, c'est rentable, si on pousse des méthodes efficaces.
Donc pas plus de TGV, mais au final, en province, ce dont on a besoin c'est de pouvoir rejoindre la gare TGV sans voiture.
Prend a peu près n'importe quel abonnement de transport en commun, c'est moins cher que d'avoir une voiture, même si elle ne roule presque pas.
Et c'est nettement moins dangereux : tu peux les prendre en toute sécurité même en cas de fatigue, d'ivresse, de maladie, de vieillesse, ou de jeunesse.
Et tu peux dormir, bouquiner, discuter, doom-scroller, ou répondre à des SMS…
En termes de qualité de vie, ça change tout.
Au prix d'un peu de souplesse - dépendant du réseau qui aurait été développé.
Mais c'est une histoire de cercle vicieux : des nouvelles lignes actuellement sont difficilement rentables puisque tout le monde a sa voiture, et qu'au final la perte relative de souplesse, et le fait que la voiture coûte du simple fait de l'avoir, et pas trop par trajet (c'est souvent moins cher au trajet que le train, même seul, hors abonnement).
Pour que ça soit rentable à titre individuel, il faut se débarrasser de sa voiture, et donc il faut un sérieux investissement initial pour fournir directement une offre permettant à un maximum de gens de se séparer dudit bolide.
Et ça, c'est de la politique.
De la politique du service public même, autant dire que c'est pas prêt d'aller dans le bon sens…
Bah non, c'est pas ennuyeux, c'est que du bonheur en fait.
J'ai un rapport technique boulot à faire, je l'écris en org-mode, j'exporte en LaTeX/PDF, et pif, c'est propre, lisible, clair, pro, et j'ai à peu près fait zéro efforts de mise en page.
Bon, quand je fais des cartons d'invitation pour l'anniversaire de mes enfants, je n'utilise pas LaTeX, mais plutôt Scribus par exemple, voire Gimp quand c'est assez simple (c'est souvent simple).
T'as vraiment zéro questions de mise en page à te poser, tu changes un truc, tu exportes, et c'est fini, le reste c'est pas ton problème.
Et dans org-mode tu as une hiérarchie claire, des listes, des tableaux, et même des tableurs, des images, avec légende etc.
Tu veux finalement mettre un paragraphe après un autre : alt+↓
Passer un sous-titre en titre : alt+←
Etc.
LaTeX c'est que du bonheur, et org-mode c'est génial.
Ouais, ça va plus vite.
Jaime bien me creuser la tête sur l'advent of code, un minimum de libs externes, ou de trucs tout faits.
D'ailleurs on doit pouvoir remarquer que plus on appuie sur les boutons rebelles, moins on appuie sur plein d'autres boutons.
Dans un cas avec une seule colonne en trop, on doit pouvoir prouver que la solution maximise la valeur pour cette colonne, en respectant la règle de de n'avoir que des solutions entières.
Donc parcourir depuis le maximum possible en descendant, et s'arrêter dès qu'on a une solution.
Mais ça accélère le cas le plus simple, rien de bien utile en somme.
On voit que pour obtenir le résultat de la ligne 2, 25, on a quatre boutons possibles, notés a, b, c, d. On a a+b+c+d=25, ça fait pas beaucoup de combinaisons, ici 3276, calculées en python avec itertools.combinations_with_replacement([a,b,c,d],25).
Et après je brute-force un peu en espérant avoir suffisamment réduit le champs des possibles.
Ça simplifie suffisamment le problème pour permettre de résoudre la plupart des problèmes parfois en assez longtemps, mais clairement pas tous, j'ai oublié mon programme deux jours, et j'ai un problème qui tournait encore.
Donc là il faut simplifier la matrice. Je fais avec une diagonale, en gardant des nombres entiers positifs, donc je n'ai plus uniquement des 1 dedans.
Je réduis à ça, en réorganisant les lignes, mais l'ordre des boutons n'a pas d'importance, on a juste besoin du nombre total de boutons appuyés :
Ensuite, bah j'ai ma dernière colonne qui casse les pieds, on voit un maximum à 864/60, ou 56/4, ou 264/12, et un minimum à -468/-54, donc une valeur entre 9 et 14.
Alors on remplace, on regarde si notre solution devenue triviale (matrice diagonale, ça va :)) est entière, on jette, et on calcule la solution avec le minimum de boutons appuyés.
Facile.
Parfois, on n'a même pas de dernière colonne et la matrice est diagonale directement, super.
Et puis parfois on en a 2 ou 3, et ça devient casse-pied.
Les calculs de maxima et minima ne tiennent plus, puisque les boutons rebelles influent les uns sur les autres.
Au final j'ai énuméré toutes les possibilités d'appuyer de 0 à 200 fois sur chacun des derniers boutons et résolu, comme au dessus, solution entière, que des valeurs positives, et on prend la plus petite.
Le tout optimisé comme un projet Microsoft, ça prend 2 minutes 36s, et le résultat est valide.
Je n'arrive déjà plus à relire mon code, et ça sent qu'il faudrait utiliser une bibliothèque d'algèbre linéaire, au moins pour les simplifications, et manipulations de lignes et colonnes, un numpy avec des matrices propres serait probablement une grande avancée dans la lisibilité et les performances.
À noter qu'avec un solveur, dans l'exemple au dessus, il suffit de rajouter une ligne [0, 0, 0, 0, 0, 0, 0, 0, 0, 1] = (valeur de 9 à 14), et de lui dire « c'est bon, c'est carré, alors c'est quoi ma solution ? », de vérifier qu'elle est entière et de passer à la suite.
Mais bon, la résolution d'une matrice diagonale, c'est pas vraiment le plus difficile !
Bref, j'aurais bien pataugé dans ce problème, pour au final ne pas avoir trouvé de truc sensiblement différent des autres, moins bien fait et en plus longtemps.
Officiellement la cuvée 2025 n'est pas la meilleure pour moi ;)
Posté par Yth (Mastodon) .
En réponse au journal Advent of Code 2025.
Évalué à 2 (+0/-0).
Dernière modification le 13 décembre 2025 à 15:53.
Ah ouais, j'ai juste eu le temps de réfléchir au problème, mais c'est tellement con au final.
Me reste plus qu'à prendre le temps de finir le jour 10 maintenant, parce que sur téléphone c'est trop galère, donc je dois retrouver mon PC, et mon Linux :)
Une journée - encore - sans ordinateur, avec une résolution en très peu de temps de réflexion, et un calcul instantané sur téléphone.
Pour l'exercice 2, un cache bien posé, un découpage en trois sous-graphes entre svr->fft->dac->out, et la supposition qu'il n'y avait pas de boucles.
En fait, avec des boucles, de toute façon l'énoncé est infaisable, puisqu'on doit dénombrer les chemins possible, une seule boucle où que ce soit sur un seul chemin permet un nombre infini de chemins.
Les boucles ça se gère en cas de recherche du plus court chemin.
Si j'avais eu 0 entre fft et dac, j'aurais inversé les deux, et pour le cas général, additionner les deux semble pertinent.
J'ai aussi fait une fonction d'analyse des données pour faire le cas d'exemple, où les données sont différentes entre l'exercice 1 et le 2, d'où le clear_cache aussi.
Ma multiplication finale c'est 3241 * 22130172 * 7345, donc avec un algo plus naïf, et surtout sans cache, on arrive à trouver les valeurs de svr à fft et de dac à out, mais pas de fft à dac, avec 22 millions de chemins.
En pratique, ma fonction paths est appelée 3102 fois entre les deux exercices, avec 1891 fois où le cache a répondu et 1211 fois où le contenu de la fonction a été exécuté, autant dire que c'est assez négligeable pour le dénombrement total de ~500 billions de chemins, et ça ne prend rien en RAM.
Ici, j'ai réfléchi au fait que si on a deux boîtes de dérivation qui ne sont pas reliées par le fil le plus petit existant, alors on peut raccourcir le réseau total.
Donc il apparaît clair qu'il faut ajouter les liens du plus petit au plus grand, jusqu'à compléter l'exercice.
J'ai un peu lutté sur la représentation des données, je voulais être intelligent, mais je me suis retrouvé avec des cas où des sous-graphes étaient encore référencés.
Là, j'aurais été plus à l'aise en C, à manipuler proprement des pointeurs, pour modifier directement les données à plusieurs endroits à la fois.
Bon, je le fais aussi en Python, mais j'ai des trucs qui m'ont embêté, et j'ai perdu l'élégance que j'espérais avoir.
Au final, j'ai quand même un truc pas super optimisé qui s'exécute en 3,5s, c'est très laid.
Et comme ça prend seulement 1s en PyPy, je sais que j'ai fait du mauvais travail :D
fromdataclassesimportdataclassimportmathimportitertoolsMAX=1000# 10 pour l'exempledata=sys.stdin.read().strip().splitlines()@dataclass(frozen=True)classBox:x:inty:intz:intdef__mul__(self,x):# distance euclidienne: a*breturn(self.x-x.x)**2+(self.y-x.y)**2+(self.z-x.z)**2boxes={Box(*(int(_)for_inl.split(",")))forlindata}dist=sorted({(a*b,frozenset((a,b)))fora,binitertools.product(boxes,boxes)ifb!=a})circuits={b:{b}forbinboxes}fori,(d,(a,b))inenumerate(dist):ifbnotincircuits[a]:c=circuits[a].union(circuits[b])iflen(c)==len(boxes):break# On a finifor_inc:circuits[_]=cifi==MAX-1:ex1={(len(_),frozenset(_))for_incircuits.values()}ex1=math.prod(sorted(lforl,_inex1)[-3:])ex2=a.x*b.x
Posté par Yth (Mastodon) .
En réponse au journal Advent of Code 2025.
Évalué à 2 (+0/-0).
Dernière modification le 09 décembre 2025 à 19:18.
Je ne crois pas avoir spécialement utilisé mon cerveau pour cet exercice, un code sur smartphone, peu lisible, mais efficace.
Je crois avoir été naïf en première approche, mais la naïveté ici est explosive : on ne peut pas compter les 357 525 737 893 560 rayons de l'exercice 2 de façon indépendante.
data=sys.stdin.read().strip().splitlines()w,h=len(data[0]),len(data)map="".join(data)b={map.index("S")}# exercice 1c={map.index("S"):1}# exercice 2: 1 seul rayon au départex1=0for_inrange(h-1):n={i+wforiinbifmap[i+w]=="."}# ligne droites={i+wforiinbifmap[i+w]=="^"}# splitex1+=len(s)# Tous les endroits où on a des rayons, pour les 2 exercicesb=n.union({i+1foriins},{i-1foriins})# ex1d={i:c[i-w]ifiinnelse0foriinb}# On reprend les rayons directsforiins:# On ajoute les rayons splittésd[i-1]+=c[i-w]d[i+1]+=c[i-w]c=dex2=sum(c.values())
Pour la partie 2, je transpose la matrice des données en inversant les X et les Y, en gros ça fait un miroir par la diagonale, pour lire dans l'autre sens.
En ayant retiré la ligne d'opérateurs à la fin.
Et après les nombres sont séparés par des lignes vides.
C'est assez simple.
fromoperatorimportmul,adddata=sys.stdin.read().strip().splitlines()op=[{"+":add,"*":mul}[_]for_indata[-1].split()]r=[0ifo==addelse1foroinop]forlindata[:-1]:fori,vinenumerate(l.split()):r[i]=op[i](r[i],int(v))ex1=sum(r)d=[# bascule de matrice"".join([l[j]forlindata[:-1]]).strip()forjinrange(len(data[0]))]i,r=0,[0ifo==addelse1foroinop]forlind:ifnotl:i+=1continuer[i]=op[i](r[i],int(l))ex2=sum(r)
Ah, c'est bien ça, shapely.
Parce que bon, j'ai salement polioté sur cette partie, et au final j'ai une solution en faisant une hypothèse de travail et 9 minutes de calculs avec PyPy.
Il faut beaucoup trop réfléchir pour modéliser le bidule proprement, savoir ce qui est dedans et dehors, dépatouiller les sous-ensembles etc.
Et mon code aurait foiré s'il y avait eu des « crochets » du genre ça, en considérant le rectangle entre les deux O, la case avec un _ rend le rectangle impossible, mais n'est pas « vue » par mon algo :
######.#....#.#O##.#.##_#.O#...#..#.###..#.######
Bref, c'est moche, je montre pas, mais dans l'idée, je liste toutes les arêtes, puis pour chaque x possible (0 à 100000 en gros) on regarde le y maximal et minimal, et on fait idem pour les les y possible avec les x maximal et minimal.
L'hypothèse ici c'est qu'on voit toutes les arêtes depuis l'extérieur de la surface, nord, sud, est ouest, on a soit une arête dans l'axe et on voit une seule case, soit elle est entièrement visible face à nous.
Là dessus, pour chaque rectangle possible, triés par superficie décroissante, on regarde si les sommets sont « à l'intérieur », c'est à dire si pour le x du sommet, le y est entre le max et le min, et si pour le y du sommet le x est entre le min et le max.
Si c'est le cas, on pousse plus loin, et on teste tous les bords du rectangle (nous avons ici une optimisation d'échelle, permettant d'éliminer très rapidement la majorité des rectangles, et de se concentrer sur ceux qui ont un potentiel !).
Dès qu'on est 100% OK, on a le bon résultat, et ça fonctionne.
C'est brutal, je ne suis pas sûr de pourquoi ça prend tant de temps, je suppose que je pourrais optimiser mon calcul initial des bornes, j'ai utiliser un cache de fonction, puis j'ai forcé le remplissage du cache au début pour voir pourquoi c'était long.
Et la version Python (non PyPy donc) bloque au calcul du bon rectangle.
D'expérience, si la version Python est plus lente que la version PyPy, c'est qu'on a fait de la boue…
Une bonne optimisation serait de simplifier le terrain par tous les x et y existant dans les coordonnées.
Dans l'exemple on a x dans [2, 7, 9, 11] et y dans [1, 3, 5, 7], et en réalité le « terrain » fait 4x4 et non 11x7. Dans le cas réel, on a un terrain de moins de 250x250 (496 lignes et chaque coordonnées y est normalement au moins représentée deux fois), et là c'est plutôt facile de parcourir un peu en force sur une terrain minuscule (60 000 cases contre 10 milliards…).
Mais ça demande de bien réfléchir à ne pas tomber sur des effets de bords.
Et ceci m'a - enfin - amené à une optimisation intermédiaire : je reprend exactement mon algo, mais après avoir testé les sommets des différents rectangles, au lieu de tester les côtés entiers, je ne teste que les points dont les coordonnées sont dans cette fameuse liste réduite de ~250 x et ~250 y.
Je tombe à 3s avec PyPy, ce qui prouve qu'on doit pouvoir optimiser pour aller à une vitesse raisonnable.
Mais…
Mais est-ce que ça répond au problème dans le cas général ? Est-ce que j'ai un biais de chez-moi-ça-marche ? Parce que je peux décrire des situations où ça ne fonctionne pas, typiquement mon exemple plus haut. J'ai quand même une simplification qui n'est absolument pas prévue par l'énoncé du problème.
Bref, shapely c'est officiellement une bonne solution…
On peut facilement faire mieux en stockant les adresses des @ dans un ensemble, et en supprimant à chaque itération ceux qu'on a pu repérer.
Ça évite de reconstruire une carte, et ça laisse manipuler uniquement des ensembles d'entiers, ça doit forcément être plus efficace que de jouer avec une chaîne de caractères.
Jour 4 : pour des raisons personnelles, aucun accès à un ordinateur de la journée. Mais une balade, fairphone à la main.
Armé de mon qpython, je code…
Ici, pas de noms de variables explicites, parce que écrire sur un clavier tactile, c'est chiant, donc moins on écrit, mieux on se porte.
Ici, un classique, pour tester les 8 directions, on définit une carte en ayant ajouté une bordure vide autour, qu'on bascule en 1 dimension, avec huit déplacements entiers.
Posté par Yth (Mastodon) .
En réponse au journal Advent of Code 2025.
Évalué à 4 (+2/-0).
Dernière modification le 03 décembre 2025 à 14:31.
Assez similaire dans l'algo au bout du compte, j'ai passé assez rapidement le second exercice, pas de bug, j'ai trouvé plus simple celui du jour.
Yth.
data=stdin.read().strip().splitlines()defjoltage(bank,count=2):r,i,bank=[],0,bank+"."# bank[i:-0] does not work, going for [:-1] with 1 garbageforninrange(count,0,-1):r.append(a:=max(bank[i:-n]))i+=bank[i:].index(a)+1# i(ndex) of next unused battery inside bankreturnint("".join(r))ex1=sum(joltage(_,2)for_indata)ex2=sum(joltage(_,12)for_indata)
[^] # Re: 640 Ko c'est bien suffisant
Posté par Yth (Mastodon) . En réponse au sondage Quelle quantité de RAM ai-je sur ma machine principale ?. Évalué à 2 (+0/-0).
Oui, mais c'est toujours inutilisable et sans ergonomie.
# Lunes pour Caméléon.
Posté par Yth (Mastodon) . En réponse au journal À la recherche du Linuxfrien type. Évalué à 3 (+1/-0). Dernière modification le 08 janvier 2026 à 11:39.
Mon cerveau lent a rampé sur les jeux de mots pas tous si laids.
Ici on ne parlera donc pas du mulot si cher à notre pré-pré-pré-président, mais du Mulet, Fondation de toute culture science-fictive, qui est l'exemple type du fait qu'un/e individu/e n'est pas une statistique, et peu foutre un bordel galactique ; à un/e.
D'autres plus geeks auraient pu suggérer comme constante de pondération l'équation suivante :
X=a^n/t*H, d'où le titre de mon message, mais je m'égare.Concernant la sous-espèce HSL, je peux confirmer une tendance dominante du gène « Libriste », mon exo-partenaire n'ayant rien comprise, mais ma progéniture étant parfaitement prête pour le laptop Manchot (j'entretiens patiemment leur inculture propriétaire).
Et ladite progéniture est aussi prête à mal dormir pour le plaisir d'avoir un félin qui ronronne en lui bouffant les orteils. Mais là, malheureusement d'un point de vue scientifique, pas de données de prévalence génique, c'était foutu des deux côtés.
Je tiens cependant à dire que ma myopie n'a pas évoluée depuis que j'ai découvert Linux, il y a plus de 26 ans, mais qu'après quelques années récentes passées à subir du Windows (et Virtualbox) de façon professionnelle, ma vue a fini par reprendre sa lente dégradation, mais sans apparition de presbytie. Heureusement, j'ai pu mettre fin à cette période douloureuse, j'espère qu'il n'est pas trop tard pour mes yeux, qui ont fortement saignés.
Mais je ne suis pas quadragénaire, j'ai juste eu 20 ans pour la deuxième fois, ce qui se voit à mon absence totale de calvitie, j'ai toujours l'ample et abondante chevelure de mes 19 ans.
À noter que malgré mes requêtes, ma Mère-Grand ne me tricote plus de pull, donc j'en suis réduit à avoir froid, et à froid, point de fusion - pour refaire une boucle gravitationnelle sur les possibles imposture scientifiques.
À sa décharge, l'an prochain elle pourra expérimenter un type de bug classique des sites et systèmes mal foutus qui ne codent l'année de naissance que sur deux chiffres, courage, plus que 13 mois à tenir et elle aura certainement droit à des promos sur les turbulettes.
Et tout ça, bah c'est pas rin !
[^] # Re: Les couleurs
Posté par Yth (Mastodon) . En réponse au journal À la recherche du Linuxfrien type. Évalué à 3 (+1/-0).
Exactement : Linux 1991, et Windows 1995.
Paf.
[^] # Re: Des fayens dans les illustrations
Posté par Yth (Mastodon) . En réponse au journal À la recherche du Linuxfrien type. Évalué à 3 (+1/-0).
Ça ne marche que pour les cerfs-volants.
[^] # Re: role pas motivant.
Posté par Yth (Mastodon) . En réponse au lien Debian : toute l'équipe de protection des données démissionne. Évalué à 2 (+0/-0).
Rhooo, fichtre, ça rappelle des souvenirs cette conversation lunaire ^
J'espère qu'ellui l'a pas fait son burnout, et a su décrocher avant de cramer…
[^] # Re: 640 Ko c'est bien suffisant
Posté par Yth (Mastodon) . En réponse au sondage Quelle quantité de RAM ai-je sur ma machine principale ?. Évalué à 2 (+0/-0).
Mon premier était un 386 à 4Mo !
Ensuite j'ai eu un 286, mais je ne sais plus à quelle quantité de RAM.
Puis un Pentium.
Et après j'ai bricol-acheté un K6-2 350 underclocké à 333, dont j''allouais une partie de la RAM à la carte graphique intégrée, mais je ne me souviens plus de la quantité…
Et ensuite j'ai récupéré un 486 DX4-100 avec 16Mo de RAM et un disque SCSI de 1Go, une vraie bombe !
Le plus ancien qui tourne encore est un laptop DELL inspiron 1501 de 2006, 2Go boosté plus tard à 4Go de RAM, avec le disque 3"5 remplacé aussi par un SSD, ce qui le rend toujours très utilisable.
J'en ai eu d'autres, des machines pros surtout, un NUC intel (i3-6400 2x2.3Ghz, 32Go de RAM) et des SoCs (Embedian, Odroid XU4, et HC4).
Et là j'ai un Shuttle XPC nano NA10H7, Ryzen 7 8x5.1Ghz, 64Go de RAM. Ça doit avoir plus de puissance et de RAM que toutes mes précédentes machines réunies.
[^] # Re: Avec un système d’exploitation alternatif ?
Posté par Yth (Mastodon) . En réponse au message A la recherche d'un telephone mobile. Évalué à 2 (+0/-0).
Tu peux blâmer, mais normalement tes parents te remettent vite fait à ta place ;)
# Fairphone
Posté par Yth (Mastodon) . En réponse au message A la recherche d'un telephone mobile. Évalué à 7 (+5/-0).
Tu as le Fairphone, qui est parfaitement compatible LineageOS ou e/OS/.
Et c'est le plus réparable de tous les téléphones du monde.
L'un des rares où tu peux changer la batterie par exemple, mais aussi ton connecteur USB-C si tu le pètes accidentellement, ou même l'écran.
Sans avoir besoin de poste à souder, des décolleur de bidules collés, et d'outil complexes…
Solution alternative : https://commown.coop/
Qui va te louer un smartphone (dont Fairphone 4, 5 et 6), à tarif dégressif au fil des ans, ce qui incite à le garder longtemps, et qui prennent en charge toutes les réparations (avec franchise pour la destruction de l'écran ou la destruction totale, ou perte, du téléphone).
J'ai récemment changé la batterie du mien (un FP4, après plus de deux ans), devenue efficace à 70%, et en une semaine c'était fait.
Au pire, le téléphone ne te convient pas et tu le retournes, en fermant l'abonnement.
[^] # Re: 640 Ko c'est bien suffisant
Posté par Yth (Mastodon) . En réponse au sondage Quelle quantité de RAM ai-je sur ma machine principale ?. Évalué à 10 (+8/-0).
Pour la dernière phrase, tu t'es trompé, c'était « windows est prêt pour le desktop ».
Depuis windows 3.1 ça n'a pas changé, c'est toujours inutilisable et sans ergonomie.
Bisous,
[^] # Re: Mineurs
Posté par Yth (Mastodon) . En réponse au journal Nintendo enfreint le droit de propriété. Évalué à 7 (+5/-0).
Ouais, la disquette, c'est l'icône de distributeur de boisson qui sert à sauvegarder les fichiers, rien à voir…!
[^] # Re: Tentative d'explication
Posté par Yth (Mastodon) . En réponse au lien Voitures neuves : la Commission renonce au tout-électrique pour 2035. Évalué à 2 (+1/-1).
Les arguments sont très intéressants.
Mais :
L'alternative c'est de remettre des transports en communs, qui peuvent facilement être nettement moins polluants, et plus économes. Ça coûte cher en infrastructures, mais c'est de la mutualisation, après, c'est rentable, si on pousse des méthodes efficaces.
Donc pas plus de TGV, mais au final, en province, ce dont on a besoin c'est de pouvoir rejoindre la gare TGV sans voiture.
Prend a peu près n'importe quel abonnement de transport en commun, c'est moins cher que d'avoir une voiture, même si elle ne roule presque pas.
Et c'est nettement moins dangereux : tu peux les prendre en toute sécurité même en cas de fatigue, d'ivresse, de maladie, de vieillesse, ou de jeunesse.
Et tu peux dormir, bouquiner, discuter, doom-scroller, ou répondre à des SMS…
En termes de qualité de vie, ça change tout.
Au prix d'un peu de souplesse - dépendant du réseau qui aurait été développé.
Mais c'est une histoire de cercle vicieux : des nouvelles lignes actuellement sont difficilement rentables puisque tout le monde a sa voiture, et qu'au final la perte relative de souplesse, et le fait que la voiture coûte du simple fait de l'avoir, et pas trop par trajet (c'est souvent moins cher au trajet que le train, même seul, hors abonnement).
Pour que ça soit rentable à titre individuel, il faut se débarrasser de sa voiture, et donc il faut un sérieux investissement initial pour fournir directement une offre permettant à un maximum de gens de se séparer dudit bolide.
Et ça, c'est de la politique.
De la politique du service public même, autant dire que c'est pas prêt d'aller dans le bon sens…
[^] # Re: Latex la galère
Posté par Yth (Mastodon) . En réponse au journal pdfLaTeX, XeLaTeX et LuaLaTeX sont dans un bateau. Évalué à 3 (+2/-1).
Bah non, c'est pas ennuyeux, c'est que du bonheur en fait.
J'ai un rapport technique boulot à faire, je l'écris en org-mode, j'exporte en LaTeX/PDF, et pif, c'est propre, lisible, clair, pro, et j'ai à peu près fait zéro efforts de mise en page.
Bon, quand je fais des cartons d'invitation pour l'anniversaire de mes enfants, je n'utilise pas LaTeX, mais plutôt Scribus par exemple, voire Gimp quand c'est assez simple (c'est souvent simple).
T'as vraiment zéro questions de mise en page à te poser, tu changes un truc, tu exportes, et c'est fini, le reste c'est pas ton problème.
Et dans org-mode tu as une hiérarchie claire, des listes, des tableaux, et même des tableurs, des images, avec légende etc.
Tu veux finalement mettre un paragraphe après un autre : alt+↓
Passer un sous-titre en titre : alt+←
Etc.
LaTeX c'est que du bonheur, et org-mode c'est génial.
[^] # Re: Jour 10
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Ouais, ça va plus vite.
Jaime bien me creuser la tête sur l'advent of code, un minimum de libs externes, ou de trucs tout faits.
D'ailleurs on doit pouvoir remarquer que plus on appuie sur les boutons rebelles, moins on appuie sur plein d'autres boutons.
Dans un cas avec une seule colonne en trop, on doit pouvoir prouver que la solution maximise la valeur pour cette colonne, en respectant la règle de de n'avoir que des solutions entières.
Donc parcourir depuis le maximum possible en descendant, et s'arrêter dès qu'on a une solution.
Mais ça accélère le cas le plus simple, rien de bien utile en somme.
[^] # Re: Jour 10
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Ben j'ai fini par bricoler un truc qui fonctionne, mais bigre, j'ai pas les maths bien à plat sur ce problème.
Au début j'avais cherché les boutons avec le moins de choix possibles.
Exemple :
On voit que pour obtenir le résultat de la ligne 2, 25, on a quatre boutons possibles, notés a, b, c, d. On a a+b+c+d=25, ça fait pas beaucoup de combinaisons, ici 3276, calculées en python avec
itertools.combinations_with_replacement([a,b,c,d],25).Et après je brute-force un peu en espérant avoir suffisamment réduit le champs des possibles.
Ça simplifie suffisamment le problème pour permettre de résoudre la plupart des problèmes parfois en assez longtemps, mais clairement pas tous, j'ai oublié mon programme deux jours, et j'ai un problème qui tournait encore.
Donc là il faut simplifier la matrice. Je fais avec une diagonale, en gardant des nombres entiers positifs, donc je n'ai plus uniquement des 1 dedans.
Je réduis à ça, en réorganisant les lignes, mais l'ordre des boutons n'a pas d'importance, on a juste besoin du nombre total de boutons appuyés :
Ensuite, bah j'ai ma dernière colonne qui casse les pieds, on voit un maximum à 864/60, ou 56/4, ou 264/12, et un minimum à -468/-54, donc une valeur entre 9 et 14.
Alors on remplace, on regarde si notre solution devenue triviale (matrice diagonale, ça va :)) est entière, on jette, et on calcule la solution avec le minimum de boutons appuyés.
Facile.
Parfois, on n'a même pas de dernière colonne et la matrice est diagonale directement, super.
Et puis parfois on en a 2 ou 3, et ça devient casse-pied.
Les calculs de maxima et minima ne tiennent plus, puisque les boutons rebelles influent les uns sur les autres.
Au final j'ai énuméré toutes les possibilités d'appuyer de 0 à 200 fois sur chacun des derniers boutons et résolu, comme au dessus, solution entière, que des valeurs positives, et on prend la plus petite.
Le tout optimisé comme un projet Microsoft, ça prend 2 minutes 36s, et le résultat est valide.
Je n'arrive déjà plus à relire mon code, et ça sent qu'il faudrait utiliser une bibliothèque d'algèbre linéaire, au moins pour les simplifications, et manipulations de lignes et colonnes, un numpy avec des matrices propres serait probablement une grande avancée dans la lisibilité et les performances.
À noter qu'avec un solveur, dans l'exemple au dessus, il suffit de rajouter une ligne
[0, 0, 0, 0, 0, 0, 0, 0, 0, 1] = (valeur de 9 à 14), et de lui dire « c'est bon, c'est carré, alors c'est quoi ma solution ? », de vérifier qu'elle est entière et de passer à la suite.Mais bon, la résolution d'une matrice diagonale, c'est pas vraiment le plus difficile !
Bref, j'aurais bien pataugé dans ce problème, pour au final ne pas avoir trouvé de truc sensiblement différent des autres, moins bien fait et en plus longtemps.
Officiellement la cuvée 2025 n'est pas la meilleure pour moi ;)
[^] # Re: Jour 12
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0). Dernière modification le 13 décembre 2025 à 15:53.
Ah ouais, j'ai juste eu le temps de réfléchir au problème, mais c'est tellement con au final.
Me reste plus qu'à prendre le temps de finir le jour 10 maintenant, parce que sur téléphone c'est trop galère, donc je dois retrouver mon PC, et mon Linux :)
[^] # Re: Jour 11
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Une journée - encore - sans ordinateur, avec une résolution en très peu de temps de réflexion, et un calcul instantané sur téléphone.
Pour l'exercice 2, un cache bien posé, un découpage en trois sous-graphes entre svr->fft->dac->out, et la supposition qu'il n'y avait pas de boucles.
En fait, avec des boucles, de toute façon l'énoncé est infaisable, puisqu'on doit dénombrer les chemins possible, une seule boucle où que ce soit sur un seul chemin permet un nombre infini de chemins.
Les boucles ça se gère en cas de recherche du plus court chemin.
Si j'avais eu 0 entre fft et dac, j'aurais inversé les deux, et pour le cas général, additionner les deux semble pertinent.
J'ai aussi fait une fonction d'analyse des données pour faire le cas d'exemple, où les données sont différentes entre l'exercice 1 et le 2, d'où le clear_cache aussi.
Ma multiplication finale c'est
3241 * 22130172 * 7345, donc avec un algo plus naïf, et surtout sans cache, on arrive à trouver les valeurs de svr à fft et de dac à out, mais pas de fft à dac, avec 22 millions de chemins.En pratique, ma fonction paths est appelée 3102 fois entre les deux exercices, avec 1891 fois où le cache a répondu et 1211 fois où le contenu de la fonction a été exécuté, autant dire que c'est assez négligeable pour le dénombrement total de ~500 billions de chemins, et ça ne prend rien en RAM.
[^] # Re: jour 9
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Je me pose des questions sur un truc comme ça :
Qui se « simplifie » en ne considérant que les coordonnées des 8 sommets, en ça :
Et nous dis assez facilement que le rectangle complet est valide alors que pas vraiment, en vrai.
[^] # Re: Jour 8
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Ici, j'ai réfléchi au fait que si on a deux boîtes de dérivation qui ne sont pas reliées par le fil le plus petit existant, alors on peut raccourcir le réseau total.
Donc il apparaît clair qu'il faut ajouter les liens du plus petit au plus grand, jusqu'à compléter l'exercice.
J'ai un peu lutté sur la représentation des données, je voulais être intelligent, mais je me suis retrouvé avec des cas où des sous-graphes étaient encore référencés.
Là, j'aurais été plus à l'aise en C, à manipuler proprement des pointeurs, pour modifier directement les données à plusieurs endroits à la fois.
Bon, je le fais aussi en Python, mais j'ai des trucs qui m'ont embêté, et j'ai perdu l'élégance que j'espérais avoir.
Au final, j'ai quand même un truc pas super optimisé qui s'exécute en 3,5s, c'est très laid.
Et comme ça prend seulement 1s en PyPy, je sais que j'ai fait du mauvais travail :D
[^] # Re: Jour 7
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0). Dernière modification le 09 décembre 2025 à 19:18.
Je ne crois pas avoir spécialement utilisé mon cerveau pour cet exercice, un code sur smartphone, peu lisible, mais efficace.
Je crois avoir été naïf en première approche, mais la naïveté ici est explosive : on ne peut pas compter les 357 525 737 893 560 rayons de l'exercice 2 de façon indépendante.
[^] # Re: Jour 6
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Pour la partie 2, je transpose la matrice des données en inversant les X et les Y, en gros ça fait un miroir par la diagonale, pour lire dans l'autre sens.
En ayant retiré la ligne d'opérateurs à la fin.
Et après les nombres sont séparés par des lignes vides.
C'est assez simple.
Prodigieusement peu lisible, mais assez concis :)
[^] # Re: jour 5
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
Jour 5, 6, 7, 8, pas d'ordinateur, résolus en balade, dans la forêt, sur un téléphone…
Donc concis, moche, peu clair, mais un minimum performant, et je me rappelle plus de l'énoncé, alors pour expliquer…
[^] # Re: jour 9
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Ah, c'est bien ça, shapely.
Parce que bon, j'ai salement polioté sur cette partie, et au final j'ai une solution en faisant une hypothèse de travail et 9 minutes de calculs avec PyPy.
Il faut beaucoup trop réfléchir pour modéliser le bidule proprement, savoir ce qui est dedans et dehors, dépatouiller les sous-ensembles etc.
Et mon code aurait foiré s'il y avait eu des « crochets » du genre ça, en considérant le rectangle entre les deux O, la case avec un _ rend le rectangle impossible, mais n'est pas « vue » par mon algo :
Bref, c'est moche, je montre pas, mais dans l'idée, je liste toutes les arêtes, puis pour chaque x possible (0 à 100000 en gros) on regarde le y maximal et minimal, et on fait idem pour les les y possible avec les x maximal et minimal.
L'hypothèse ici c'est qu'on voit toutes les arêtes depuis l'extérieur de la surface, nord, sud, est ouest, on a soit une arête dans l'axe et on voit une seule case, soit elle est entièrement visible face à nous.
Là dessus, pour chaque rectangle possible, triés par superficie décroissante, on regarde si les sommets sont « à l'intérieur », c'est à dire si pour le x du sommet, le y est entre le max et le min, et si pour le y du sommet le x est entre le min et le max.
Si c'est le cas, on pousse plus loin, et on teste tous les bords du rectangle (nous avons ici une optimisation d'échelle, permettant d'éliminer très rapidement la majorité des rectangles, et de se concentrer sur ceux qui ont un potentiel !).
Dès qu'on est 100% OK, on a le bon résultat, et ça fonctionne.
C'est brutal, je ne suis pas sûr de pourquoi ça prend tant de temps, je suppose que je pourrais optimiser mon calcul initial des bornes, j'ai utiliser un cache de fonction, puis j'ai forcé le remplissage du cache au début pour voir pourquoi c'était long.
Et la version Python (non PyPy donc) bloque au calcul du bon rectangle.
D'expérience, si la version Python est plus lente que la version PyPy, c'est qu'on a fait de la boue…
Une bonne optimisation serait de simplifier le terrain par tous les x et y existant dans les coordonnées.
Dans l'exemple on a x dans [2, 7, 9, 11] et y dans [1, 3, 5, 7], et en réalité le « terrain » fait 4x4 et non 11x7. Dans le cas réel, on a un terrain de moins de 250x250 (496 lignes et chaque coordonnées y est normalement au moins représentée deux fois), et là c'est plutôt facile de parcourir un peu en force sur une terrain minuscule (60 000 cases contre 10 milliards…).
Mais ça demande de bien réfléchir à ne pas tomber sur des effets de bords.
Et ceci m'a - enfin - amené à une optimisation intermédiaire : je reprend exactement mon algo, mais après avoir testé les sommets des différents rectangles, au lieu de tester les côtés entiers, je ne teste que les points dont les coordonnées sont dans cette fameuse liste réduite de ~250 x et ~250 y.
Je tombe à 3s avec PyPy, ce qui prouve qu'on doit pouvoir optimiser pour aller à une vitesse raisonnable.
Mais…
Mais est-ce que ça répond au problème dans le cas général ? Est-ce que j'ai un biais de chez-moi-ça-marche ? Parce que je peux décrire des situations où ça ne fonctionne pas, typiquement mon exemple plus haut. J'ai quand même une simplification qui n'est absolument pas prévue par l'énoncé du problème.
Bref, shapely c'est officiellement une bonne solution…
[^] # Re: Jour 4
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 2 (+0/-0).
On peut facilement faire mieux en stockant les adresses des @ dans un ensemble, et en supprimant à chaque itération ceux qu'on a pu repérer.
Ça évite de reconstruire une carte, et ça laisse manipuler uniquement des ensembles d'entiers, ça doit forcément être plus efficace que de jouer avec une chaîne de caractères.
[^] # Re: Jour 4
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 3 (+1/-0).
Jour 4 : pour des raisons personnelles, aucun accès à un ordinateur de la journée. Mais une balade, fairphone à la main.
Armé de mon qpython, je code…
Ici, pas de noms de variables explicites, parce que écrire sur un clavier tactile, c'est chiant, donc moins on écrit, mieux on se porte.
Ici, un classique, pour tester les 8 directions, on définit une carte en ayant ajouté une bordure vide autour, qu'on bascule en 1 dimension, avec huit déplacements entiers.
Durée difficile à évaluer, c'est lent en qpython, zéro chance de brute force.
On est à 3s environ, donc l'algo est assez bon 😉
[^] # Re: Jour 3
Posté par Yth (Mastodon) . En réponse au journal Advent of Code 2025. Évalué à 4 (+2/-0). Dernière modification le 03 décembre 2025 à 14:31.
Assez similaire dans l'algo au bout du compte, j'ai passé assez rapidement le second exercice, pas de bug, j'ai trouvé plus simple celui du jour.