Advent Of Code 2025

[ThaSandman]

Ik doe ook zeker weer mee! Ruby it is

[Salandur]

Ik ga hem dit jaar ook weer proberen :-)

[OB1]

Ik wil ook graag meedoen, mijn Git-repository staat hier: https://github.com/OlivierBouchoms/advent-of-code-2025

Ik twijfel nog over de taal... wil een keer iets anders doen dan C# of JS. Klinkt als een mooie gelegenheid om weer eens iets met Python te gaan doen!

[Devilfish]

Ik verwacht ook wel weer mee te doen in C# via https://github.com/antonrademaker/codeadvent

[Woy]

Eens kijken of ik dit jaar wel weer eens verder kom dan de eerste week

[ZpAz]

Probeer meestal wel wat mee te doen, maar dit jaar waarschijnlijk echt geen tijd. Misschien dat dat tegen December veranderd. Maar daar lijkt het niet op.

[Mschamp]

Ik ga ook terug meedoen in C#, maar door het werk zal het iets meer 'wanneer ik tijd heb' zijn

[wackmaniac]

https://www.reddit.com/r/adventofcode/s/X35Npb0xvT

tl/dr; het aantal dagen wordt teruggebracht tot 12 dagen - beginnend op 1 december -, en de global leaderboard verdwijnt.

Als ik eerlijk ben dan is minder dagen wel lekker. Vanaf dag 14/15 wordt het toch altijd wel weer een behoorlijke opgave (pun intended). En het verdwijnen van het global leaderboard is denk ik een logisch gevolg van de groeiende hoeveelheid AI-gebruikers. Nu wordt het veel meer; wil jij AI gebruiken? Gebruik jij toch lekker AI!

[Mugwump]

Ik vind het ook geen slechte ontwikkeling. Ik merk gewoon dat ik te lang niet met al m'n CS fundamentals en algoritmen e.d. heb gedaan, dat de wat uitdagendere problemen me veel meer tijd kosten. Tijd die ik tegenwoordig gewoon niet meer (over) heb.

[ElkeBxl]

wackmaniac schreef op woensdag 22 oktober 2025 @ 08:58:
Als ik eerlijk ben dan is minder dagen wel lekker. Vanaf dag 14/15 wordt het toch altijd wel weer een behoorlijke opgave (pun intended).

Zelf ben ik ook tevreden met minder dagen.

topaz2078 zelf heeft ook antwoord gegeven op de vraag naar de complexiteit van de puzzels over de 12 dagen:

I'm still calibrating that. My hope right now is to have a more condensed version of the 25-day complexity curve, maybe skewed a little to the simpler direction in the middle of the curve? I'd still like something there for everyone, without outpacing beginners too quickly, if I can manage it.

[KabouterSuper]

wackmaniac schreef op woensdag 22 oktober 2025 @ 08:58:
https://www.reddit.com/r/adventofcode/s/X35Npb0xvT

tl/dr; het aantal dagen wordt teruggebracht tot 12 dagen - beginnend op 1 december -, en de global leaderboard verdwijnt.

Als ik eerlijk ben dan is minder dagen wel lekker. Vanaf dag 14/15 wordt het toch altijd wel weer een behoorlijke opgave (pun intended).

Het is nog niet duidelijk of de opgaven even moeilijk blijven, voor hetzelfde geld wordt dag 3 al een longest path probleem en dag 4 een intcode opgave. Ik ben in elk geval blij dat AoC niet helemaal stopt.

[P_Tingen]

Oh, heerlijk. Dit is de redding voor mij.

Ik zat er voor het eerst echt aan te denken om niet mee te doen. 25 dagen is voor mij echt te lang. Het moet er allemaal maar een beetje bij tussendoor en hoe verder in december hoe moeilijker ze worden en dus ook des te meer tijd ze kosten. Tel daarbij op dat ik het in een exotische taal doe samen met hooguit nog een stuk of 4 anderen. Ik kan - als ik echt vastloop - niet even spieken bij een ander hoe die het opgelost heeft.

De grootste lol voor mij zit er in om de puzzels op te lossen (uiteraard) maar daarna ook te kijken hoe mijn fellow-ontwikkelaars het probleem hebben opgelost. Er zijn vaak meerdere wegen die naar Rome leiden en ik vind het heerlijk om ook die wegen te kennen. Twaalf dagen geeft me net iets meer ademruimte

[marzman95]

Minder dagen is echt een positieve ontwikkeling. Ik ga in elk geval weer een poging wagen, het zal makkelijk worden zo om het bij te houden. Ik zal in C# gaan meedoen.

[MueR]

Ik vind het ook wel een positieve ontwikkeling. Ik haak meestal af ergens tussen dag 15 en 20, omdat ik mijn interesse verlies. En geen global leaderboard voor de LLM tryhards meer, yay!

[SPee]

Dag 15 is ook waarop ik vaak afhaak. Hoewel dat vorige jaar iets eerder was.
Maar ik denk dat het dit jaar niet lukt. Vorige jaren was het in december vrij rustig op mijn werk, maar ik ben straks druk bezig met een project. Maanden vrij rustig, maar nu start toch een nieuw opdracht met de vraag "dit jaar nog klaar?", omdat het budget van dit jaar gebruikt moet worden.

[.oisyn]

12 dagen is wel beter, wel weer jammer dat het alsnog 12 contiguous dagen zijn en niet om de dag oid . Dat zou ook wel goed kunnen werken door de 2e helft van elke puzzel gewoon een dag later pas open te gooien.

[ Voor 34% gewijzigd door .oisyn op 23-10-2025 01:26 ]

[Douweegbertje]

.oisyn schreef op donderdag 23 oktober 2025 @ 01:25:
12 dagen is wel beter, wel weer jammer dat het alsnog 12 contiguous dagen zijn en niet om de dag oid . Dat zou ook wel goed kunnen werken door de 2e helft van elke puzzel gewoon een dag later pas open te gooien.

Ja die vond ik ook apart, ik had graag een 'rust' dag tussen elke opdracht gezien. Nu blijft het toch eigenlijk 12 dagen knallen..

[ElkeBxl]

Iedereen klaar voor de AoC?

[MatHack]

Ik ga in ieder geval meelezen hier. Meedoen denk ik niet, want ik moet eigenlijk druk bezig met mijn masterscriptie

[.oisyn]

MatHack schreef op donderdag 27 november 2025 @ 12:28:
Ik ga in ieder geval meelezen hier. Meedoen denk ik niet, want ik moet eigenlijk druk bezig met mijn masterscriptie

Wat is nou belangrijker, een dom papiertje of een github repo waarin je daadwerkelijk je skills tentoonstelt

[ Voor 3% gewijzigd door .oisyn op 27-11-2025 12:36 ]

[Marcj]

