Advent Of Code 2025

[bakkerjangert]

Mijn implementatie in python. Deel 1 was ik langer mee bezig dan deel 2. Door de opzet van deel 1 was deel 2 één extra check in de loop toevoegen.

[Friits]

Oei, op het leaderboard loopt Soultaker iedere dag iets verder op mij uit! Misschien toch maar om 5u45 opstaan om alvast een pot koffie te zetten.

Hier mijn Python-code voor vandaag.

[Soultaker]

Janoz schreef op maandag 8 december 2025 @ 08:15:
Huh? Volgens mij zaten er dit jaar helemaal geen vragen over AI in de survey

Oh, je hebt gelijk. Ik keek naar de resultaten van vorige jaren. Wel jammer want juist als je elk jaar dezelfde vraag stelt kun je verandering in sentiment tracken (zo zie je bijvoorbeeld dat JavaScript terrein verliest aan TypeScript).

Friits schreef op maandag 8 december 2025 @ 09:25:
Oei, op het leaderboard loopt Soultaker iedere dag iets verder op mij uit!

In het verleden verloor ik vooral punten op de latere dagen, wanneer de problemen moeilijker worden. Bijvoorbeeld 23, 24, 25 in 2023, en 21, 23, 24 in 2024.

Misschien toch maar om 5u45 opstaan om alvast een pot koffie te zetten.

Koffie zetten doe ik ook altijd. Mag dat eigenlijk wel, of is dat illegale doping voor programmeurs?

[Eupeodes]

Soultaker schreef op maandag 8 december 2025 @ 10:08:
[...]

Koffie zetten doe ik ook altijd. Mag dat eigenlijk wel, of is dat illegale doping voor programmeurs?

is het doping of brandstof?

A programmer is an organism that converts caffeine into code

[HannoOttens]

Vandaag was een leuke uitdaging! Tevreden met de snelheid van mijn oplossing. Draait in ~160ms (80ms voor beide delen).

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

spoiler:

Verbonden circuits hou ik bij in een array met volgnummertjes. Die beginnen allemaal op nul en zijn groter dan nul als ze deel zijn van een circuit.

[ Voor 3% gewijzigd door HannoOttens op 08-12-2025 12:25 ]

[Janoz]

Friits schreef op maandag 8 december 2025 @ 09:25:
Misschien toch maar om 5u45 opstaan om alvast een pot koffie te zetten.

Ik zet er niet mijn wekker voor. Maar ik wordt wel eens vroeg wakker, en in december ga ik er dan (even) uit. In het weekend even naar beneden, puzzel doen en weer lekker mijn bed in kruipen, en door de week hangt het af van hoe snel ik de puzzel af heb.

Vanochtend was ik pas om 6:20 beneden. Ik denk niet dat mijn wederhelft heel gelukkig wordt wanneer ik half december elke dag een wekker zet

[Jelle van Kraaij]

Zo was voor mij wel ongeveer het limiet, hopelijk lukt morgen nog...
part2 was wel zo klaar daarintegen, opzet kon ongeveer gelijk blijven
Eerst lang zelf geprobeerd, maar op een gegeven moment wel een beetje inspiratie opgedaan.

spoiler:

Idee om eerst alle combinaties uit te rekenen maakte het verschil, daarna kon ik het zelf wel weer verder bedenken

https://github.com/Jellev...25/blob/main/day08/run.py

[ Voor 86% gewijzigd door Jelle van Kraaij op 08-12-2025 15:27 ]

[Jelle van Kraaij]

Friits schreef op maandag 8 december 2025 @ 09:25:
Oei, op het leaderboard loopt Soultaker iedere dag iets verder op mij uit! Misschien toch maar om 5u45 opstaan om alvast een pot koffie te zetten.

Hier mijn Python-code voor vandaag.

Friits je hebt wel weer een ongelooflijk korte, elegante oplossing vergeleken met mij chapeau

