Advent Of Code 2025

[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 compacte 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 04-12-2025 08:01 ]

[.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.

[Mugwump]

Leuk, een gridpuzzeltje.

spoiler:

Vreesde bij deel 2 even dat ik wat slimme zaken moest gaan doen om performanceredenen, maar ook hier was brute forcen gewoon weer millisecondenwerk.

[FCA]

Ik moest vandaag denken aan YouTube: Te weinig wc-papier? Heftruckchauffeur stelt Nederland gerust!

spoiler:

kon de parsing en wat logica van dag 4 van vorig jaar kopieëren. Zometeen toch even kijken wat dag 5 van vorig jaar ook alweer was. En inderdaad, voor deel 2 was het een for loopje en een update stap, 2ms en klaar.

[Soultaker]

Weer niet zo moeilijk vandaag; ik was in 4 minuten en 13 seconden klaar, wat nog sneller was dan gisteren

Hier wat extra testdata voor dag 4: aoc-2025-day-4-challenge-1-to-3.zip

Referentieantwoorden en tijden:

aoc-2025-day-4-challenge-1.txt
...65
...02

real    0m0.212s
user    0m0.168s
sys     0m0.036s

aoc-2025-day-4-challenge-2.txt
...65
...72

real    0m1.544s
user    0m1.322s
sys     0m0.213s

aoc-2025-day-4-challenge-3.txt
...04
...04

real    0m0.166s
user    0m0.140s
sys     0m0.024s

[KabouterSuper]

Ghehe schreef op woensdag 3 december 2025 @ 23:25:
[...]
Die "-8+10*part" is wel netjes gevonden, dat had ik zelf niet bedacht.

Ach, komt die 8 jaar studie/phd wiskunde toch nog een keer van pas.

Ik zag trouwens tot mijn schrik dat er dit jaar maar 24 punten te verdienen zijn, geen 25. Tot zover de mooie ronde getallen in mijn totaal aantal sterren

[Hagdos]

KabouterSuper schreef op donderdag 4 december 2025 @ 08:12:
Ik zag trouwens tot mijn schrik dat er dit jaar maar 24 punten te verdienen zijn, geen 25. Tot zover de mooie ronde getallen in mijn totaal aantal sterren

Nog twee nachtjes slapen, en dan sta ik op 512! Dat is pas een mooi rond getal!

[Friits]

@KabouterSuper: Ik hoop dat dag 12 deel 2 dit jaar een "echte" opdracht is, en we daarna pas de gebruikelijke bonusster krijgen.

Hier mijn oplossing voor vandaag, waar ik een eenvoudige

spoiler:

convolutie

gebruik om het grid te updaten.

[KabouterSuper]

Hagdos schreef op donderdag 4 december 2025 @ 08:23:
[...]
Nog twee nachtjes slapen, en dan sta ik op 512! Dat is pas een mooi rond getal!

Had ik ook bedacht, aantrekkelijk als je ocd hebt. En dan wachten tot 2045 om in één keer naar 1000 te gaan (en in 2046 naar 1024).

[KabouterSuper]

Friits schreef op donderdag 4 december 2025 @ 08:23:
@KabouterSuper: Ik hoop dat dag 12 deel 2 dit jaar een "echte" opdracht is, en we daarna pas de gebruikelijke bonusster krijgen.

Hier mijn oplossing voor vandaag, waar ik een eenvoudige

spoiler:

convolutie

gebruik om het grid te updaten.

Heel netjes! Heb ik ook aan gedacht. Ik twijfel(de) wat de convolutie doet voor het middelpunt, maar 'same' doet blijkbaar precies wat je wil.

[Soultaker]

Friits schreef op donderdag 4 december 2025 @ 08:23:
@KabouterSuper: Ik hoop dat dag 12 deel 2 dit jaar een "echte" opdracht is, en we daarna pas de gebruikelijke bonusster krijgen.

Dat zou een leuke manier zijn om op 25 sterren te komen, maar volgens de events pagina zijn er maar 24 sterren in totaal, dus ik denk niet dat het zo werkt.

[P_Tingen]

Friits schreef op donderdag 4 december 2025 @ 08:23:
@KabouterSuper: Ik hoop dat dag 12 deel 2 dit jaar een "echte" opdracht is, en we daarna pas de gebruikelijke bonusster krijgen.

Hier mijn oplossing voor vandaag, waar ik een eenvoudige

spoiler:

convolutie

gebruik om het grid te updaten.

Wow, bizar korte oplossing! Ik had zelf iets meer regels nodig, al zijn de eerste 100 regels een standaard programma dat ik klaar heb staan in mijn map met AoC-snippets

[Hagdos]

Soultaker schreef op donderdag 4 december 2025 @ 09:03:

Dat zou een leuke manier zijn om op 25 sterren te komen, maar volgens de events pagina zijn er maar 24 sterren in totaal, dus ik denk niet dat het zo werkt.

Ik blijf een beetje hopen. Na 24 dagen en op kerstochtend was het wel fijn om een "makkelijke" laatste ster te hebben. Na 11 dagen en halverwege december wil ik best nog wel een laatste uitdaging.

[Woy]

Ik heb een lekker naive implementatie gedaan, ik had verwacht dat dat niet snel zou werken, maar het had er geen enkele moeite mee ( 122 ms in een debug build, dus ik ga geen moeite meer stoppen in verbeteren )

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

[ Voor 11% gewijzigd door Woy op 04-12-2025 11:09 ]

[fruitschaal2]

Hier ook de meest eenvoudige oplossing. Dit was snel genoeg voor de normale input, dus geen optimalisaties verder.

De extra grote input komt er uiteindelijk wel doorheen, maar bij de laatste duurt wel wel bijna 20 seconde...

https://topaz.github.io/p...0GeKH7nxtopUil4SPZv/01tHX

[Soultaker]

Toch is er een simpele manier om het in O(n) op te lossen. (b.v. mijn Python code).

Overigens had ik ook nog bedacht dat je het probleem kunt zien als

spoiler: dag 4

een cellular automaton.

Bijvoorbeeld met golly:

% bgolly -2 -r B/S45678 sample.txt
0: 71
1: 58
2: 46
4: 34
8: 29
16: 28
32: 28
64: 28

De uitvoer is het aantal cellen dat over is per generatie. Dus 71 in het begin en 58 na 1 iteratie, betekent dat 71-58=13 het antwoord is van deel 1, en aangezien het aantal cellen stabiliseert op 28, is 71-28 = 43 het antwoord voor deel 2. Hetzelfde werkt voor de officiële testinvoer.

Het grappige is dat golly blijkbaar het invoerbestand correct interpreteert, wat ik niet verwacht had.

Het argument "B/S45678" beschrijft de evolutieregel die gebruikt wordt: Bxxx beschrijft het aantal buren dat een cel moet hebben om geboren te worden (B=birth), Sxxx beschrijft het aantal buren dat een cel moet hebben om te overleven (S=survive). Bij Conway's Game of Life is de regel "B2/S23", en bij dit probleem worden cellen nooit geboren en sterven ze wanneer minder dan 4 buren hebben, vandaar dus "B/S45678".

Zo kun je het probleem dus oplossen zonder maar 1 regel code te schrijven.

[Camulos]

Tot nu toe leuke opdrachten! Meeste kan nog steeds met brute force

Ik ben vooral met C# nu de File Based Apps aan het uitproberen (oftewel 1 bestand, geen project, en direct uitvoeren alsof het een script is!), nieuwe feature in C#14/.NET10 => Dag 3 / Dag 4

[MueR]

Vandaag was easy enough, zeker met alle tools die ik in de jaren al ontwikkeld had voor dit soort grid dingen.

Voor de gein maar eens een visualisatie er bij gemaakt. En m'n pogingen in andere talen (vandaag Kotlin) maar eens in een repo gemikt: https://github.com/MueR/advent-of-experiments-2025

[Janoz]

Vandaag maakte deel 2 mijn deel 1 een stuk efficienter . Alles draait in 17ms. Ik merk wel dat mijn kennis van mijn eigen library altijd wat roestig is aan het begin omdat ik hem altijd maar 1x peer jaar gebruik ;D. Misschien toch maar eens wat meer documentatie toevoegen

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

[Soultaker]

Het valt me op dat na het insturen van een oplossing het leaderboard soms minutenlang niet updatet (b.v. dan ben ik al lang klaar maar heb ik op het leaderboard nog maar 1 zilveren ster). Hebben andere mensen daar ook last van? Het voegt wel wat spanning toe 's ochtends, maar het is wel een beetje vreemd, alsof er ergens een cache niet wordt geüpdatet.

Anyway, dag 5 heb ik voor de grap nog eens opgelost als een shell script.

$ solve.sh sample
Part 1: 3
Part 2: 14

Performance is prima:

$ time solve.sh input.txt 
Part 1: ..6
Part 2: ...043

real    0m0.054s
user    0m0.041s
sys     0m0.009s

[FCA]

spoiler:

Niet heel moeilijk vandaag, standaard range merging voor deel 2, maar ik had een stomme denkfout en een off-by-one fout, die allebei geen invloed hadden op de test invoer/uitvoer dus dat was even lichte paniek. Uiteindelijk in de 5 minuten verplichte timeout (te vaak incorrect gesubmit) het foutje gevonden.

Wel blij dat ik een parsing library van vorig jaar heb gemaakt, dat scheelt wel wat tijd nu.

[FCA]

Soultaker schreef op vrijdag 5 december 2025 @ 07:53:
Het valt me op dat na het insturen van een oplossing het leaderboard soms minutenlang niet updatet (b.v. dan ben ik al lang klaar maar heb ik op het leaderboard nog maar 1 zilveren ster). Hebben andere mensen daar ook last van? Het voegt wel wat spanning toe 's ochtends, maar het is wel een beetje vreemd, alsof er ergens een cache niet wordt geüpdatet.

....

Ja, en het is anders per leaderboard. Ik zie soms dat ik in 1 leaderboard al 2 sterren voor die dag heb, en de andere pas een paar minuten later wordt geupdate.

[Eupeodes]

part 1 had ik zo af, part 2 liep ik toch wel tegen een aantal probleempjes aan

spoiler:

Mijn eerste oplossing gaf een MemoryError, mijn tweede oplossing ging aanvankelijk de mist in met overlap

[Gropah]

Vond vandaag vrij makkelijk. Deel 1 was redelijk straight forward. Deel 2 eerst geprobeerd te bruteforcen, want nee heb je en ja kun je krijgen. Maar het eerste meest straightforward idee daarna werkte meteen zonder al te veel sjoege, namelijk door

spoiler:

overlap te dedupliceren

[Soultaker]

Extra test data voor dag 5: aoc-2025-day-5-challenge-1.zip
Hier zit een edge case in die wel in de voorbeelddata zit maar niet in de officiële data. Ben benieuwd of mensen hier nog de mist in gaan. Antwoorden:

$ time pypy3 05.py < aoc-2025-day-5-challenge-1.txt 
...50
...4022

real    0m0.373s
user    0m0.330s
sys     0m0.040s

edit:
M'n shell script doet het in 5 seconden; niet slecht

[ Voor 7% gewijzigd door Soultaker op 05-12-2025 09:14 ]

[Eupeodes]

Soultaker schreef op vrijdag 5 december 2025 @ 08:44:
Extra test data voor dag 5: aoc-2025-day-5-challenge-1.zip
Hier zit een edge case in die wel in de voorbeelddata zit maar niet in de officiële data. Ben benieuwd of mensen hier nog de mist in gaan. Antwoorden:

$ time pypy3 05.py < aoc-2025-day-5-challenge-1.txt 
...50
...4022

real    0m0.373s
user    0m0.330s
sys     0m0.040s

ik geloof dat mijn deel 1 nog wat optimalisatie kan gebruiken, dik 5 minuten rekentijd, deel 2 was maar 200ms. Verder ben ik, ondanks de dikke mist buiten, niet de mist in gegaan met deze input (op zich ook niet gek, want ik schrijf en test mijn code op de voorbeeldinput en pas als het antwoord daarop klopt laat ik mijn code los op de echte input)

[ Voor 14% gewijzigd door Eupeodes op 05-12-2025 09:01 ]

[Woy]

Vandaag was vrij makkelijk:

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

Deel 2 was wat mij betreft nog makkelijker dan deel 1, die is bij mij ook sneller dan deel 1, nou zou deel 1 ook zeker sneller kunnen door

spoiler:

Ook daar te sorteren, maar het is al snel genoeg.

[ Voor 25% gewijzigd door Woy op 05-12-2025 10:12 ]

[KabouterSuper]

Soultaker schreef op vrijdag 5 december 2025 @ 08:44:
Extra test data voor dag 5: aoc-2025-day-5-challenge-1.zip
Hier zit een edge case in die wel in de voorbeelddata zit maar niet in de officiële data. Ben benieuwd of mensen hier nog de mist in gaan. Antwoorden:

$ time pypy3 05.py < aoc-2025-day-5-challenge-1.txt 
...50
...4022

real    0m0.373s
user    0m0.330s
sys     0m0.040s

edit:
M'n shell script doet het in 5 seconden; niet slecht

Met pypy haal ik deel 1 in 240s en deel 2 in 0.013. Ik moest even de edge-cases checken (ik had wel een vermoeden wat er in de data kon zitten), en moest een hele kleine aanpassing doen.

[Woy]

Soultaker schreef op vrijdag 5 december 2025 @ 08:44:
Extra test data voor dag 5: aoc-2025-day-5-challenge-1.zip
Hier zit een edge case in die wel in de voorbeelddata zit maar niet in de officiële data. Ben benieuwd of mensen hier nog de mist in gaan. Antwoorden:

$ time pypy3 05.py < aoc-2025-day-5-challenge-1.txt 
...50
...4022

real    0m0.373s
user    0m0.330s
sys     0m0.040s

edit:
M'n shell script doet het in 5 seconden; niet slecht

Part2 komt direct uit mijn oplossing, Part 1 zou ik mijn code moeten optimaliseren met mijn suggestie die ik hierboven doe.

[Hagdos]

Soultaker schreef op vrijdag 5 december 2025 @ 08:44:
Extra test data voor dag 5: aoc-2025-day-5-challenge-1.zip
Hier zit een edge case in die wel in de voorbeelddata zit maar niet in de officiële data. Ben benieuwd of mensen hier nog de mist in gaan. Antwoorden:

$ time pypy3 05.py < aoc-2025-day-5-challenge-1.txt 
...50
...4022

real    0m0.373s
user    0m0.330s
sys     0m0.040s

edit:
M'n shell script doet het in 5 seconden; niet slecht

spoiler:

Bedankt! Toen ik deel 1 las dacht ik aan een mooie optimalizatie met binary search. Die leek niet te lukken omdat sommige ranges volledig overlapten met anderen, dus is niet netjes te sorteren. Toen een naïve oplossing gedaan. Voor deel 2 overlappende ranges samengevoegd, dus toen was het ineens weer mogelijk, maar niet meer nodig. Voor jouw input was het zeker wel nodig!

Ik ben nog wel benieuwd welke edge cases je bedoelt, ik ben nergens op gestuit.

Draait nu in een seconde met Python. Nog niet getest met Pypy.

[Eupeodes]

Eupeodes schreef op vrijdag 5 december 2025 @ 08:59:
[...]

ik geloof dat mijn deel 1 nog wat optimalisatie kan gebruiken, dik 5 minuten rekentijd, deel 2 was maar 200ms. Verder ben ik, ondanks de dikke mist buiten, niet de mist in gegaan met deze input (op zich ook niet gek, want ik schrijf en test mijn code op de voorbeeldinput en pas als het antwoord daarop klopt laat ik mijn code los op de echte input)

Heb wat kunnen optimaliseren waardoor deel 1 nu in ieder geval onder de minuut zit

spoiler:

De de-duplicatie die nodig is voor deel 2 eerst uitvoeren en dan pas deel 1 berekenen geeft een enorme boost, initialisatie kost nu 200 ms, deel 2 is amper meer meetbaar, en deel 1 staat er nu onder de minuut

edit: nog een optimalisatie gevonden waardoor ik nu rond de halve minuut zit

[ Voor 4% gewijzigd door Eupeodes op 05-12-2025 09:59 ]

[Marcj]

Gisteren en vandaag waren eigenlijk erg makkelijk. De input is ook vrij klein, waardoor een brute implementatie best te doen is. Hier mijn oplossing voor vandaag.

Soultaker schreef op vrijdag 5 december 2025 @ 08:44:
Extra test data voor dag 5: aoc-2025-day-5-challenge-1.zip
Hier zit een edge case in die wel in de voorbeelddata zit maar niet in de officiële data. Ben benieuwd of mensen hier nog de mist in gaan. ...

Heel erg bedankt voor deze grotere inputs. Maakt het nog enigzins uitdagend en geeft een reden tot verdere optimalisatie. De officiele input deed de domme implementatie al in enkele milliseconden. Mijn huidige implementatie doet deze grote input ook best snel.

spoiler:

Al doe ik nu het combineren van de ranges al bij het verwerken van de input. Vandaar dat die wat trager is, maar daardoor kan de geoptimaliseerde lijst bij beide delen werken. Dat maakt deel 1 echt veel sneller.

Executing
 ├── Input parsed in 17,889µs
 ├── Part 1 calculated in 27,185µs: ...50
 ├── Part 2 calculated in 3µs: ...4022
 └── Total time: 45,647µs

[Woy]

spoiler:

Ik zie dat mensen echt de ranges samenvoegen voor part2, in mijn implementatie doe ik dat niet eens echt, ik skip gewoon een gedeelte van een range als hij al geteld is.

[Marcj]

Soultaker schreef op donderdag 4 december 2025 @ 07:40:
Weer niet zo moeilijk vandaag; ik was in 4 minuten en 13 seconden klaar, wat nog sneller was dan gisteren

Hier wat extra testdata voor dag 4: aoc-2025-day-4-challenge-1-to-3.zip
...

Deze gaan bij mij nu ook vrij snel, maar nr 1 en 2 leveren ook erg mooie plaatjes op!

Deel 1 (in 52ms):


Deel 2 (in 908ms):


Deel 3 (in 59ms) is natuurlijk helemaal zwart na de tijd.

[Soultaker]

KabouterSuper schreef op vrijdag 5 december 2025 @ 09:25:
Met pypy haal ik deel 1 in 240s en deel 2 in 0.013. Ik moest even de edge-cases checken (ik had wel een vermoeden wat er in de data kon zitten), en moest een hele kleine aanpassing doen.

Nice! Ik neem aan dat je de tijd voor het parsen en sorteren bij deel 1 hebt meegerekend? Anders snap ik niet hoe je deel 2 zo snel voor elkaar krijgt.

Bij mij zit verreweg de meeste tijd in het parsen (wat ik niet echt geoptimaliseerd heb) en het sorteren (solve-timed.py):

$ time pypy3 solve-timed.py < aoc-2025-day-5-challenge-1.txt 
ParseInput: 0.064 s
SortRanges: 0.212 s
SortIngredients: 0.013 s
Part1: 0.012 s
Part2: 0.006 s

real    0m0.406s
user    0m0.363s
sys     0m0.033s

Vandaar dat het met de gewone Python interpreter ook bijna even snel draait:

$ time python3 solve-timed.py < aoc-2025-day-5-challenge-1.txt 
ParseInput: 0.147 s
SortRanges: 0.088 s
SortIngredients: 0.031 s
Part1: 0.065 s
Part2: 0.026 s

real    0m0.417s
user    0m0.372s
sys     0m0.037s

Wel interessant om te zien dat het parsen en sorteren in CPython juist weer sneller is dan in PyPy. Waarschijnlijk komt dat doordat het sorteren van tuples een call van native code naar Python code vereist, en dat om een of andere reden sneller is in CPython.

Marcj schreef op vrijdag 5 december 2025 @ 10:00:
Mijn huidige implementatie doet deze grote input ook best snel.

Mooie oplossing! Ik vermoed dat deel 1 nog iets efficiënter kan door de recursief de ingrediënten te partitioneren op ranges, maar ik weet het niet zeker.

Woy schreef op vrijdag 5 december 2025 @ 10:08:

spoiler:

Ik zie dat mensen echt de ranges samenvoegen voor part2, in mijn implementatie doe ik dat niet eens echt, ik skip gewoon een gedeelte van een range als hij al geteld is.

Zo doe ik het ook. Technisch doe je dan wel dubbel werk bij deel 1 en deel 2, maar dat is hooguit een factor 2.

edit:

Hagdos schreef op vrijdag 5 december 2025 @ 09:39:
Ik ben nog wel benieuwd welke edge cases je bedoelt, ik ben nergens op gestuit.

spoiler:

In de officiële invoer zijn er geen ingredient ids die exact gelijk zijn aan het eindpunt van een range, maar in mijn testdata expres wel. Dus als je ergens < i.p.v. <= gebruikt kun je daarop de fout in gaan. Maar in de voorbeeldinvoer komt dit wel voor (range 3-5 met ingredient 5) dus als je die eerst opgelost hebt dan ben je waarschijnlijk immuun voor dit probleem.

[ Voor 11% gewijzigd door Soultaker op 05-12-2025 10:34 ]

[HannoOttens]

Vandaag was ook goed te doen weer!

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

[MueR]

Ik had verwacht dat het vandaag wat moeilijker zou worden eigenlijk, maar dit stelde weinig voor. Dag 5 in Go. Totale tijd rond de ~200µs

En voor de challenge (ik doe het rekenwerk voor deel 1 direct in de parsing stap):

code:

Parsed input in 2.662702613s
Part 1 output: ...50  (131ns)
Part 2 output: ...4022  (199.408µs)
Total time: 2.662954364

[ Voor 33% gewijzigd door MueR op 05-12-2025 11:13 ]

[Mugwump]

Op de een of andere manier kom ik vandaag te laag uit bij deel 2, terwijl de aanpak volgens mij gewoon correct is.

spoiler:

Eerst begonnen met ranges mergen. Example klopte, maar ik kreeg een too low op m'n daadwerkelijke input. Daarna even de aanpak gehanteerd om simpelweg door de op min, max gesorteerde lijst heen te lopen en te tellen. Komt hetzelfde antwoord uit dus ook te laag. Maar even een test file gemaakt met alle vormen van overlap die ik kan vinden, maar ook die lijkt gewoon correct te werken.
Ik zie even niet waar ik de mist in ga.

[fruitschaal2]

Ik had de mazzel dat ik dacht dat het mergen van de ranges al nodig was voor deel 1, hierdoor was deel 2 wel erg goed te doen. Fijn zo'n meevaller op de vrijdag

Op de input van Soultaker heb ik deze resultaten;

code:

Total time: 219.836 ms
Reading data took: 13941 μs
puzzle 1 took: 205891 μs
puzzle 2 took: 2 μs

spoiler:

Bij het inlezen van de data word de data gelijk samengevoegd, hierdoor gaan zowel deel 1 als deel 2 sneller.

Oplossing: https://topaz.github.io/p...uCG/jRoQEwjUgRICJ/5urFlQ=

[Hagdos]

Mugwump schreef op vrijdag 5 december 2025 @ 11:06:
Op de een of andere manier kom ik vandaag te laag uit bij deel 2, terwijl de aanpak volgens mij gewoon correct is.

spoiler:

Eerst begonnen met ranges mergen. Example klopte, maar ik kreeg een too low op m'n daadwerkelijke input. Daarna even de aanpak gehanteerd om simpelweg door de op min, max gesorteerde lijst heen te lopen en te tellen. Komt hetzelfde antwoord uit dus ook te laag. Maar even een test file gemaakt met alle vormen van overlap die ik kan vinden, maar ook die lijkt gewoon correct te werken.
Ik zie even niet waar ik de mist in ga.

[Afbeelding]

Probeer de volgende input eens;

code:

3-8
10-14
12-18
13-16
20-25

Het goede antwoord is 21.

[Woy]

MueR schreef op vrijdag 5 december 2025 @ 11:05:
Ik had verwacht dat het vandaag wat moeilijker zou worden eigenlijk, maar dit stelde weinig voor. Dag 5 in Go. Totale tijd rond de ~200µs

En voor de challenge (ik doe het rekenwerk voor deel 1 direct in de parsing stap):

code:

Parsed input in 2.662702613s
Part 1 output: ...50  (131ns)
Part 2 output: ...4022  (199.408µs)
Total time: 2.662954364

Hoe komt het dat jouw parsing zo lang duurt in verhouding met je oplossing?
Ik measure mijn parsing niet los, maar kom op dit uit

Read input in (00:00:00.0613386)
Part 1: ...50 (00:00:00.2242683)
Part 2: ...4022 (00:00:00.0412880)

Ah, wacht ik zie het al, jouw parsing is ook al het berekenen van de solution, dus die timings zijn niet echt representatief

[ Voor 8% gewijzigd door Woy op 05-12-2025 11:35 ]

[Mugwump]

Hagdos schreef op vrijdag 5 december 2025 @ 11:23:
[...]


Probeer de volgende input eens;

code:

3-8
10-14
12-18
13-16
20-25

Het goede antwoord is 21.

Ik moet toch eens minder gaan drinken.

spoiler:

Miste inderdaad de situatie dat 1 range volledig in een andere range viel. Die gewoon uit de lijst geknikkerd en dan komt het goede antwoord eruit rollen.

Thanks!

[MueR]

Woy schreef op vrijdag 5 december 2025 @ 11:33:
[...]
Ah, wacht ik zie het al, jouw parsing is ook al het berekenen van de solution, dus die timings zijn niet echt representatief

Daarom stond dat er ook bij

[Woy]

MueR schreef op vrijdag 5 december 2025 @ 11:42:
[...]

Daarom stond dat er ook bij

Ja, wat verwacht je nou, dat ik je hele post ga lezen ofzo

[MueR]

Woy schreef op vrijdag 5 december 2025 @ 11:43:
[...]

Ja, wat verwacht je nou, dat ik je hele post ga lezen ofzo

Ja, dat verwacht ik ja

Anyway, mn part 1 solution was echt mega inefficient. Nu is ie beter en zijn de tijden representatief. Met de challenge:
$ time make run
Parsed input in 39.019904ms
Part 1 output: ...50 (481.656µs)
Part 2 output: ...4022 (184.012µs)
make run 0.23s user 0.18s system 254% cpu 0.159 total

[KabouterSuper]

Soultaker schreef op vrijdag 5 december 2025 @ 10:29:
[...]

Nice! Ik neem aan dat je de tijd voor het parsen en sorteren bij deel 1 hebt meegerekend? Anders snap ik niet hoe je deel 2 zo snel voor elkaar krijgt.

Ja, parsen en sorteren zit in deel 1. Het enige statement wat echt heel traag is, is trouwens

spoiler:

for i in ingred:
ssum+=any([1 for (f1,f2) in ranges.keys() if f1<=i<=f2])

Blijkbaar is dit enorm inefficient. Ik ga eens een pythoniaanse manier zoeken die dit wel snel kan.

[SPee]

Mijn eerste poging duurde 70s om de id's te controleren. Toch een kleine verbetering gemaakt en nu gaat het een stuk sneller. Overigens voeg ik de ranges voor deel 1 niet samen. (rust)

test day5::day5_tests::example1_1 ... ok
test day5::day5_tests::example2_1 ... ok
test day5::day5_tests::part2 ... ok
test day5::day5_tests::part1 ... ok
test day5::day5_tests::part3 ... ok

test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 18 filtered out; finished in 0.11s

[Sircuri]

Tot nu toe haakte ik altijd af na dag 3. Maar op een of andere manier lijkt het nu redelijk eenvoudig elke dag. Ik had nog de meeste moeite met deel 2 van dag 1

[P_Tingen]

Bij deel 2 had ik al door dat brute force niet ging werken, maar voor de lolz toch gemaakt en aangezet, met een berekening van de ETA erbij. Ik denk niet dat ik daar op ga wachten; tegen die tijd ben ik als 100-plusser al jaren met pensioen als het goed is



na 0,00003nogwat% berekend te hebben is de verwachte eindtijd ergens in 2073

PS: verbeterde versie finisht in ong 2 ms 😎

[Soultaker]

KabouterSuper schreef op vrijdag 5 december 2025 @ 13:14:

Python:

    ssum+=any([1 for (f1,f2) in ranges.keys() if f1<=i<=f2])

Voor de echte snelheidswinst moet je je algoritme verbeteren, maar ik kan het niet laten om op dit stukje coden te reageren. Je materialiseert hier eerst een hele lijst met 1'en voor elke range waartoe het element behoort, maar any() is alleen in het eerste element geïnteresseerd. Dit soort expressies kun je dus beter schrijven met een generator, door simpelweg de blokhaken weg te halen:

Python:

    ssum+=any(1 for (f1,f2) in ranges.keys() if f1<=i<=f2)

Daarnaast is de 1 for bla if bla constructie een beetje overbodig. De filter-conditie kan je naar voren halen, immers any() checkt of enig element dat gegenereerd wordt naar true evalueert:

Python:

    ssum+=any(f1<=i<=f2 for (f1,f2) in ranges.keys())

Dat is al een heel stuk idiomatischer. Dan kun je tenslotte nog de haakjes om (f1, f2) weghalen, maar dat is een kwestie van persoonlijke voorkeur.

Bij dit probleem maakt het qua performance waarschijnlijk weinig uit, maar in z'n algemeenheid kan een generator wel behoorlijk veel efficiënter zijn bij functies als any() en all() die niet per se alle elementen hoeven te evalueren.

[KabouterSuper]

Soultaker schreef op vrijdag 5 december 2025 @ 16:19:
[...]

Voor de echte snelheidswinst moet je je algoritme verbeteren, maar ik kan het niet laten om op dit stukje coden te reageren. Je materialiseert hier eerst een hele lijst met 1'en voor elke range waartoe het element behoort, maar any() is alleen in het eerste element geïnteresseerd. Dit soort expressies kun je dus beter schrijven met een generator, door simpelweg de blokhaken weg te halen:

Python:

    ssum+=any(1 for (f1,f2) in ranges.keys() if f1<=i<=f2)

Daarnaast is de 1 for bla if bla constructie een beetje overbodig. De filter-conditie kan je naar voren halen, immers any() checkt of enig element dat gegenereerd wordt naar true evalueert:

Python:

    ssum+=any(f1<=i<=f2 for (f1,f2) in ranges.keys())

Dat is al een heel stuk idiomatischer. Dan kun je tenslotte nog de haakjes om (f1, f2) weghalen, maar dat is een kwestie van persoonlijke voorkeur.

Bij dit probleem maakt het qua performance waarschijnlijk weinig uit, maar in z'n algemeenheid kan een generator wel behoorlijk veel efficiënter zijn bij functies als any() en all() die niet per se alle elementen hoeven te evalueren.

Dank je voor de uitleg. Je hebt helemaal gelijk. Het is een mooi gevalletje 'eerst iets schrijven, dan pas nadenken'. Ik was begonnen om de list te maken en te checken hoeveel rijen er in zitten. De ouderwetsche truc die ik altijd gebruikte in sql was 'select sum(1) from [table] ' omdat je zo vroeger een full-table scan kon vermijden. Maar in python werkt het helemaal niet zo, vandaar dat ik sum veranderde in any. Heel ranzig, maar wel iets sneller een werkend programma. De any heb ik nooit correct kunnen toepassen, dus ik ben blij met je duidelijke uitleg.

Any-way, ik heb een beter algoritme waarmee ik de grote dataset in 0.5 sec kan doorrekenen.

[FCA]

Soultaker schreef op vrijdag 5 december 2025 @ 08:44:
Extra test data voor dag 5: aoc-2025-day-5-challenge-1.zip
Hier zit een edge case in die wel in de voorbeelddata zit maar niet in de officiële data. Ben benieuwd of mensen hier nog de mist in gaan. Antwoorden:

$ time pypy3 05.py < aoc-2025-day-5-challenge-1.txt 
...50
...4022

real    0m0.373s
user    0m0.330s
sys     0m0.040s

edit:
M'n shell script doet het in 5 seconden; niet slecht

Met wat optimalisaties

spoiler:

Binary search voor deel 1, totale lengte bijvoegen direct berekenen in deel 2

Day 5 - Part 1 : ..850
        generator: 411ns,
        runner: 17.500247ms

Day 5 - Part 2 : ...04022
        generator: 120ns,
        runner: 14.761247ms

Draai de hele parsing + sortering opnieuw in deel 1 en deel 2.
Heb nog zitten denken of het algoritmisch nog sneller kon, maar ik kwam niet rond de sortering heen.

code: https://github.com/janjit.../blob/master/src/day05.rs

[Proxi]

Ik zie dat veel mensen 'm makkelijk vonden vandaag. Ik niet, zat me toch te klooien. Uiteindelijk heb ik er een redelijk functioneel feestje van gemaakt. Misschien moet ik toch eens F# overwegen .

https://github.com/Reintj...ob/master/Day5/Program.cs

[P_Tingen]

Proxi schreef op vrijdag 5 december 2025 @ 21:05:
Ik zie dat veel mensen 'm makkelijk vonden vandaag. Ik niet, zat me toch te klooien. Uiteindelijk heb ik er een redelijk functioneel feestje van gemaakt. Misschien moet ik toch eens F# overwegen .

https://github.com/Reintj...ob/master/Day5/Program.cs

Deel 1 was toch wel te doen hoop ik?

Iets als deel 2 zit elk jaar wel in AoC. Op een zeker moment herken je wat je moet gebruiken. Ik moest wel even terugzoeken want op zich weet ik in grote lijnen wel wat ik moet doen, maar ik mis altijd net weer een paar details

[Proxi]

P_Tingen schreef op vrijdag 5 december 2025 @ 21:33:
[...]

Deel 1 was toch wel te doen hoop ik?

Iets als deel 2 zit elk jaar wel in AoC. Op een zeker moment herken je wat je moet gebruiken. Ik moest wel even terugzoeken want op zich weet ik in grote lijnen wel wat ik moet doen, maar ik mis altijd net weer een paar details

Ja, deel 1 was in een paar minuten gefixt. Zat bij deel 2 eerst met een brute force die (natuurlijk) niet werkte. Daarna klooien met het herkennen van overlappende ranges. Ik detecteerde alleen dát er een overlap was, maar niet precies waar, dus daar had ik niet zoveel aan. Uiteindelijk gesorteerd en toen was het goed te doen, het duurde erg lang voordat het klikte bij me.

[Soultaker]

Tja, vandaag was vooral letterlijk doen wat er gevraagd wordt. Wel een beetje pielen met het splitsen en roteren natuurlijk. Mijn (niet erg elegante) Python code: 06.py

spoiler:

Ik gebruik transpositie in plaats van rotatie; daardoor wordt de volgorde van de getallen omgedraaid, maar dat maakt niet uit, want optellen en vermenigvuldigen zijn commutatieve operaties.

Ik vermoed dat je hier met numpy of een array-based programming language er nog wel wat moois van kunt maken.

[Hagdos]

Vandaag was meer klooien met de input data dan dat het echt puzzelen was.

Toch even opscheppen met 2^9:

[Soultaker]

Hagdos schreef op zaterdag 6 december 2025 @ 07:24:
Toch even opscheppen met 2^9:
[Afbeelding]

Heb jij er maar 512?

[Hagdos]

Verdorie, het is nog vroeg. Ik dacht even dat ik iets gemist had

Ik zie dat ik niet in de topicstart sta, dus ik ben niet te controleren. Dat ga ik (laten) fixen.

[itons]

goed bezig hoor

[P_Tingen]

Ik snap de opgave niet helemaal, ook na drie keer lezen niet. En geen koffie.
Ik heb een zooi getallen in kolommen, maar onderaan een heleboel regels met operatoren, welke moet ik nou gebruiken, is dit een soort rpn?

[MatHack]

P_Tingen schreef op zaterdag 6 december 2025 @ 08:32:
Ik snap de opgave niet helemaal, ook na drie keer lezen niet. En geen koffie.
Ik heb een zooi getallen in kolommen, maar onderaan een heleboel regels met operatoren, welke moet ik nou gebruiken, is dit een soort rpn?

spoiler: uitleg opgave

Voor deel 1 is het de getallen per kolom (normale leesrichting), voor deel 2 moeten de cijfers van boven naar beneden gelezen worden voor het maken van de getallen

[FCA]

Moest inderdaad deel 2 een paar keer lezen voordat ik uberhaupt begreep wat de bedoeling was

spoiler:

En daarna lichte paniek: hoe parse ik dit nu weer?
Uiteindelijk een array van chars, en dan transponeren, rijen chars naar strings omzetten, en elke keer als ik een lege string tegenkwam de index ophogen.
Niet mijn favoriete opgave, eerste iteratie had een hoop "match" op de operator, dubbele enumerate loops en turbofishes overal.

Soort van opgeschoonde oplossing: https://github.com/janjit.../blob/master/src/day06.rs

[Friits]

Best een lastige vandaag! Conceptueel niet natuurlijk, maar wel om het een beetje netjes uit te schrijven. Uiteindelijk heb ik het kunnen geïmplenteerd als een serie splits, zips en joins, tot slot een eval om het antwoord daadwerkelijk uit te rekenen:

spoiler:

*nums, ops = open('in.txt')
part1 = zip(*map(str.split, nums))
part2 = [*map(str.split, filter(bool, ' '.join(map(''.join, zip(*nums))).split(' '*5)))]
for nums in part1, part2: print(eval('+'.join(map(str.join, ops.split(), nums))))

[ Voor 10% gewijzigd door Friits op 06-12-2025 15:11 ]

[Soultaker]

Friits schreef op zaterdag 6 december 2025 @ 12:13:

spoiler:

*nums, ops = open('in.txt')
part1 = zip(*map(str.split, nums))
part2 = map(str.split, ' '.join(map(''.join, zip(*nums))).split(' '*5))
for nums in part1, part2: print(eval('+'.join(map(str.join, ops.split(), nums))))

Even los van het feit dat ik niet zo snel zie waar de vermenigvuldiging hier zit, (dat zit in de map(str.join, ops.split, ..) lijkt het niet het juiste antwoord te geven voor deel 2?

[ Voor 5% gewijzigd door Soultaker op 06-12-2025 13:41 ]

[Friits]

Soultaker schreef op zaterdag 6 december 2025 @ 13:34:
[…] lijkt het niet het juiste antwoord te geven voor deel 2?

Ah je hebt gelijk, bedankt voor het melden. Iets te veel als een kip zonder kop zitten refactoren, en slechts getest op de voorbeeld-input. Ik heb de code hierboven aangepast.

[Woy]

Deel 1 vandaag was weer erg makkelijk. Deel 2 is ook niet zo heel moeilijk als je eenmaal begrijpt wat er precies gevraagd wordt.

Maar het netjes opschrijven is inderdaad nog wel een uitdagen, daar heb ik niet al te veel tijd aan besteed

https://github.com/rverst...ain/AdventOfCode/Day06.cs

[Proxi]

Hahaha, blijkbaar zijn omslachtig en overengineered mijn tweede en derde naam voor dag 6:

https://github.com/Reintj...ob/master/Day6/Program.cs

[Jelle van Kraaij]

https://github.com/JellevanKraaij/AoC-2025/tree/main/day06
Vond hem zelf wel leuk gemaakt vandaag.
2de onderdeel was wel even een breinkraker...

[Soultaker]

Fuuuu... 3 seconden te traag op deel 1. Gefeliciteerd Michael.

[Gropah]

Rare dag voor mij vandaag.

Ik snap deel 1 nog steeds niet (als in ik kom handmatig niet tot het antwoord) maar door gewoon te doen wel opgelost.

Deel 2 was wat mij betreft best simpel (en kon ik ook makkelijk begrijpen ). antwoord:

spoiler:

DFS mbv recursie met caching voor al bezochte plekken vanwege performance.

. Voor mij was het wel zo dat ik

spoiler:

niet veel kon hergebruiken door mijn (achteraf) domme implementatie van deel 1, wat vrij letterlijjk de map aanpastte naar de getekende boom in het voorbeeld

. Maar eh, niet ontevreden.

[FCA]

Deel 1 best lang over zitten prutsen, halverwege zelfs helemaal omgegooid

spoiler:

Eerst bedacht om alle beams apart te tracken, maar zag de 3-dubbele for loop niet zitten, dus omgezet naar iets wat per regel geupdate werd en dan er door heen lopen. Achteraf een goede keus, want deel 2 was toen heel simpel: i.p.v. een boolean houden we een integer bij.

Uiteindelijk voor deel 2 eerst nog een off-by-one met de testdata: niet nadenken, gewoon +1 er bij op, en het werkte ook voor de echte data.

Later in de ochtend bedacht waarom: je begint natuurlijk altijd al met 1 beam, dat was ik vergeten...
En nog een edge-case bedacht die dus blijkbaar niet in de data voorkomt: als je een splitter hebt die een nieuwe tachyonbeam in een doorlopende beam plaatst moet je die eerste beam niet wegvagen, maar de nieuwe beams erbij op tellen.

[Reptile209]

Gropah schreef op zondag 7 december 2025 @ 10:47:
Rare dag voor mij vandaag.

Ik snap deel 1 nog steeds niet (als in ik kom handmatig niet tot het antwoord) maar door gewoon te doen wel opgelost.

[...]

Ik heb hem alleen gelezen, nog niet begonnen met uitwerken. Maar in snap idd geen reet van hoe ze op die 21 spits komen. Maar wellicht valt het kwartje als ik er echt aan begin...

[Soultaker]

Gropah schreef op zondag 7 december 2025 @ 10:47:
Ik snap deel 1 nog steeds niet (als in ik kom handmatig niet tot het antwoord) maar door gewoon te doen wel opgelost.

Huh? Het is toch gewoon

spoiler:

het aantal splitters (^) dat door een lichtstraal (|) geraakt wordt

? Op wat voor antwoord kom je uit op het voorbeeld dat niet klopt met de tekst (en blijkbaar wel met je code, aangezien je het toch hebt weten op te lossen?)

spoiler:

niet veel kon hergebruiken door mijn (achteraf) domme implementatie van deel 1, wat vrij letterlijjk de map aanpastte naar de getekende boom in het voorbeeld

Ik deed precies hetzelfde bij deel 1. Dit was mijn code voor deel 1 die letterlijk alle lichtstralen intekent in het grid.

Mijn ervaring is dat het lastig is om te voorspellen wat deel 2 wordt, dus mijn filosofie is om niet vooruit te denken, en deel 1 er zo snel mogelijk uit te rammen op de domste manier die ik kan bedenken, en dan bij deel 2 pas slimme dingen te gaan doen als het echt moet.

In het verleden probeerde ik soms wel de code netjes te organiseren voor deel 2, maar in de praktijk leidde dat er vaak toe dat ik langer over deel 1 deed, terwijl deel 2 toch net wat anders was dan ik had gehoopt, waardoor ik alsnog alles om moest gooien.

[Soultaker]

Reptile209 schreef op zondag 7 december 2025 @ 13:21:
Maar in snap idd geen reet van hoe ze op die 21 spits komen. Maar wellicht valt het kwartje als ik er echt aan begin...

Okee nu ben ik echt benieuwd hoe jij en @Gropah het probleem geïnterpreteerd hebben. Want het problem statement bevat letterlijk de uitwerking van dit voorbeeld:

.......S.......
.......|.......
......|^|......
......|.|......
.....|^|^|.....
.....|.|.|.....
....|^|^|^|....
....|.|.|.|....
...|^|^|||^|...
...|.|.|||.|...
..|^|^|||^|^|..
..|.|.|||.|.|..
.|^|||^||.||^|.
.|.|||.||.||.|.
|^|^|^|^|^|||^|
|.|.|.|.|.|||.|

Het enige dat je moet doen is

spoiler:

het aantal ^ karakters tellen waar een | boven staat.

Dat is letterlijk 21.

spoiler:

Er staat 22 ^ karakters in het grid; de enige met een . erboven is de vijfde op de een na laatste regel, dus 22 - 1 = 21.

[Reptile209]

Soultaker schreef op zondag 7 december 2025 @ 13:29:
[...]
Dat is letterlijk 21.

spoiler:

Er staat 22 ^ karakters in het grid; de enige met een . erboven is de vijfde op de een na laatste regel, dus 22 - 1 = 21.

Kijk, dat had ik in mijn quick-scan nog niet opgemerkt idd. En meestal worden dat soort zaken juist in het stap-voor-stap voorbeeld uitgewerkt.

[Jelle van Kraaij]

Deel 1 was even goed lezen en nadenken wat ze nou bedoelde en boe is op die 21 komen
Deel 2 stuk langer over gedaan

spoiler:

Recursive zonder caching is niet te doen.
Toen iteratief geprobeerd zonder caching, wel iets sneller, maar duurde nog steeds veel te lang
Dan maar weer alles omgooien naar recursive met caching. Zo dat maakt een enorm verschil
Ik vervang gwn de '^' met de uitgerekende waarde

https://github.com/JellevanKraaij/AoC-2025/tree/main/day07

[Friits]

Leuk puzzeltje vandaag. Mijn oplossing in Python.

Ik vind de puzzels tot nu toe trouwens wel erg makkelijk, zeker gegeven dat we inmiddels over de helft zijn, en het weekend (die waren tijdens eerdere edities altijd moeilijker dan de doordeweekse puzzels). Maar goed, ik vermaak me alsnog prima!

[Jelle van Kraaij]

Friits schreef op zondag 7 december 2025 @ 14:10:
Leuk puzzeltje vandaag. Mijn oplossing in Python.

Ik vind de puzzels tot nu toe trouwens wel erg makkelijk, zeker gegeven dat we inmiddels over de helft zijn, en het weekend (die waren tijdens eerdere edities altijd moeilijker dan de doordeweekse puzzels). Maar goed, ik vermaak me alsnog prima!

PFff sommige mensen kunnen veeel beter puzzelen en python dan mij
Mooi gedaan

@Friits ik snap nu hoe het werkt, heel mooi opgelost!

[ Voor 3% gewijzigd door Jelle van Kraaij op 07-12-2025 14:17 ]

[Friits]

Thanks! Het is gewoon een kwestie van veel doen, denk ik. Ik heb inmiddels alle 500+ sterren, en ben ieder jaar ook actief op het AoC-subforum van Reddit. Daar is iedere dag een thread waarin mensen hun oplossingen plaatsen. Hier is die voor de puzzel van vandaag.

Zeker mijn eerste paar jaren heb ik veel geleerd door het lezen en begrijpen van andere oplossingen. Tegenwoordig deel ik vooral mijn eigen oplossingen, en ontvang ik feedback

[Jelle van Kraaij]

Ja, eens! Tijdens mijn opleiding (CODAM) was aoc altijd het leukste, dan kon je met iedereen om je heen competitie doen, elkaar helpen en ideeën uitwisselen.
Nu ben ik de enige dev in mijn bedrijf, dus dit jaar voor het eerst een beetje online aan het kijken.
Daarom ben ik hier (;
Grootste lol vind ik het gewoon oplossen en hoe dat is maakt me niet zoveel uit.
Maar daarna kijken hoe mensen het 10x korter of sneller hebben geschreven is altijd zeer interessant.

[Gropah]

Soultaker schreef op zondag 7 december 2025 @ 13:25:
[...]

Huh? Het is toch gewoon

spoiler:

het aantal splitters (^) dat door een lichtstraal (|) geraakt wordt

? Op wat voor antwoord kom je uit op het voorbeeld dat niet klopt met de tekst (en blijkbaar wel met je code, aangezien je het toch hebt weten op te lossen?)

En dat was het stukje wat ik mistte

spoiler:

Ik had dus niet gezien dat er een splitser niet geraakt werd, dus zat mij af te vragen waarom niet 22/aantal splitsers.

Maar goed, uiteindelijk heeft mij dat niet tegengehouden om de goeie oplossing te implementeren

[Marcj]

Vandaag kreeg ik het voor elkaar om deel 1 niet goed te begrijpen en per ongeluk de oplossing voor deel 2 alvast te schrijven. Was al verbaasd dat ik memoization voor deel 1 nodig had. Nou ja, maakte de rest wel vrij makkelijk

[FCA]

Friits schreef op zondag 7 december 2025 @ 14:10:
Leuk puzzeltje vandaag. Mijn oplossing in Python.

Ik vind de puzzels tot nu toe trouwens wel erg makkelijk, zeker gegeven dat we inmiddels over de helft zijn, en het weekend (die waren tijdens eerdere edities altijd moeilijker dan de doordeweekse puzzels). Maar goed, ik vermaak me alsnog prima!

Het werkt goed op de data die AOC je geeft (en is kort en bondig en elegant), maar er zijn wat edge cases waar dit niet goed gaat (hoe erg dat is hangt er vanaf wat voor purist je bent natuurlijk):

spoiler:

Als je 2 beams naaast elkaar hebt die alle 2 een splitter op dezelfde rij tegenkomen, en als je een splitter op de eerste of laatste kolom hebt

Sowieso zijn er de eerste dagen natuurlijk qua complexiteit in de data geen "worst-case" scenario's.

Het verhaal over weekenden die moeilijker zijn doet elk jaar de ronde, maar ik heb het niet zo in de statistieken kunnen terugvinden. Als ik bijvoorbeeld kijk naar https://github.com/jwoLon...-ov-file#completion-times dan zitten de extra moeilijke dagen door de hele week verspreid.

Wat betreft de moeilijkheidsgraad dit jaar, het enige wat ik terug kan vinden is https://www.reddit.com/r/...&utm_content=share_button van 2 maanden terug, waar hij zegt te proberen het hele spectrum te bestrijken, zonder beginners te ontmoedigen. Ik ga er dus vanuit dat het nu snel moeilijker gaat worden...

[Janoz]

Wat ik voor vandaag voor deel 1 gedaan had maakte deel 2 vervolgens ook best simpel.

spoiler:

Voor deel 1 las ik gewoon per regel de input en hield ik in een set de x locaties van de beams bij. Stond er op die regel een splitter dan ging het totaal aantal 1 omhoog en voegde ik aan de set x+1 en x-1 toe. Zat er geen splitser dan werd gewoon x in de nieuwe set gedaan.

Voor deel 2 hoefde ik alleen de set te vervangen door een hasmap met hoeveel realiteiten er voor die x positie waren. Het toevoegen aan de set hoefde ik alleen te vervangen door het bij elkaar optellen van het aantal realiteiten.

https://github.com/Janoz-NL/advent-of-code/blob/master/y2025/src/main/java/com/janoz/aoc/y2025/day7/Day7.java#L23

[Friits]

@FCA Haha, ik ben totaal geen purist, en ook geen snelheidsduivel. Randgevallen (die niet in mijn input zitten) of efficiëntie interesseren me niet. If it works, it works.

Ik probeer wel altijd een compact stukje code (<15 LoC) af te leveren. De meeste dagen zo eenvoudig mogelijk (en daardoor goed te begrijpen), maar soms ga ik helemaal los met NumPy, functools, of itertools.

Dat van die weekenden is wel iets dat ik me denk te kunnen herinneren uit eerdere jaren, zeker anno IntCode. Die statistieken geven alleen maar aan hoe snel de eerste honderd oplossers waren, en dat is natuurlijk niet echt representatief voor de gehele populatie van oplossers.

Maar goed, ik ben benieuwd wat we nog gaan krijgen. Ik hoop op nog een mooi doolhof-based puzzel, en iets waarin we een simpel spel moeten simuleren. En in de tweede helft bepalen wat de score is na ronde 10¹⁰⁰

Ik ben wel blij met slechts twaalf dagen AoC, want rond de twaalfde komt meestal ook de AIVD kerstpuzzel uit. Die periode van overlap tussen AoC en AIVD was niet goed voor m'n nachtrust en/of sociaal leven

[RayNbow]

Ik durf mijn brouwsel voor vandaag niet te tonen. Zeer inefficiënt in elkaar geflanst...

1. Lees grid in.
2. Definieer een oneindige lijst waarin herhaaldelijk een stapfunctie wordt toegepast op het grid. De stapfunctie neemt dus als invoer een heel grid en produceert een nieuw heel grid.
3. Pak vanwege hoe m'n stapfunctie werkt het (aantal rijen x 2)e grid uit de lijst.
4. Gebruik daarvan de laatste rij om het antwoord te bepalen.

...maar het werkt.

[KabouterSuper]

Friits schreef op zondag 7 december 2025 @ 18:27:
@FCA
Dat van die weekenden is wel iets dat ik me denk te kunnen herinneren uit eerdere jaren, zeker anno IntCode.

Ik kan me ook een weekend-opdracht herinneren met 8-bit cijfers (a la wekkerradio) en een opdracht met het verrijden van auto's. Was het niet moeilijker, dan was het in elk geval afwijkend.

Ik ben wel blij met slechts twaalf dagen AoC, want rond de twaalfde komt meestal ook de AIVD kerstpuzzel uit. Die periode van overlap tussen AoC en AIVD was niet goed voor m'n nachtrust en/of sociaal leven

Jij doet dus ook mee mee de aivd kerstpuzzel, leuk! Ik heb vorig jaar als volwassene de juniorpuzzel gedaan, maar vanwege AoC ben ik pas in Januari begonnen. Ik heb het zelfs ingezonden (natuurlijk netjes gemeld dat ik geen junior ben). Ik was trots dat ik 9e of 10e geworden was, maar er waren dus wel een handvol 15-jarige snotneuzen beter dan ik.

[fruitschaal2]

Vandaag weer een leuke puzzel. Eerste oplossing was snel gevonden. Voor deel 2 heb ik ook het eerste deel herschreven van een set naar een hashmap, zodat beide delen in1 keer opgelost kunnen worden.

Mijn oplossing: https://topaz.github.io/p...WGnyh1hKGJBUyT/i11//NRiGP

[jeroenheijmans]

Hoi Tweakers! Naast zelf meedoen (TypeScript repo) bouw ik een AoC browser extension (leuk om wat screenshots voorbij te zien komen hierboven! ), en run ik elk jaar de community 'survey' voor Advent of Code.

Mocht je dat leuk vinden kun je er wat meer over lezen op Reddit, of de survey gewoon even invullen als je dat nog niet al gedaan hebt: https://forms.gle/TAgtXYskwDXDtQms6

Survey sluit op of vlak na de 12e, en kort daarna komen de resultaten bij de vorige jaren op: https://jeroenheijmans.github.io/advent-of-code-surveys/

En: veel plezier met de puzzels natuurlijk!

[Soultaker]

Het begint langzaam aan iets moeilijker te worden. Ik had mazzel dat ik vorig jaar

spoiler: dag 8

een Disjoint Set datastructuur geïmplementeerd had (disjointset.py). Niet om puzzels op te lossen, maar om extra data te genereren (die data structuur is behulpzaam om random doolhoven te genereren, bijvoorbeeld).

Die code kon ik vandaag dus mooi hergebruiken, en dan is de oplossing eigenlijk relatief eenvoudig: 08.py

Ik had wel een trage start bij deel 1, want ik had bij de voorbeeldinvoer de verkeerde interpretatie:

spoiler:

Ik telde de componenten nadat de eerste 10 connecties gemaakt waren (waarbij ik paren van punten die al in hetzelfde component zaten oversloeg), terwijl de bedoeling was om simpelweg de eerste 10 paren te verwerken (ongeacht of ze nieuwe verbindingen vormen of niet).

Dan krijg je een off-by-one error bij de voorbeeldinvoer. Ik had pas door wat er mis ging toen ik me realiseerde dat de officiële invoer precies 1000 punten bevat, en dan kun je natuurlijk nooit 1000 verbindingen maken (maximaal 999).

[Soultaker]

jeroenheijmans schreef op zondag 7 december 2025 @ 22:27:
Hoi Tweakers! Naast zelf meedoen (TypeScript repo) bouw ik een AoC browser extension (leuk om wat screenshots voorbij te zien komen hierboven! ), en run ik elk jaar de community 'survey' voor Advent of Code.

De extension is erg handig! Vooral naar de tabel met tijden kijk ik vaak. Eigenlijk raar dat dat niet standaard in het leaderboard zit (je hebt wel je eigen “personal times” op een aparte pagina, maar het is juist leuk om te vergelijken met de concurrentie). De grafieken vind ik wat minder inzichtelijk.

Ik heb de survey ook ingevuld. Ben benieuwd hoe de attitudes over AI veranderen. Dat is nogal een polariserend onderwerp.

[Janoz]

Soultaker schreef op maandag 8 december 2025 @ 06:50:
Het begint langzaam aan iets moeilijker te worden. Ik had mazzel dat ik vorig jaar...

spoiler:

Mijn connected sets implementatie die ik al had was helaas puur op 2d grids geimplementeerd, dus eigenlijk had ik daar niet zo vel aan. Gelukkig kon ik sommige datastructuren wel hergebruiken.

spoiler:

Voor vandaag was ik even bang dat de permutatie van al die verbindingen te groot zou gaan worden, maar dat bleek mee te vallen. 10000 verbindingen valt naturlijk ook nog best mee.

Uiteindelijk heb ik net geen 2 seconden nodig voor 1 en 2

Soultaker schreef op maandag 8 december 2025 @ 07:03:
Ik heb de survey ook ingevuld. Ben benieuwd hoe de attitudes over AI veranderen. Dat is nogal een polariserend onderwerp.

Huh? Volgens mij zaten er dit jaar helemaal geen vragen over AI in de survey

[ Voor 18% gewijzigd door Janoz op 08-12-2025 08:17 ]