Ik heb dit jaar alvast aangemaakt in mijn advent project.

Hopelijk vind ik de tijd om vlot met oplossingen te komen

[Soultaker]

Om in de stemming te komen plaats ik een voorbeeldopgave. Natuurlijk volstrekt optioneel.

Qua moeilijkheidsgraad denk ik dat het een probleem is dat je normaal gesproken ongeveer midden in de maand zou kunnen verwachten. Deel 1 moet voor iedereen te doen zijn.

Pre-AoC uitdaging 1: cadeautjes bezorgen

December komt er weer aan, en om zich voor te bereiden op de drukke kerstavond gaat de Kerstman oefenen met het uitdelen van cadeautjes. Daarvoor heeft hij de elfjes gevraagd om elk een stapel cadeautjes voor hun huis te zetten, die hij ter oefening gaat verdelen over de straat.

De aantallen worden gegeven als een lijst getallen gescheiden door spaties, bijvoorbeeld de invoer:

5 1 2 5

betekent dat er 4 huizen zijn, dat er 5 cadeautjes voor het eerste huis liggen, 1 voor het tweede huis, 2 voor het derde huis, en 5 voor het vierde huis.

De huizen staan in een straat die van het westen naar het oosten loopt, maar omdat die straat vlak bij de noordpool ligt, vormen de huizen een cirkel, zodat als je bij het laatste huisje doorloopt je weer bij het eerste huisje aankomt.

De Kerstman begint bij huisje 1. Daar pakt hij alle cadeautjes op die hij over de volgende huisjes verdeelt (1 per huisje). Dan pakt hij de cadeautjes bij het daaropvolgende huisje op, en die verdeelt hij op dezelfde manier. Dit gaat zo door tot hij met lege handen voor een huis staat waar geen cadeautjes meer zijn om op te pakken. Dan is de oefening voorbij.

Ter verduidelijking een voorbeeld. Neem weer de beginaantallen 5, 1, 2, 5. De Kerstman bevindt zich steeds op het getal tussen haakjes. Dan:

Stap  0:  (5-5)  1     2     5      pakt 5 cadeautjes op
Stap  1:   0    (1+1)  2     5      legt 1 cadeautje neer (4 over)
Stap  2:   0     2    (2+1)  5      legt 1 cadeautje neer (3 over)
Stap  3:   0     2     3    (5+1)   legt 1 cadeautje neer (2 over)
Stap  4:  (0+1)  2     3     6      legt 1 cadeautje neer (1 over)
Stap  5:   1    (2+1)  3     6      legt 1 cadeautje neer (0 over)
Stap  6:   1     3    (3-3)  6      pakt 3 cadeautjes op
Stap  7:   1     3     0    (6+1)   legt 1 cadeautje neer (2 over)
Stap  8:  (1+1)  3     0     7      legt 1 cadeautje neer (1 over)
Stap  9:   2    (3+1)  0     7      legt 1 cadeautje neer (0 over)
Stap 10:   2     4    (0)    7      klaar

In dit voorbeeld doet de Kerstman 10 stappen voordat hij klaar is.

De werkelijke invoer staat hier: https://pastebin.com/raw/uizP2wPt

Vraag 1: hoeveel stappen doet de Kerstman voordat hij met lege handen voor een huis zonder cadeautjes staat?

spoiler: antwoord 1

Antwoord 1 eindigt op: ..718

Deel 2

(voor het echte Advent of Code-gevoel pas openen nadat je deel 1 hebt opgelost!)

spoiler:

De elfjes hebben de instructies van de kerstman verkeerd begrepen. Ze zijn gewend om in tonnen cadeautjes te rekenen, en aangezien er precies 2025 cadeautjes in een standaard noordpoolton gaan, moet je elk getal in de invoer dus met 2025 vermenigvuldigen.

De voorbeeldinvoer (5 1 2 5) wordt dan: 10125 2025 4050 10125, en het aantal stappen is niet 10 maar 49715375.

Vraag 2: Hoeveel stappen doet de kerstman als je de getallen in de invoer met 2025 vermenigvuldigt?

spoiler: antwoord 2

Antwoord 2 eindigt op: ..674

[fruitschaal2]

@Soultaker Leuk dat je weer moeite stop t in het maken van (extra) opdrachten!

Ik gebruik python, eerste oplossing geschreven zonder gebruik van andere modules. Voor de tweede oplossing heb ik hetzelfde principe gebruikt maar deze keer met numpy. De tweede oplossing duurt ongeveer 47 seconde, ik vermoed dat er een andere manier zal zijn om deze puzzel op te lossen dan wat ik heb gedaan:

spoiler: oplossing

Ik heb gebruikt gemaakt van het feit dat als het aantal cadeautjes groter is dan de lengte van de straat, dat iedereen minimaal dat aantal krijgt. Daarna verdeel je de rest van de cadeaus:

https://pastebin.com/C7HAwnfh

Edit:
De oplossing in rust is onder de 4 seconde, maar precies hetzelfde principe:
https://pastebin.com/CBGcptfL

[ Voor 15% gewijzigd door fruitschaal2 op 28-11-2025 15:18 ]

[Bolukan]

spoiler:

Ik voel de mogelijkheid om een markov-state machine te maken met de mod 4 omvang van de stapels, en de 4 posities, (4x4)x4 is 64 states om te bepalen bij welk huis de kerstman met lege handen zal staan en die op te lossen.

[ Voor 5% gewijzigd door Bolukan op 28-11-2025 14:03 ]

[Soultaker]

fruitschaal2 schreef op vrijdag 28 november 2025 @ 11:21:

spoiler: oplossing

Ik heb gebruikt gemaakt van het feit dat als het aantal cadeautjes groter is dan de lengte van de straat, dat iedereen minimaal dat aantal krijgt. Daarna verdeel je de rest van de cadeaus:
https://pastebin.com/C7HAwnfh

spoiler:

Dit was één van de oplossingen die ik voorzien had, en het werkt natuurlijk, maar je kunt er nog een factor street_length uit halen als je slim bent. Mijn oplossing gebruikt geen numpy of ingewikkelde algoritmen of datastructuren.

[fruitschaal2]

Haha helaas ben ik dan niet slim (genoeg). Ben benieuwd naar jouw oplossing.

[Ghehe]

Was een leuke opdracht @Soultaker ! Mijn oplossing is niet echt snel voor deel 2 (enkele minuten) dus ik denk dat ik nog een simplificatie over het hoofd zie.

[Soultaker]

fruitschaal2 schreef op zaterdag 29 november 2025 @ 11:38:
Ben benieuwd naar jouw oplossing.

Ik zal 'm morgen posten (laatste dag voor de AoC begint).

[P_Tingen]

spoiler:

Heb nog geen tijd gehad om hem te maken maar ik gok dat je met deling door 4 kan bepalen hoeveel kado's er bij elk huisje bijkomen en dat je met MODULO kan bepalen waar je uitkomt