[FCA]

Vandaag flink lopen prutsen.

spoiler:

Detecteren hoe en wat we konden mergen was een flinke struggle. Uiteindelijk voor deel 1 eerst een hele langzame strategie gevonden (hele tijd door de lijst heen gaan en checken of we iets mergen), later voor deel 2 in de trein een goede manier gevonden. Lijkt erg op wat Friits had gedaan, maar uiteraard minder kort en elegant.

Eerst nog wel wat langzaam, maar nu deel 1 in 11ms en deel 2 in 28ms. Wel veruit de langzaamste (na optimalisaties) tot nu toe, maar je blijft natuurlijk zitten met een O(n^2) algoritme voor het bereken van de afstanden, nog geen idee of je dat nog zou kunnen optimaliseren.

edit: met nog wat micro-optimalisaties naar 4ms en 21.9ms respectievelijk. Meeste tijd zit dus niet in de afstanden berekenen, maar in de code daarna.

Ik zie nu dat er speciale algoritmes voor bestaan (disjoint-set data structuren). Dag 13 dan maar

[ Voor 16% gewijzigd door FCA op 08-12-2025 20:55 ]

[jeroenheijmans]

De extension is erg handig! ... De grafieken vind ik wat minder inzichtelijk.

Thanks! En mee eens, ik gebruik zelf vooral ook de mediallespiegel (want: leuk!) en de delta-tijden (want: interessanter voor beetje 'competitie' in NL tijdzone).

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

Correct! Het was tijd voor iets nieuws (en de vraag riep erg veel negativiteit op in de "Other..." antwoorden), dus dit jaar zijn de vragen over welke "emoties" je ervaart tijdens het puzzelen nieuw!

[FCA]

Deel 1 was mijn snelste solve tijd tot nu toe, deel 2...

spoiler:

Blijkt dat het in Rust "snel genoeg" is om door alle randen van een rechthoek heen te lopen en te checken (met een precomputed min max tabel) of die binnen de groene randen valt. Slechts 10s rekentijd op de laptop
Wel veel zitten prutsrn met verschillende conventies voor x en y

Nu al wel een snellere oplossing bedacht: alleen de randen checken op posities waar er veranderingen in de min en max x en y posities van de groene randen zitten.

Wel goed voor de positie op het leaderboard op m'n werk, blijkbaar zijn er veel mensen die geometrie lastig vinden.

[P_Tingen]

Vraagje over dag 8, deel 2. Het is me weer eens niet duidelijk

spoiler:

Er staat:

Continue connecting the closest unconnected pairs of junction boxes together until they're all in the same circuit.

Maar betekent dat ook dat ik niet meer slechts de top-1000 van kortste connections moet maken, maar juist alle connections moet gebruiken?

 
Pff, soms heeft AoC meer met tekstverklaren te maken dan met programmeren

[FCA]

P_Tingen schreef op dinsdag 9 december 2025 @ 08:59:
Vraagje over dag 8, deel 2. Het is me weer eens niet duidelijk

spoiler:

Er staat:

Continue connecting the closest unconnected pairs of junction boxes together until they're all in the same circuit.

Maar betekent dat ook dat ik niet meer slechts de top-1000 van kortste connections moet maken, maar juist alle connections moet gebruiken?

 
Pff, soms heeft AoC meer met tekstverklaren te maken dan met programmeren

Ja, maar wel nog steeds in volgorde van klein naar groot.

[P_Tingen]

FCA schreef op dinsdag 9 december 2025 @ 09:06:
[...]
Ja, maar wel nog steeds in volgorde van klein naar groot.

Dank u!

[Friits]

@P_Tingen http://www.adventofrealizingicantread.com is niet voor niets geregistreerd

Dit is wat ik vandaag in elkaar heb geknutseld. Niet al te snel (0.6 seconden), maar goed genoeg voor mij.

[ Voor 203% gewijzigd door Friits op 09-12-2025 12:00 ]

[Marcj]

Vandaag was interessant. Deel 1 was heel snel opgelost, maar deel 2 ging ik eerst helemaal de verkeerde kant mee op. Uiteindelijk nu in mijn pauze maar afgemaakt en de uiteindelijke oplossing is vrij kort nog.

spoiler:

Wel een nieuwe functie moeten implementeren om te controleren of een lijn een vierkant doorkruist. Maar toen ik dat had, ging deze ook vrij snel.

Nu loopt deze ook binnen 10ms, waar ik wel blij mee ben.

Voor de grap ook nog een visualisatie gemaakt van de output. Nu snap ik de input ineens veel beter

spoiler:

[ Voor 30% gewijzigd door Marcj op 09-12-2025 13:12 ]

[Soultaker]

Volgens mij doen jullie allemaal maar wat, zolang het juiste antwoord er uit rolt, ook al is het algoritme zo lek als een mandje

Case in point:

Friits schreef op dinsdag 9 december 2025 @ 09:37:
Dit is wat ik vandaag in elkaar heb geknutseld. Niet al te snel (0.6 seconden), maar goed genoeg voor mij.

Prachtige code, maar faalt op zoiets simpels als:

1,1
9,1
9,9
7,9
7,3
3,3
3,9
1,9

(Correcte antwoord: 27, niet 81.)

Sommige van de andere oplossingen die ik langs zien komen zijn net zo dubieus.

[HannoOttens]

@Soultaker Oef, ook bij mij komt door een incorrecte oplossing uit.. 35 in plaats van de inderdaad correcte 27. Leuke edge case die ik nog niet had bedacht!

Blijft moeilijk om echt een sluitend algoritme te bedenken. Doe het graag zonder te zoeken op vergelijkbare problemen. Dan kom ik er toch vaak achter dat mijn kennis te kort schiet.

[P_Tingen]

Soultaker schreef op dinsdag 9 december 2025 @ 13:17:
Volgens mij doen jullie allemaal maar wat, zolang het juiste antwoord er uit rolt, ook al is het algoritme zo lek als een mandje

Case in point:

[...]

Prachtige code, maar faalt op zoiets simpels als:

1,1
9,1
9,9
7,9
7,3
3,3
3,9
1,9

(Correcte antwoord: 27, niet 81.)

Sommige van de andere oplossingen die ik langs zien komen zijn net zo dubieus.

Voor welk deel is dit, A of B?

[bakkerjangert]

Deel 1 appeltje eitje, deel 2 daar in tegen veel mee lopen prutsen. Nog niet optimaal met een handmatige aanpassing die benodigd is mijn code en traag voor deel 2. Maar wel correct, in ieder geval voor mijn input.

[MatHack]

P_Tingen schreef op dinsdag 9 december 2025 @ 15:18:
[...]

Voor welk deel is dit, A of B?

9B, deel A is supersimpel.

[Thorwing]

Vandaag beetje heen en weer gestruggled met een algoritme. Ik begon met het idee dat AWT mij kon helpen vandaag, maar kreeg dat niet werkend. Toen voor de sterren van vandaag nog even algoritme bedacht die natuurlijk werkt voor de opgave, maar vervolgens niet voor de gekke voorbeelden zoals mensen hier aangeven. Toen dat eenmaal werkte weer terug naar AWT en low and behold, het werkte.

Is het valsspelen? Wellicht...

Kotlin:

object Day9 : AdventOfCode({
    val coordinates: List<Pair<Int, Int>> = input
        .lines()
        .map { it.split(",").map(String::toInt).let { (x, y) -> y to x } }

    val polygon: Polygon = coordinates.fold(Polygon()) { acc, (y, x) -> acc.apply { addPoint(x, y) } }

    val rectangles: List<Rectangle2D> = coordinates.flatMapIndexed { row, (p1y, p1x) ->
        coordinates.drop(row + 1).map { (p2y, p2x) ->
            Rectangle2D.Double(
                minOf(p1x, p2x).toDouble(),
                minOf(p1y, p2y).toDouble(),
                (p2x - p1x).absoluteValue.toDouble(),
                (p2y - p1y).absoluteValue.toDouble()
            )
        }
    }

    fun Rectangle2D.size() = ((width + 1) * (height + 1)).toLong()

    part1 {
        rectangles.maxOf(Rectangle2D::size)
    }

    part2 {
        rectangles.filter(polygon::contains).maxOf(Rectangle2D::size)
    }
})

[Janoz]

Soultaker schreef op dinsdag 9 december 2025 @ 13:17:
Volgens mij doen jullie allemaal maar wat, zolang het juiste antwoord er uit rolt, ook al is het algoritme zo lek als een mandje

Case in point:

[...]

Prachtige code, maar faalt op zoiets simpels als:

1,1
9,1
9,9
7,9
7,3
3,3
3,9
1,9

(Correcte antwoord: 27, niet 81.)

Sommige van de andere oplossingen die ik langs zien komen zijn net zo dubieus.

Yup, ik krijg ook 35. Maar mijn aaname dat cutouts kleiner zouden zijn dan de grootste oppervlakte was voor de puzzel input juist .

Wel mooi om te zien wat de JIT kan. Als ik mijn oplossing 2x achter elkaar draai is de tweede keer meer dan 2x zo snel.

In 0m 0s 59ms 447875ns
In 0m 0s 25ms 812333ns

edit: Hmm, misschien is het nog wel een grappige uitdaging om een BSP te implementeren zodat ook het voorbeeld van @Soultaker goed gaat.

[ Voor 7% gewijzigd door Janoz op 09-12-2025 16:13 ]

[Marcj]

Soultaker schreef op dinsdag 9 december 2025 @ 13:17:
Volgens mij doen jullie allemaal maar wat, zolang het juiste antwoord er uit rolt, ook al is het algoritme zo lek als een mandje
...
Sommige van de andere oplossingen die ik langs zien komen zijn net zo dubieus.

Nou ja, lek. Ik heb aannames gedaan over de vorm. Maar jouw voorbeeld heb ik wel even toegevoegd en ook een oplossing gevonden zodat ik niet een gebied vind die geheen buiten de vorm zit. Wel maak ik nu nog de aanname dat de poly opgeschreven staat met de klok mee. Als je dat omdraait werkt die nog steeds niet

Ook mijn check of een lijn door een gebied kruist is niet fool-proof, maar goed genoeg voor deze vormen.

Ook nog een optimalisatie gevonden, waardoor veel sneller ongeldige gebieden uitgesloten worden.

spoiler:

Sorteren van de lijnen op lengte helpt enorm, omdat je eerst de langste lijnen bekijkt of ze kruizen. En die hebben de hoogste kans.

[Soultaker]

Thorwing schreef op dinsdag 9 december 2025 @ 15:48:
Vandaag beetje heen en weer gestruggled met een algoritme. Ik begon met het idee dat AWT mij kon helpen vandaag, maar kreeg dat niet werkend. Toen voor de sterren van vandaag nog even algoritme bedacht die natuurlijk werkt voor de opgave, maar vervolgens niet voor de gekke voorbeelden zoals mensen hier aangeven. Toen dat eenmaal werkte weer terug naar AWT en low and behold, het werkte.

Is het valsspelen? Wellicht...

Ik zag dat Apparaat9 op het leaderboard (wie is dat hier?) ook een bestaande polygon intersection library gebruikt had: day_09.py

Ergens een beetje flauw, aan de andere kant: don't hate te player, hate the game.

Marcj schreef op dinsdag 9 december 2025 @ 17:02:
Nou ja, lek. Ik heb aannames gedaan over de vorm.