[Soultaker]

Oplossing voor het probleem dat ik hier postte:

spoiler:

Voor deel 1 kun je elke stap simuleren, zoals in het gegeven voorbeeld, wat iedereen zou moeten lukken. Voor de volledigheid een oplossing in Python: https://pastebin.com/tn1PbfTP

Het nadeel van die aanpak is dat de tijd die je nodig hebt proportioneel is aan het aantal stappen dat Santa zet, wat de som is van het aantal cadeautjes dat hij bij huizen oppakt. Bij deel 1 is het gemiddeld aantal cadeautjes dat Santa oppakt rond de 1000, maar in deel 2 is het 2025 keer zo groot, dus rond de 2025000 (~2 miljoen). Elk cadeautje afzonderlijk bezorgen is dan relatief traag.

@fruitschaal2 had al bedacht dat als het aantal cadeautjes dat je oppakt (c) groter is dan de lengte van de straat (n), dat je dan in één keer bij elk huis floor(c/n) cadeautjes kan bezorgen. Daarmee reduceer je de tijd van c naar n per pickup. Aangezien n=997 in de officiële invoer, wat aanzienlijk lager is dan c=~2 miljoen, helpt dat wel, maar het kan nog beter, namelijk in O(1) tijd per pickup.

Het cruciale inzicht is dat het aantal keer dat je de straat doorlopen hebt bepaalt hoeveel cadeautjes er bij elk huis achtergelaten zijn: namelijk 1 per keer, behalve als je voor het huis gestopt bent om cadeautjes op te pakken.

Je kunt het aantal cadeautjes voor het huidige huis berekenen als: (beginaantal) + (aantal keer dat Santa de straat doorlopen heeft) - (aantal keer dat Santa hier cadeautjes opgepakt heeft) - (totaal aantal cadeautjes dat Santa hier opgepakt heeft).

De laatste twee termen veranderen alleen wanneer Santa daadwerkelijk voor een huis stopt om cadeautjes op te pakken. Als je die termen in een array bijhoudt, hoef je die alleen maar te updaten wanneer je stopt bij een huis om cadeautjes op te pakken. Hoeveel cadeautjes er zijn achtergelaten hoef je dus niet expliciet bij te houden.

Python code: https://pastebin.com/xV7YhLj5
Javascript code: https://pastebin.com/7Ah0ZEbh

[Hagdos]

Bedankt! Ik was er net mee bezig; heb een oplossing die werkt in Python maar voor deel 2 echt veel tijd nodig heeft (De oplossing van @fruitschaal2 had ik er wel al in zitten, alleen zonder Numpy).

Ga het nog eens proberen met dat nieuwe inzicht. Mooie puzzel!

Edit: Gelukt; mijn code staat hier: https://pastebin.com/90dBMtxH. Draait in ~ 4 seconden voor beide delen.

[ Voor 16% gewijzigd door Hagdos op 30-11-2025 19:09 ]

[Soultaker]

Hagdos schreef op zondag 30 november 2025 @ 17:24:
Edit: Gelukt; mijn code staat hier: https://pastebin.com/90dBMtxH. Draait in ~ 4 seconden voor beide delen.

Pro-tip: met PyPy draait 'ie in 300 ms.

[Soultaker]

Vandaag niet al te ingewikkeld, wat natuurlijk niet zo gek is voor dag 1. Ik hoop wel dat komende dagen wat sneller moeilijker worden, nu we maar 12 dagen in totaal hebben.

Als extra uitdaging/benchmarkmateriaal hier wat extra testdata: aoc-2025-day-1-challenge-1.zip

Correcte antwoorden eindigen op:

spoiler:

...039
...493

[Eupeodes]

Mijn oplossing werkt als een trein op mijn officiële input (rond de 3 ms voor de totale oplossing (en op de voorbeelddata nog een factor 10 sneller)). Ook op deze extra input blijft ie ruim onder de seconde, maar voor deel 2 wel met een ander antwoord... daar ga ik vanmiddag verder naar kijken

[ Voor 5% gewijzigd door Eupeodes op 01-12-2025 07:59 ]

[eagle00789]

Ik zal dit jaar ook eens meedoen maar dan in powershell. kijken hoe ver ik kan komen. Mijn code zal ik hier posten: https://github.com/eagle00789/AoC2025

Dag 1 al gereed en geupload. Leuke challange. Vooral het rekening houden met het roteren en het passeren van de 0 op de juiste manier brak mijn hoofd wel eens.... maar het is gelukt.

[ Voor 37% gewijzigd door eagle00789 op 01-12-2025 08:33 ]

[bakkerjangert]

Leuke eerste opdracht. Niet al te moeilijk, maar ook niet te makkelijk.

spoiler:

Echter voor deel 2 kwam ik maar niet goed, bleek dat ik de dail niet naar de start positie had terug gezet

[Marcj]

Leuke start, op zich niet heel moeilijk. Al zat in deel 2 nog wel een edge-case waar ik niet aan had gedacht in eerste instantie. Duurde de implementatie toch langer dan ik dacht.

Soultaker schreef op maandag 1 december 2025 @ 06:59:
Vandaag niet al te ingewikkeld, wat natuurlijk niet zo gek is voor dag 1. Ik hoop wel dat komende dagen wat sneller moeilijker worden, nu we maar 12 dagen in totaal hebben.

Als extra uitdaging/benchmarkmateriaal hier wat extra testdata: aoc-2025-day-1-challenge-1.zip

Correcte antwoorden eindigen op:

spoiler:

...039
...493

Sneaky, hier zit nog een andere edge-case in voor mijn code. Maar hij klopt nu:

spoiler:

Executing
├── Input parsed in 14,470µs
├── Part 1 calculated in 5,242µs: ...039
├── Part 2 calculated in 6,085µs: ...493
└── Total time: 26,200µs

Ergens denk ik dat het ook branchless moet kunnen, maar daar heb ik vandaag geen tijd voor

[P_Tingen]

Dag 1 is traditioneel niet zo ingewikkeld, oplossing in Progress 4GL hier

[Basje]

Leuke start weer dit jaar! Oplossing in C#

spoiler:

Ben wel onnodig lang bezig geweest met deel 2, want blijkbaar is % in C# geen modulo maar de rest, dus "-18 % 100 == 82; // false". Had ik simpelweg niet verwacht.

[KabouterSuper]

Mooie opdracht om December te beginnen. Ik had vooral moeite om in te loggen (mentale notitie aan mezelf: stop met google accounts te gebruiken om in te loggen).

spoiler:

Ik had een beetje gehoopt/gedacht dat R0 en L0 in de data zouden zitten als edge case. Tuurlijk schuurt dat met het idee dat het een kluis is, maar dat houdt elfjes natuurlijk niet tegen om dat in de puzzel input te zetten.