Fair enough, dat hoort ook een beetje bij Advent of Code, en ik heb zelf natuurlijk ook bepaalde aannamen gedaan. Toch is het nuttig om ten minste na te denken over welke voorwaarden je vereist, anders snap je eigenlijk je eigen code niet.

[Friits]

Soultaker schreef op dinsdag 9 december 2025 @ 13:17:
[...]
Prachtige code, maar faalt op zoiets simpels als:

Sommige van de andere oplossingen die ik langs zien komen zijn net zo dubieus.

Guilty as charged, maar voor mij is het analyseren van de input en vervolgens gebruik (kunnen) maken van bepaalde eigenschappen, onderdeel van de puzzel. In mijn ogen niets dubieus aan, maar ik snap jouw perspectief. Ieder z'n ding

[P_Tingen]

Zelf vind ik het vooral leuk om te zien hoe anderen het probleem aanpakken en deel van de lol is ook om - als ik de oplossing eenmaal heb - nog eea bij te schaven.
Helaas zijn er weinig Progress 4gl ontwikkelaars die meedoen, maar ook door naar oplossingen te kijken in andere talen leer ik bij.

Wat me wel opvalt is dat ik in Progress echt heel veel zelf moet doen waar in andere talen een library voor is.

You lucky Bastards!

[Soultaker]

Ik zal in plaats van alleen maar te zeuren over de oplossingen van anderen ook eens mijn eigen oplossingsaanpak posten, dan kunnen anderen voor de verandering over mij zeuren.

Ten eerste de oplossing die ik vanmorgen gebruikt heb om het antwoord te vinden, en die wellicht het meest eenvoudig te begrijpen is: (spoilers zijn voor deel 2; deel 1 is zo simpel dat ik 'm niet uit hoef te leggen)

spoiler:

Je kunt de lijnstukken intekenen op een 2D grid. Als je zorgt dat er 1 cel ruimte omheen zit, dan kun je met een flood fill algoritme de cellen aan de buitenkant vinden. De overgebleven ongemarkeerde cellen zijn dan per definitie de binnenkant.

Dit werkt prima voor de voorbeeldinvoer, maar de officiële invoer is ongeveer 100,000 × 100,000 pixels groot, en als je dat expliciet in een 2D grid stopt, heb je ongeveer 10 GB geheugen nodig (1 byte per pixel) of tenminste 1,25 GB (1 bit per pixel).

Om het efficiënter te maken, comprimeer ik de coordinaten. Dit is een bekende truc die ook wel eerder langs gekomen is, bijvoorbeeld: dag 22 van 2021.

Voor wie niet bekend is met dit principe: het idee is dat alleen de coördinaten die daadwerkelijk in de invoer voorkomen relevant zijn, en dat je de ruimte daartussen kunt comprimeren tot 1 cel.

Zie bijvoorbeeld figuur 1 hier (externe link omdat spoiler tags de formatting verpesten).

De x-coordinaten in de invoer zijn: 3, 8, 10, 12. Dat betekent dat kolommen 1-2 en 4-7 in het grid identiek zijn, dus kun je samennemen, zoals te zien is in figuur 2.

Hetzelfde principe kun je toepassen op de rijen. In de voorbeelinvoer levert dat niets op, maar in de officiële invoer wel.

Het aantal rijen en kolommen dat overblijft is proportioneel aan het aantal coördinaten in de invoer. Als n het aantal regels in de invoer is, dan is de tijdcomplexiteit van het algoritme O(n⁴): n²/2 rechthoeken, en een grid van hooguit (2n)×(2n) pixels. In de praktijk is het sneller omdat de meeste rechthoeken ofwel een relatief klein deel van het gecomprimeerde grid beslaan, ofwel snel verworpen kunnen worden wanneer er een cel gevonden is die buiten de figuur ligt.

Code: 09.py

---

Dan nog een andere aanpak. Je kunt in plaats van een bitmap de invoer ook zien als polygoon, en dan voor elke mogelijke rechthoek kijken of hij 100% overlapt met die polygoon.

spoiler:

Het probleem hiermee is dat de figuur die beschreven wordt in de invoer een rand heeft met een dikte van 1, maar om de polygoon logica te implementeren wil je eigenlijk alleen de buitenranden van de figuur hebben, zodat de hele figuur strict binnen de polygoon ligt,

Je moet dus eerst de omtrek van die polygoon inclusief de rand vinden. Zie figuur 3 voor een voorbeeld.

De coordinaten in de invoer: 7,1 11,1 11,7 9,7 9,5 2,5 2,3 7,3

Worden dan hoekpunten van de polygoon: 7,1 12,1 12,8 9,8 9,6 2,6 2,3 7,3

Ik had wat moeite om te bedenken wanneer je precies wel of niet 1 op moet tellen bij de coordinaten. Ik heb uiteindelijk gewoon alle 8 situaties met de hand uitgeschreven (vier if-statements hier). Als iemand een simpelere/nettere manier weet om dit te doen hou ik me aanbevolen.

Op dit punt heb ik een simpele polygoon zónder rand. Om vervolgens te detecteren of een rechthoek volledig overlapt, heb ik gebruik gemaakt van de shoelace formula waarbij de coordinaten geclampt worden tot de rechthoek. Deze truc werkt echt alleen voor een rechthoek waarvan de randen parallel lopen aan de assen maar aangezien dat bij dit probleem toevallig zo is, is een ingewikkelder polygoonintersectiealgoritme niet nodig.

Code: 09-alt.py

In theorie zou de tweede oplossing sneller moeten zijn: O(n³) in plaats van O(n⁴). In de praktijk is het ook iets sneller maar het verschil is niet heel groot (1,1s vs 2,5s met PyPy; 11s vs 15s zonder).

[Jelle van Kraaij]

Ik ben niet verder gekomen dan part1, part2 is wel over mijn puzzellimiet.
Gisteren vondt ik part2 nog maar net te doen, vandaag was ik hoopvol door makkelijke part1 maar helaas
https://github.com/Jellev.../blob/main/day09/part1.py
Terug naar mijn usual business, embedded werk, praten met 4g/LTE modems...

[ Voor 38% gewijzigd door Jelle van Kraaij op 09-12-2025 20:44 ]

[Friits]

Ik heb zojuist trouwens wat optimalisaties gedaan en de uitvoertijd teruggebracht van 0.6 naar 0.06 seconden! Nog steeds houdt 'ie geen rekening met alle "randgevallen" van @Soultaker, maar het werkt prima voor mijn puzzel-input. And that's good enough for me!

spoiler:

Optimalisatie 1: Sorteer de "rode" rechthoeken aflopend op oppervlakte. Dan kan je stoppen zodra je je eerste "geldige" rechthoek hebt gevonden. Eventuele andere geldige rechthoeken zijn namelijk sowieso kleiner.

Optimalisatie 2: Sorteer de "groene" lijnen aflopend op lengte. We zoeken voor iedere "rode" rechthoek namelijk naar een lijn die de rechthoek doorsnijdt, en daarmee ongeldig maakt. Hoe eerder we zo'n lijn vinden, hoe sneller we door kunnen om de volgende rechthoek te testen.

Als je de puzzel-input hebt bekeken, weet je waarom deze optimalisatie een groot verschil maakt. En ook in het algemeen geldt: hoe langer de lijn, hoe groter de kans dat 'ie een willekeurige rechthoek doorsnijdt.

[ Voor 67% gewijzigd door Friits op 09-12-2025 22:05 ]

[Soultaker]

Gefeliciteerd @Friits, je was me vandaag te snel af! En eigenlijk heb ik het probleem nog steeds niet helemaal opgelost.

Voor deel 1

spoiler:

heb ik gewoon een breadth-first search geschreven. Alle combinaties van knoppen proberen had ook gekund (essentiële observatie: elke knop wordt hooguit 1 keer ingedrukt, want 2 keer drukken is equivalent aan 0 keer drukken, dus kun je gewoon alle 2^k varianten proberen).

Python code: 10A.py

Voor deel 2

spoiler:

probeerde ik eerst de aanpak van deel 1 te generaliseren. Dat was wat naïef van me, maar het leek me zo'n logische extensie van deel 1 dat het wel haast de bedoeling moest zijn. Niet dus: het aantal mogelijkheden is veel te groot.

Ik heb zelfs even snel A* in elkaar gehackt met een simpele heuristiek, maar ook dat hielp niet (genoeg) om problemen binnen een redelijke tijd op te lossen.

Daarna heb ik zitten kijken of ik bepaalde kenmerken van de invoer kon gebruiken; bij sommige invoeren heb je b.v. dat 1 energie-meter maar door 2 knoppen beïnvloed wordt. Dan kun je eerst alle combinaties van die twee knoppen proberen en dan heb je een simpeler probleem om recursief op te lossen. Maar helaas waren er ook invoerregels waarbij dat niet geldt.

Uiteindelijk heb ik een beetje flauw het probleem aan scipy.optimize. linprog gegeven, om ieder geval de ster binnen te halen.

Python code: 10B-scipy.py

Maar ik vind dat eigenlijk geen “echte” oplossing. Vandaag nog maar even nadenken over een betere aanpak. Ben benieuwd of iemand anders iets slimmers bedacht heeft!

[Friits]

@Soultaker: ik heb vandaag ook gewoon een ILP-solver geïmporteerd, want het her-implementeren daarvan is not my idea of fun.

Ik heb wel even geëxperimenteerd met een local search, maar dat kreeg ik (nog) nét niet lekker werkend.

[ Voor 103% gewijzigd door Friits op 10-12-2025 12:49 ]

[Janoz]

Ik dacht gisteren al dat we nog geen pathfinding hadden gehad. Deel 1 opgelost met BFS en daarna Dijkstra (omdat ik die toch al geimplementeerd had), en ja, deel 2....

Nog wat lopen aanklooien met A* maar ik heb uiteindelijk ook maar de handoek in de ring gegooid.
Het voelt inderdaad heel erg als vals spelen, maar toch Z3 in mijn oplossing gehangen.

[Corniel]

Ik heb vandaag ook maar Z3 in de strijd gegooid...

spoiler:

Ik kreeg met een priority queue de voorbeelden wel snel opgelost. IK heb nog geprobeerd om op basis van het aantal bits in de buttons die eerst maximaal te doen, maar het schoot totaal niet op als je tot meer dan 200 kliks moet komen...

[Janoz]

Soultaker schreef op dinsdag 9 december 2025 @ 13:17:
Volgens mij doen jullie allemaal maar wat, zolang het juiste antwoord er uit rolt, ook al is het algoritme zo lek als een mandje

Case in point:

[...]

Prachtige code, maar faalt op zoiets simpels als:

1,1
9,1
9,9
7,9
7,3
3,3
3,9
1,9

(Correcte antwoord: 27, niet 81.)

Sommige van de andere oplossingen die ik langs zien komen zijn net zo dubieus.

Met een kleine aanpassing die nauwelijks invloed op de totale performance heeft kan ik nu ook zien wanneer een oplossing volledig buiten de tegels valt

https://github.com/Janoz-...edf721582c6369929e056d229

Runtime van de exhte opdrachten is nog steeds 25ish ms

[Marcj]

Vandaag was wel een uitdaging, maar ik heb een oplossing.

spoiler:

Het komt er op neer dat ik een "poor-mans" trage linear solver heb gemaakt, met wat aannames op deze input.

Op het moment doet hij er echter wel 4 minuten over om tot een resultaat te komen. Ik hoop dat ik nog wat optimalisaties vind om het behoorlijk te versnellen.