[P_Tingen]

KabouterSuper schreef op maandag 1 december 2025 @ 10:32:

spoiler:

Ik had een beetje gehoopt/gedacht dat R0 en L0 in de data zouden zitten als edge case. Tuurlijk schuurt dat met het idee dat het een kluis is, maar dat houdt elfjes natuurlijk niet tegen om dat in de puzzel input te zetten.

spoiler:

Ik heb voor de zekerheid nog even gecheckt op negatieve nummers, just in case...

[Eupeodes]

Soultaker schreef op maandag 1 december 2025 @ 06:59:
Als extra uitdaging/benchmarkmateriaal hier wat extra testdata: aoc-2025-day-1-challenge-1.zip

zat nog een leuk dingetje in dat niet in het voorbeeld of mijn officiële input zat.

spoiler:

Ik kwam hierdoor dik 100 te hoog uit op deel twee

[Mugwump]

Simpel opdrachtje, duurde alleen nogal voordat ik het slordigheidje even uit deel 2 kon slopen, want ik word al de hele dag gestoord door collega's en meetings.
Laat me met rust, ik ben met belangrijke dingen bezig.

[Janoz]

Eupeodes schreef op maandag 1 december 2025 @ 11:12:
[...]

zat nog een leuk dingetje in dat niet in het voorbeeld of mijn officiële input zat.

spoiler:

Ik kwam hierdoor dik 100 te hoog uit op deel twee

Ik denk dat ik hetzelfde heb aangezien ik op ...598 uitkom

[fruitschaal2]

Ik ben dit jaar in Rust begonnen, erg leuke eerste opdracht.

spoiler:

Ik moest alleen wel even wennen aan de data type, in het voorbeeld van @Soultaker had ik blijkbaar niet genoeg aan een i32... Dat soort problemen had je niet bij een taal als python..
Goed leermoment, vast niet de eerste die tegen een overflow error aan loopt met dit soort problemen.

[Salandur]

Ik vond hem leuk. In deel 2 een tel bugje waardoor ik in eerste instantie te hoog uitkwam. Gelukkig snel op kunnen lossen.

[KabouterSuper]

Iemand bedacht om de kluis te spiegelen als je linksom moet draaien?

spoiler:

Zo omzeil je bij deel 2 het probleem dat je linksom iets anders moet doen dan rechtsom

[MueR]

In go was het zo gedaan. Voor de lol nog een poging gedaan in een andere taal... Meh, ik kom voor deel 2 7 te hoog uit op mijn attempt in Rockstar. Ergens mis ik wat, maar het is een vrij aparte taal

edit: en nu 3 te laag.. rage..

[ Voor 5% gewijzigd door MueR op 01-12-2025 23:29 ]

[.oisyn]

Te druk met Sinterklaas hier, ik vrees dat ik in het weekend een inhaalslag moet gaan maken

[ Voor 10% gewijzigd door .oisyn op 01-12-2025 23:31 ]

[MueR]

MueR schreef op maandag 1 december 2025 @ 22:20:
In go was het zo gedaan. Voor de lol nog een poging gedaan in een andere taal... Meh, ik kom voor deel 2 7 te hoog uit op mijn attempt in Rockstar. Ergens mis ik wat, maar het is een vrij aparte taal

edit: en nu 3 te laag.. rage..

Fixed it.

[jetspiking]

Leuke opdracht! De tweede helft moest ik wel toch even goed voor zitten, ik zat er in eerste instantie naast.

spoiler:

Ik had eigenlijk verwacht dat er nog een extra bestand met meer uitzonderingen gegeven zou worden. Ik had eigenlijk ook verwacht dat de start positie variabel zou worden of er nog extra offset toegevoegd zou worden.

Ik heb C# gebruikt:
https://github.com/jetspiking/Advent-of-Code

[Gropah]

Zat gisteren met een aantal off-by-one errors die mij te veel tijd hebben gekost. Die van vandaag vond ik eigenlijk wel makkelijk. Maar het scheelt hier nogal als je een taal gebruikt

spoiler:

die goede list functions heeft

[Janoz]

.oisyn schreef op maandag 1 december 2025 @ 23:31:
Te druk met Sinterklaas hier, ik vrees dat ik in het weekend een inhaalslag moet gaan maken

Pas maar op, dan zijn we al halverwege

Vandaag nog steeds relatief simpel. Ik was bang dat voor deel 2 een straight forward oplossing misschien langaam zou kunnen gaan worden, maar nadat ik gisteren de oplossing van Soultaker voor dag 1 gezien had dacht ik er maar gewoon voor te gaan en het bleek snel genoeg.

https://github.com/Janoz-NL/advent-of-code/blob/master/y2025/src/main/java/com/janoz/aoc/y2025/day2/Day2.java

[Mugwump]

Gropah schreef op dinsdag 2 december 2025 @ 07:09:
Zat gisteren met een aantal off-by-one errors die mij te veel tijd hebben gekost. Die van vandaag vond ik eigenlijk wel makkelijk. Maar het scheelt hier nogal als je een taal gebruikt

spoiler:

die goede list functions heeft

spoiler:

En fatsoenlijke ondersteuning voor ranges helpt ook wel.
Levert wat lelijke Int naar String casting op, maar performance is toch nog geen issue.

[Soultaker]

@MueR leuk om te zien dat er andere mensen met esoterische programmeertalen bezig zijn Rockstar kende ik nog niet.

Ik had dag 1 gisteren ook nog in Brainfuck opgelost.

Deel 1:

Brainfuck:

>>>+++++[->++++++++++<]>>>+<<<<<<,[+>+++++++[<----------->-],----------[>>[-]<[-
>+<]++++++[<------>-]<--[->+<],----------]>>[<++++++++++>-]<<<[[-]>>[<+>-]<<]>>[
<<++++++++++[->++++++++++<]>>[<->-]]<[->>+>[-[->+<]<[-]>]<[++++++++[->>+++++++++
++<<]]>>[<+>-]<<<<]>+>>[<+>-]<[<->[->+<]]<[->>>>>+<[->[<+>-]<[->+<[->+<[->+<[->+
<[->+<[->+<[->+<[->+<[->+<[->[-]>[-]>+<+<<]]]]]]]]]]+>>]<<[<<]<<]<<,]>>>>[-]>>[>
>]<<[+++++[->++++++++<]>.[-]<<<]++++++++++.

Deel 2:

Brainfuck:

>>>>+>>>+>+++++>>+<<<<<<<<<,[+>+++++++[<----------->-]+<[[-]>-<]>[->+>>>>>[>++++
++++++<[->-<]]>[<+>-]<<<<[>>>[->+<]+++++++++>[-<[-]>[<+>-]]<<<++++++++++<[->-<]]
>[<+>-]<<<<]>[<+>-],----------[-->>>[>>>]<<[-]+<[[->>>+<<<]<<<]>>>,----------]>>
>[>>>]<<<[[<+>-]++++++[<------>-]<<<]>[>[->+<]>[<+>-[<+>-[<+>-[<+>-[<+>-[<+>-[<+
>-[<+>-[<+>-[->[-]>+<+<<[-]>[<+>-]]]]]]]]]]]>]<<<[<<<]>[->>>>>>[>++++++++++<[->-
<]]>[<+>-]<<<<[>>>[->+<]+++++++++>[-<[-]>[<+>-]]<<<++++++++++<[->-<]]>[<+>-]<<<<
]<,]>>>->>>->>>[>>>]<<<[+++++[->++++++++<]>.[-]<<<<]++++++++++.

Vooral deel 2 is erg elegant al zeg ik het zelf, en werkt vrij efficiënt ook op grote invoer: er zit geen limiet op grootte van integers in de invoer of uitvoer. Mijn eigen challenge doet 'ie in 300 ms; de officiële testdata in 2 ms. Brainfuck ftw

Hier de conceptaanpak van deel 2 (in Python) en de iets minder slecht leesbare broncode: part1.bf, part2.bf.

[Hagdos]

Leuke vandaag! Eerst deel 1 gelezen, en onder de douche bedacht dat ik niet ging brute-forcen, maar

spoiler:

een mooie generator gemaakt die alle invalide getallen in een range genereert (Pak de eerste helft van het begingetal, doe die steeds +1 tot je aan de bovenkant van de range zit.)

Voor deel 2 even achter de oren gekrabt, getwijfeld om toch te gaan bruteforcen, maar toen een makkelijke manier gevonden om mijn deel 1 aan te passen. Toch nog even mee bezig geweest want ik ben geen programmeur van huis uit, dus ik Google dingen als "Hoe heet een set ook al weer" en "Hoe join ik twee sets".

[FCA]

De moeilijksheidgraad gaat wel omhoog met het dubbele tempo lijkt het (niet dat deze extreem moeilijk was)

spoiler:

Ik had brute-force (onterecht) gelijk afgeserveerd, en had bedacht om alle invalid_ids in een hashmap te gooien en dan daarover te itereren voor elke range. Snel genoeg voor deel 1 en 2.

Daarna heb ik nog gekeken of ik het verder kan optimaliseren. Met een binary search hoef ik niet over de hele lijst met invalids meer te itereren (en hoef ik ook geen hashset te maken, dat is altijd wat inefficient in Rust).
Ik ben benieuwd of er een snellere oplossing mogelijk is dan O(k * sqrt(n) + sqrt(n) * log(n)), waarbij n het hoogste ID is, en k het aantal ranges.

[P_Tingen]

Deel 2 rekent bij mij door in 9 sec. Dat moet vast sneller kunnen. Antwoord is overigens wel goed.

spoiler:

Wat ik doe is van elk getal binnen een range een string maken. Daar bepaal ik de lengte van en deel ik door 2, want groter dan de helft van de string kan een repeterend element niet zijn.
pseudo-code:

do i = 1 to (lengte / 2)
. numRepeats = lengte / i
. als numRepeats geen geheel getal is, dan skippen

. plak string(i) numRepeats keer aan elkaar en
. als dat gelijk is aan string(i) dan is het invalid
end

Oplossing hier in Progress 4GL. Kan natuurlijk zijn dat die gewoon erg traag is met strings

.
<rant>waarom werkt de 'code' tag niet in een spoiler? </rant>

[ Voor 6% gewijzigd door P_Tingen op 02-12-2025 09:38 ]

[bakkerjangert]

Leuke opgave vandaag. Deel 2 moest ik even over denken, maar heb ik uiteindelijk wel efficiënt opgelost denk ik.

Code in python.

[Janoz]

@bakkerjangert ik denk dat je repo nog op private staat

[bakkerjangert]

Janoz schreef op dinsdag 2 december 2025 @ 11:17:
@bakkerjangert ik denk dat je repo nog op private staat

Excuus, aangepast.

[fruitschaal2]

Leuke, maar toch ook nog wel lastige puzzel. Ook om even door te krijgen wat er precies gevraagd wordt. Leerzaam om weer nieuwe dingen in een taal te vinden. Ik heb geen slimmigheden gevonden om de oplossing te optimaliseren, maar gelukkig bleef het onder 1 seconde:

code:

puzzle 1 took: 158338 μs
puzzle 2 took: 814941 μs

https://topaz.github.io/p...VVncxWbJ4odZfRe3/yOBfQA==

[Soultaker]

Wat extra testdata voor dag 2: aoc-2025-day-2-challenge-1-to-6.zip en mijn antwoorden en tijden.

FCA schreef op dinsdag 2 december 2025 @ 08:51:

spoiler:

Ik ben benieuwd of er een snellere oplossing mogelijk is dan O(k * sqrt(n) + sqrt(n) * log(n)), waarbij n het hoogste ID is, en k het aantal ranges.

Ik doe deel 1 in O(k log n), en deel 2 in O(sqrt n + k log k) (of iets daar in de buurt).

[Mugwump]

fruitschaal2 schreef op dinsdag 2 december 2025 @ 11:34:
Leuke, maar toch ook nog wel lastige puzzel. Ook om even door te krijgen wat er precies gevraagd wordt. Leerzaam om weer nieuwe dingen in een taal te vinden. Ik heb geen slimmigheden gevonden om de oplossing te optimaliseren, maar gelukkig bleef het onder 1 seconde:

code:

puzzle 1 took: 158338 μs
puzzle 2 took: 814941 μs

https://topaz.github.io/p...VVncxWbJ4odZfRe3/yOBfQA==

Ik denk dat ik vandaag het meeste tijd kwijt was met de opgave lezen inderdaad

[Woy]

Ik heb beide dagen op lekker naive wijze opgelost ( Zal het vanavond even uploaden naar mijn repo ), dat is nu sowieso mijn instelling bij AoC, want heb meestal niet de tijd om heel erg te optimaliseren. Als het binnen (enkele) seconden opgelost wordt vindt ik het prima.

[Salandur]

Ik hou me nooit zo bezig met de snelheid, totdat het nodig is voor de oplossing. En die komt meestal wat later wel.

Vond het een interesante opgave vandaag.
https://github.com/jruijg...n/src/main/java/Day2.java
Zou het nog wat kunnen versnellen door virtual threads te gebruiken, wellicht voor een volgende puzzel

[Mugwump]

Performance ga ik ook pas naar kijken als het nodig is. Deel 2 van vandaag doet er bij mij een halve seconde over, maar werken met Strings is sowieso killing voor je performance. Oplossing in Kotlin ziet er dan zo uit:

spoiler:

private fun solve2(input: String) {
val result = input.split(",")
.map { it.split("-")[0].toLong()..it.split("-")[1].toLong() }
.flatten()
.filter { isRepeatedSequences(it.toString()) }
.sum()

println(result)
}

private fun isRepeatedSequences(i: String): Boolean {
return (1..<i.length).reversed()
.filter { it <= i.length / 2 && i.length % it == 0 }
.any { i.chunked(it).toSet().size == 1 }
}

[Woy]

Mugwump schreef op dinsdag 2 december 2025 @ 12:29:
Performance ga ik ook pas naar kijken als het nodig is. Deel 2 van vandaag doet er bij mij een halve seconde over, maar werken met Strings is sowieso killing voor je performance.

In C# probeer ik dan ook zo veel mogelijk allocatie vrij te werken en met (ReadOnly)Span<char>, dat kan inderdaad vrij veel performance schelen

[SPee]

Ik programmeer in VS Code. Maar nu die standaard AI intelligence heeft, kwam die dus al bijna automatisch met de oplossing. Dat maakt het een stuk minder leuk om de opdrachten te doen.

[Ulic]

Leuk weer een jaartje AoC meedoen Ik ben maar weer eens voor de challenge gegaan van een programmeertaal waar ik nog geen ervaring mee heb. Ik ben voor Rust gegaan. Dag 1 prima gelukt, op 1 typ foutje na dat me veel te veel tijd heeft gekost om te debuggen ( <= ipv < ). Vanavond of morgen dag 2 maar eens proberen.

[MueR]

Vandaag naast de go oplossing iets op de cli, nadat ik een collega hoorde over een regex.. het doet het nog verbazend goed.

code:

Part 1:
...689
real    0m0.887s
user    0m0.931s
sys     0m0.038s
Part 2:
...192
real    0m1.784s
user    0m1.824s
sys     0m0.037s

[FCA]

Soultaker schreef op dinsdag 2 december 2025 @ 11:44:
Wat extra testdata voor dag 2: aoc-2025-day-2-challenge-1-to-6.zip en mijn antwoorden en tijden.


[...]

Ik doe deel 1 in O(k log n), en deel 2 in O(sqrt n + k log k) (of iets daar in de buurt).

Knap. Ik heb nu ook iets dergelijks werkend voor deel 1, maar deel 2 nog niet

spoiler:

Ik moet nog op een slimme manier voor dubbele checken, bijv 111_111 en 11_11_11

Deel 1 is nu retesnel op de challenges (met een u128 output ), enkele milliseconden voor challenge 4.

[acemoo]

Heeft iemand anders zich hier nog geïrriteerd aan deze text voor vandaag?

None of the numbers have leading zeroes; 0101 isn't an ID at all. (101 is a valid ID that you would ignore.)

Ik vertaal dit naar "als er een leading zero is, haal die dan weg.
Maar deze hele text is totaal irrelevant gezien de input die je krijgt.

[Reptile209]

acemoo schreef op dinsdag 2 december 2025 @ 19:45:
Heeft iemand anders zich hier nog geïrriteerd aan deze text voor vandaag?

[...]

Ik vertaal dit naar "als er een leading zero is, haal die dan weg.
Maar deze hele text is totaal irrelevant gezien de input die je krijgt.

Is niet relevant als je met strings wil gaan werken. Maar als je de input puur als getallen gaat verwerken, is het wel nuttig om te weten of "001001" zou kunnen bestaan. Maar zoals je zegt: het zit sowieso al niet in de input, maar het kan maar duidelijk zijn. Of wat ruis om je op het verkeerde been te zetten

[Soultaker]

FCA schreef op dinsdag 2 december 2025 @ 18:41:

spoiler:

Ik moet nog op een slimme manier voor dubbele checken, bijv 111_111 en 11_11_11

Ja, daar liep ik ook op vast. Ik dacht in eerste instantie dat de aanpak van deel 1 uit te breiden was naar deel 2, maar ik kon geen goede manier bedenken om dubbeltellen te voorkomen. En toen ik het een beetje probeerde te researchen eindigde ik met de Wikipedia pagina's over necklace polynomials en Möbius functies open en dacht ik: dit wordt me (véél) te ingewikkeld

MueR schreef op dinsdag 2 december 2025 @ 16:43:
Vandaag naast de go oplossing iets op de cli

Nice! Zit wel een bugje in: ^([0-9])\1+$ moet ^([0-9]+)\1$ zijn in deel 1, of gewoon ^(.+)\1$ maar dat maakt voor het resultaat niet uit.

[MueR]

Soultaker schreef op dinsdag 2 december 2025 @ 22:41:
Nice! Zit wel een bugje in: ^([0-9])\1+$ moet ^([0-9]+)\1$ zijn in deel 1, of gewoon ^(.+)\1$ maar dat maakt voor het resultaat niet uit.

Whelp, nice spot!

[Corniel]

Gisteren liep ik enorm te k#tten. Vandaar ging het wel. Ik heb geen regex gebruikt, maar 'simpele' loopjes. Het valt me wel op dat bij velen deel twee relatief veel trager is, terwijl het bij mij maar 34% is. Wellicht een verstandige early exit gekozen?!

code:

2025-02-1:  22.23 ms
2025-02-2:  29.86 ms

[Reptile209]

Soultaker schreef op dinsdag 2 december 2025 @ 22:41:
[...]

Ja, daar liep ik ook op vast. Ik dacht in eerste instantie dat de aanpak van deel 1 uit te breiden was naar deel 2, maar ik kon geen goede manier bedenken om dubbeltellen te voorkomen. En toen ik het een beetje probeerde te researchen eindigde ik met de Wikipedia pagina's over necklace polynomials en Möbius functies open en dacht ik: dit wordt me (véél) te ingewikkeld


[...]

Nice! Zit wel een bugje in: ^([0-9])\1+$ moet ^([0-9]+)\1$ zijn in deel 1, of gewoon ^(.+)\1$ maar dat maakt voor het resultaat niet uit.

spoiler:

Ik had een for-loopje om de string in delen te hakken met lengte 1 tm (len/2) en dan te checken op een match. Bij een match jump ik uit die loop en hoef ik de rest dus niet meer te tellen (of door te rekenen)

[Soultaker]

Ik was snel klaar vandaag, maar ik vermoed dat veel mensen deel 2 lastig zullen vinden.

spoiler: dag 3 deel 2

Wikipedia: Dynamic programming

[bakkerjangert]

Ik was snel klaar vandaag. Met de juiste gedachte gang heb ik ik met een simpel for-loopje kunnen oplossen. Code in python

spoiler:

Voor elke batterij zoek ik het grootste nummer in de beschikbare range, waarbij er aan het einde van de reeks er voldoende over moeten zijn om de resterende batterijen toe te voegen. Dit werkt omdat ik van links naar rechts werk en 9xxx altijd groter is dan bv 8xxx. Daarna pas ik de startindex aan naar het eerst gevonden grootste getal in de beschikbare range.

[FCA]

Ah, soms heb je dat

spoiler:

dat je oplossing voor deel 1 in een for loop je oplossing voor deel 2 is

[Soultaker]

Over dag 2 schreef ik gisteren:

Soultaker schreef op dinsdag 2 december 2025 @ 22:41:
Ik dacht in eerste instantie dat de aanpak van deel 1 uit te breiden was naar deel 2, maar ik kon geen goede manier bedenken om dubbeltellen te voorkomen. En toen ik het een beetje probeerde te researchen eindigde ik met de Wikipedia pagina's over necklace polynomials en Möbius functies open en dacht ik: dit wordt me (véél) te ingewikkeld

Maar nu zie ik op reddit dat iemand dat toch werkend heeft gekregen, inderdaad met gebruik van de Möbius functie: https://old.reddit.com/r/...uld_be_easy_right_closed/

Het kon dus toch!

[FCA]

Soultaker schreef op woensdag 3 december 2025 @ 07:09:
Over dag 2 schreef ik gisteren:


[...]

Maar nu zie ik op reddit dat iemand dat toch werkend heeft gekregen, inderdaad met gebruik van de Möbius functie: https://old.reddit.com/r/...uld_be_easy_right_closed/

Het kon dus toch!

Dag 13 zullen we maar zeggen. Ik heb iets in mijn hoofd, misschien wel mobius functie stiekem (heb maar een vage herinnering aan wat dat ook al weer was volgens mij van Project Euler).

[Mugwump]

Soultaker schreef op woensdag 3 december 2025 @ 06:12:
Ik was snel klaar vandaag, maar ik vermoed dat veel mensen deel 2 lastig zullen vinden.

spoiler: dag 3 deel 2

Wikipedia: Dynamic programming

spoiler:

Ik begin doorgaans met de meest naïve implementatie met loopjes en ga dan wel kijken hoeveel optimalisatie ik nodig heb als ik tijd heb. Zonder dynamic programming is het dan gewoon zoiets:



Aangezien dat 7.5ms nodig had vond ik het wel goed genoeg voor vandaag aangezien ik ook wel ander werk heb liggen.

[Marcj]

Vandaag vond ik vrij makkelijk. Het algoritme dat ik voor deel 1 had verzonnen kon ik vrij makkelijk generaliseren naar hogere getallen. Dat krijg je dus dit in Rust. Hij runt in ongeveer 1 milliseconde, dus heb het eigenlijk veel moeilijker gemaakt dan nodig.

Gisteren ook al, ben dan wat langer bezig om het met getallen te doen in plaats van met strings. Dat is wel veel sneller, maar ook lastiger te implementeren. Vervolgens blijkt dat het probleem klein genoeg is dat een simpele grep het als string kan oplossen. Voelt dat een beetje overbodig hoe complex ik mijn oplossing heb gemaakt.

[Soultaker]

Mugwump schreef op woensdag 3 december 2025 @ 08:56:

spoiler:

Ik begin doorgaans met de meest naïve implementatie met loopjes en ga dan wel kijken hoeveel optimalisatie ik nodig heb als ik tijd heb. Zonder dynamic programming is het dan gewoon zoiets:

Dit was de (greedy) methode die @bakkerjangert ook noemde. Dat werkt inderdaad ook prima, zou zelfs iets sneller kunnen zijn in de praktijk.

Die draait in O(nk) tijd waarbij n de lengte van de invoerregel is, en k het aantal cijfers dat je eruit haalt (k=2 in deel 1, k=12 bij deel 2). Dat is hetzelfde als de DP-oplossing.

edit:
Overigens kan het ook in O(n) tijd, ongeacht de waarde van k óf het aantal cijfers.

[ Voor 6% gewijzigd door Soultaker op 03-12-2025 09:59 ]

[Ulic]

Dag 2 deel 2 net ook kunnen oplossen. Maar mijn laptop loopt er wel 5 minuten op te stampen Dat moet beter kunnen. Maar eerst maar eens dag 3 proberen, dan ga ik daarna wel verder naar de performance van dag 2 kijken.

[fruitschaal2]

@Marcj leuk om jouw oplossing te zien. Ik ben zelf ook begonnen in Rust dit jaar, erg leerzaam om dit soort "simpele" problemen op te lossen. Daarom juist leuk om te zien hoe anderen dit aanpakken.

Dit is mijn oplossing: https://topaz.github.io/p...2sJnFKidV6TjxzsgD//u3xgM=

Met de timings (spoiler is misschien niet nodig omdat het resultaten van mijn eigen input zijn, maar voor de zekerheid):

spoiler:

Advent Of Code day 3
Reading data took: 98 μs
puzzle 1 took: 59 μs
puzzle 1: 17113
puzzle 2 took: 157 μs
puzzle 2: 169709990062889

[P_Tingen]

Deel 1 was appeltje, eitje, al deed die er met mijn rechttoe-rechtaan oplossing toch nog een paar seconden over. Bij deel 2 kwam ik natuurlijk in de problemen. Dat had ik ook wel verwacht, maar ik doe al geen aannames meer over hoe deel 2 eruit gaat zien. Maar goed ook, want ik had iets heel anders verwacht.

Dus back to the drawing table en daar kwam ik bijna uit. Zat klem op één extra voorwaarde in mijn code waardoor ik steeds array subscripts out of range kreeg. Met wat hulp van Perplexity vond ik die alsnog. Daarna de code herschreven om te werken met "gewone" strings ipv een array als stack om te zien of dat nou echt veel vertraagt. Viel me nog mee. Beide delen draaien nu in 120ms

zie https://github.com/patric...ter/2025/Day-03/day-03b.p (Progress 4GL)

[Soultaker]

P_Tingen schreef op woensdag 3 december 2025 @ 11:53:
Dus back to the drawing table en daar kwam ik bijna uit. Zat klem op één extra voorwaarde in mijn code waardoor ik steeds array subscripts out of range kreeg. Met wat hulp van Perplexity vond ik die alsnog. Daarna de code herschreven om te werken met "gewone" strings ipv een array als stack om te zien of dat nou echt veel vertraagt. Viel me nog mee. Beide delen draaien nu in 120ms

zie https://github.com/patric...ter/2025/Day-03/day-03b.p (Progress 4GL)

Qua algoritme erg netjes. Had je dat zelf bedacht of kwam dat ook van Perplexity?

Over de programmeertaal zelf kan ik beter m'n mond houden

[Daanoz]

Gisteren drukke dag, dus kon 's avonds laat pas de opdracht doen. Nog geprobeerd te optimaliseren, maar zag de oplossing compleet niet. Vandaag met een frisse blik was het zo geregeld:

code:

Day 2
time: 687.17µs (1: 103.88µs, 2: 583.29µs)

Dag 3 was best prima, maar misschien ook een beter moment op de dag om het te proberen

[P_Tingen]

Soultaker schreef op woensdag 3 december 2025 @ 12:09:
[...]
Qua algoritme erg netjes. Had je dat zelf bedacht of kwam dat ook van Perplexity?

Tbh geen van beide, ik had zelf redelijk beredeneerd hoe ik het aan ging pakken maar miste een paar stappen. Vervolgens gaan zoeken en op reddit een paar hints gevonden waar ik mee verder kon. Uiteindelijk vast op een extra check die Perplexity vond.

Als test heb ik de opgave trouwens ook eens in zijn geheel in Perplexity gegooid om te zien wat die ervan maakte, maar dat leverde in eerste instantie geen goede oplossing. Pas toen ik hem (het?) de goede uitkomst erbij gaf, kon hij zelf een testcase maken kennelijk en klopte het wel. De code was alleen veel "wolliger", wat ik nog niet zo gek vind met een nichetaal als de Progress 4GL. Vind het eigenlijk al knap dat er überhaupt iets werkbaars uitkomt

Over de programmeertaal zelf kan ik beter m'n mond houden

Nou ja zeg!
Het is een prima taal voor waar het voor bedoeld is, nml administratieve toepassingen obv een Progress database. Dat is precies de reden waarom ik met AoC meedoe in die 4GL, namelijk omdat het daar eigenlijk voor de meeste opgaven helemaal niet voor geschikt is

[Woy]

Dag 3 was redelijk eenvoudig. Part2 zal vast niet helemaal optimaal zijn, maar wel gewoon een nette oplossing die meer dan snel genoeg is.

https://github.com/rversteeg/AoC2025/blob/main/AdventOfCode/Day03.cs

[Soultaker]

P_Tingen schreef op woensdag 3 december 2025 @ 13:41:
Tbh geen van beide, ik had zelf redelijk beredeneerd hoe ik het aan ging pakken maar miste een paar stappen. Vervolgens gaan zoeken en op reddit een paar hints gevonden waar ik mee verder kon. Uiteindelijk vast op een extra check die Perplexity vond.

Aha. Hoe dan ook een een leuke variant. Ik vind het interessant op hoeveel verschillende manieren dit probleem opgelost kan worden. Ik heb nu een stuk of 4 varianten voorbij zien komen, waarvan de versie met een stack nog wel de meest elegante is.

Vind het eigenlijk al knap dat er überhaupt iets werkbaars uitkomt.

LLM's zijn relatief goed in “vertalen”, dat helpt waarschijnlijk, zelfs als de trainingsdata beperkt is.

[HannoOttens]

Deze dag zag ik de bui gelukkig al aankomen en kon ik deel a schrijven op een manier die makkelijk uit te breiden was voor deel b.

https://github.com/HannoO...master/2025/day03/main.go

spoiler:

Ik neem eerste de laatste 12 batterijen in een pack. Vanaf de 13e zoek ik naar links. Als ik een getal tegen kom wat net zo groot of groter als de hoogste dan vervang ik de hoogste daarmee en schuif ik de rest door.

[kahraman11]

Ik heb voor challenge 2 van dag 3 (vandaag dus) gebruik gemaakt van recursion. Programmeren is niet mijn dagelijkse vak, dus het is niet het meest mooie code maar het werkt:

spoiler: python recursion

[code]def find_highest_number(remaining_list, numbers_left, combination):
if numbers_left == 0:
return combination

highest_number = 0

for i in range(len(remaining_list) - numbers_left + 1):
number = int(remaining_list[i])
if number > highest_number:
highest_number = number

for i in range(len(remaining_list) - numbers_left + 1):
number = int(remaining_list[i])
if number == highest_number:
return find_highest_number(remaining_list[i+1:], numbers_left - 1, combination + str(number))

count = 0
with open("input.txt") as file:
numbers_left = 12
for line in file:
l = line.replace("\n", "")
result = find_highest_number(l, 12, "")
print(result)
count += int(result)

print(count)
[/code]

[Vloris]

Nadat ik vandaag (dag 3) een naïeve oplossing voor deel 1 geschreven had dacht ik voor deel 2 direct "hej, dit ziet er heel goed recursief oplosbaar uit".
Dat werkte perfect, alleen wat traag voor de echte input (geen idee hoe traag, niet op gewacht), dus toen me ook maar eens ingelezen in 'memoization' of caching van tussenresultaten tijdens de recursie. Dat werkte echt perfect.

130ms voor deel 1 + deel 2 (ik verwacht eigenlijk dat de memoization van deel 1 ervoor zorgt dat de cache van deel 2 al deels gevuld is) -- https://github.com/floris...ob/main/src/days/day03.ts

[KabouterSuper]

Aangezien de meesten klaar zijn hier mijn compact python oplossing (denk de indents er zelf bij, daar zijn spoiler-tags niet zo goed in)

spoiler:

for part,ssum in (1,0), (2,0):
for d in [d for d in open('day 03 input.txt').read().split('\n') if d!='']:
s,ans,L=0,'',-8+10*part
for end in range(L-1,-1,-1):
m,snew=max(d[s:len(d)-end]),d[s:-end].find(max(d[s:len(d)-end]))
ans,s=ans+m,s+snew+1
ssum+=int(ans)
print(part,ssum)

[ Voor 7% gewijzigd door KabouterSuper op 03-12-2025 20:50 ]

[.oisyn]

We hadden vandaag een copilot workshop. Ik had in Visual Studio in agent mode voor de grap gewoon ingetypt: "Hier is een opdracht: <link naar AoC dag 1>. Implementeer het in C++."

Ik heb de vraag gelezen noch de geproduceerde code bestudeerd. Gewoon gecompiled, gerund en het goede antwoord kwam eruit

[ Voor 3% gewijzigd door .oisyn op 03-12-2025 21:16 ]

[Ghehe]

KabouterSuper schreef op woensdag 3 december 2025 @ 20:50:
Aangezien de meesten klaar zijn hier mijn compact python oplossing (denk de indents er zelf bij, daar zijn spoiler-tags niet zo goed in)

spoiler:

for part,ssum in (1,0), (2,0):
for d in [d for d in open('day 03 input.txt').read().split('\n') if d!='']:
s,ans,L=0,'',-8+10*part
for end in range(L-1,-1,-1):
m,snew=max(d[s:len(d)-end]),d[s:-end].find(max(d[s:len(d)-end]))
ans,s=ans+m,s+snew+1
ssum+=int(ans)
print(part,ssum)

Die "-8+10*part" is wel netjes gevonden, dat had ik zelf niet bedacht.