Advent of Code 2020

[Soultaker]

Dricus schreef op woensdag 23 december 2020 @ 14:10:

spoiler:

Ik had precies zo'n oplossing in Kotlin geïmplementeerd, maar die was significant langzamer dan de expliciete linked list. Misschien deed ik nog iets niet handig, ik weet het niet meer.

Mogelijk een ArrayList<Integer> gebruikt in plaats van een primitieve int array? In het eerste geval kan boxing/unboxing je een hoop performance kosten (al kun je dat ook vermijden als je zorgvuldig code). In het tweede geval kan ik me eigenlijk niet voorstellen dat het trager is.

[Woy]

Soultaker schreef op woensdag 23 december 2020 @ 13:58:
Oplossing voor dag 23 in Python die in een halve seconde loopt.

spoiler:

Ik zie dat veel mensen een expliciete linked list gemaakt hebben, maar dat is voor dit probleem helemaal niet nodig: je kunt de cirkel implementeren met een eenvoudige integer array. Veel simpeler én sneller.

spoiler:

Ja mijn oplossing is nu vergelijkbaar, hoewel ik een array met een struct met twee ints heb, die overhead van de struct zou er inderdaad nog uit kunnen, maar ik vermoed dat het niet heel veel winst op zal leveren qua execution time

[Varienaja]

Dag 23.

spoiler:

Ik had onderdeel A met een LinkedList gedaan. Voor onderdeel B was de .indexOf() aanroep natuurlijk te traag, want O(n). Dus de boel omgeschreven naar een ad-hoc zelfgeknutselde LinkedList met lookup-array.

Ik heb lang gekeken of ik voor B niet toch de LinkedList van Java kon gebruiken, door bijvoorbeeld een Array van ListIterators te bewaren voor de snelle lookup. Maar dat feest ging niet door, omdat ze dan allemaal in paniek raken en ConcurrentModificationExceptions gooien. Ik heb er nog over nagedacht om de node(int) methode te overschrijven, maar vond het ook zo lelijk om dan een complete kopie van java.util.LinkedList te maken, zodat ik de package-protected methode kan overschrijven door een lookup ipv een sequential scan.

Ik heb dus de ad-hoc LinkedList maar laten zitten in de opgeschoonde code.

[Anoniem: 511810]

Hier loop ik toch tegen de limieten van een geinterpreteerde taal (Matlab) aan...
versie met copy lijsten : 56 uur (schatting
versie met indexering voor linking en lookup. toch nog ~90 seconden. al wel niet heel veel sneller gaan met matlab, maar houd me aanbevolen...

[armageddon_2k1]

DataGhost schreef op woensdag 23 december 2020 @ 11:45:
[...]

Wat er in je spoiler staat heb ik in 18 korte regeltjes python staan dus "geen zin om te implementeren", tsja...

Dag 23 in Kotlin

Dat weet ik Maar ik had geen zin om nog verder achter de computer te zitten.

Doet er 11 sec over. Mijn shortcut is niet erg snel denk ik. Ach pech.

[ Voor 19% gewijzigd door armageddon_2k1 op 23-12-2020 15:45 ]

[Dricus]

Soultaker schreef op woensdag 23 december 2020 @ 14:20:
Mogelijk een ArrayList<Integer> gebruikt in plaats van een primitieve int array? In het eerste geval kan boxing/unboxing je een hoop performance kosten (al kun je dat ook vermijden als je zorgvuldig code). In het tweede geval kan ik me eigenlijk niet voorstellen dat het trager is.

Je hebt helemaal gelijk! Ik gebruikte Array<Int>. Nu ik een native int array gebruik (IntArray) is het veel sneller: ±220 milliseconden .

[armageddon_2k1]

Zo, ik ben ook van 11 sec naar 200ms gegaan.

IntArray in Kotlin ftw!

Weer wat geleerd

Wat wel fucking vervelend is is dat m’n IntelliJ besloten heeft helemaal naar de klote te gaan. Autocomplete, errors, allemaal supertraag of helemaal fout, waardoor code kloppen geen lolletje is.

Binnenkort m’n Mac maar eens opnieuw installeren wat ik van plan was.

[ Voor 59% gewijzigd door armageddon_2k1 op 23-12-2020 16:06 ]

[ydderf]

Hmmm, vandaag gaat deel 2 iets boven mijn kennis niveau om een redelijke performance te krijgen. Zegmaar dat je de tijd beter in uren kunt uitdrukken dan in msec.
Eerste opdracht lekker simpel met int array gedaan. Daarna deel twee omgezet naar een List met de onderstaande logica.

spoiler:

De eerste vier waardes onthouden en verwijderen. Waarde twee t/m vier op de juiste plek tussenvoegen en de eerste waarde weer achteraan toevoegen.

En een hashtable kan je hiervoor niet gebruiken als ik het goed begrijp, aangezien deze geen gegarandeerde volgorde heeft.

[Woy]

@ydderf

spoiler:

het is goed mogelijk om data in meerdere datastructuren tegelijk zetten. Mijn eerste versie had voor de daadwerkelijke Cups een LinkedList structuur, die is handig omdat je daar elementen kunt toevoegen/verwijderen zonder dat je alle andere elementen moet herordenen zoals in bijvoorbeeld een array.

Daarnaast had ik een dictionary om snel aan de hand van een value de juiste LinkedListNode op te zoeken.

Op deze manier gebruik je meerdere datastructuren voor hun sterke eigenschappen.

Zoals @Soultaker opmerkt is het echter ook mogelijk om met een enkele array van integers op te lossen. De index van de array is het element, de value is de verwijzing naar het volgende element.

[ Voor 7% gewijzigd door Woy op 23-12-2020 18:50 ]

[ydderf]

Het idee achter de oplossing van Soultaker is me duidelijk en met de eerste opzet komt de tijd al onder de twee seconde. Helaas alleen het antwoord nog niet goed, dus dat word morgen nog ff puzzelen...

[ZieglerNichols]

Anoniem: 511810 schreef op woensdag 23 december 2020 @ 15:13:
Hier loop ik toch tegen de limieten van een geinterpreteerde taal (Matlab) aan...
versie met copy lijsten : 56 uur (schatting
versie met indexering voor linking en lookup. toch nog ~90 seconden. al wel niet heel veel sneller gaan met matlab, maar houd me aanbevolen...

Ik had de limieten van Matlab ook al snel door voor deel 2, dus ben maar naar Python geswitched. Matlab is geweldig voor snel testen van code en voor de eerste 2 weken van AoC. Daarna beginnen de nadelen van geïnterpreteerde talen sneller duidelijk te worden. Toch begin ik altijd met Matlab voor AoC.

[StefanLemmens]

Het is toch vooral een kwestie van het probleem juist aan te pakken. In LabVIEW heb ik geen List of iets dergelijks maar met 1 array van integers slaag ik er toch in om de juiste uitkomst te bekomen in 380 msec.

[armageddon_2k1]

@ZieglerNichols @Anoniem: 511810 Python is ook een interpreted language.

Dat MatLab traag is heeft niet direct heel veel te maken met interpreted of niet, maar meer waar het voor geoptimaliseerd is. Voor matrix-calculaties worden onderliggend gewoon de BLAS en LAPACK libraries aangewend.

Dus als je je probleem in mooie matrix / vector oplossingen kan schrijven is het bloedje snel.
Daarnaast zie ik op Reddit meer dan genoeg oplossingen in MatLab die snel zijn

[ Voor 10% gewijzigd door armageddon_2k1 op 23-12-2020 21:04 ]

[ZieglerNichols]

armageddon_2k1 schreef op woensdag 23 december 2020 @ 21:03:
@ZieglerNichols @Anoniem: 511810 Python is ook een interpreted language.

Dat MatLab traag is heeft niet direct heel veel te maken met interpreted of niet, maar meer waar het voor geoptimaliseerd is. Voor matrix-calculaties worden onderliggend gewoon de BLAS en LAPACK libraries aangewend.

Dus als je je probleem in mooie matrix / vector oplossingen kan schrijven is het bloedje snel.
Daarnaast zie ik op Reddit meer dan genoeg oplossingen in MatLab die snel zijn

Ja, dat is waar. Ik denk dat de opdracht voor vandaag wat lastiger is te doen met een mooie matrix-oplossing, maar voor de meeste andere dagen was Matlab zeer goed te doen.

Ik zag nu net ook dat Matlab enige ondersteuning heeft voor een linked List. Geen idee hoe snel dat is, maar het kan dus wel.

[Anoniem: 511810]

ZieglerNichols schreef op woensdag 23 december 2020 @ 21:13:
[...]


Ja, dat is waar. Ik denk dat de opdracht voor vandaag wat lastiger is te doen met een mooie matrix-oplossing, maar voor de meeste andere dagen was Matlab zeer goed te doen.

Ik zag nu net ook dat Matlab enige ondersteuning heeft voor een linked List. Geen idee hoe snel dat is, maar het kan dus wel.

Ik heb een array van 1e6x4 gebruikt:

spoiler:

1e vector de startwaardes van de lijst
2e vector een verwijzing naar het volgende element
3e vector de index van de array zelf (al is deze niet per se nodig..)
4e vector de uitkomst van sort(array(:,1), zodat ik direct naar een waarde kan springen

vreemd genoeg kost deze oplossing met een double array de helft van de tijd als exact dezelfde code met int32 arrays en variabelen ?!?!

met de profiler gekeken wat eruit springt en dat is een any() operatie op een vector van de drie waardes waarmee de kaartwaarde-1 vergeleken moet worden. Kan het omschrijven naar () && () && () (met dus voorwaardelijke berekening) maar dat zal niet heel veel opschieten. (misschien 10% sneller.
Ik verwacht dat het opsplitsen van de 1e6x4 in 4x 1e6 (dus losse) verctoren wel iets zou kunnen helpen, maar ik verbaas me er dan wel over dat een Python oplossing zoveel sneller kan zijn (of ik heb toch ergens nog een voor de hand liggende optimalisatie niet gezien...)

[DataGhost]

armageddon_2k1 schreef op woensdag 23 december 2020 @ 21:03:
@ZieglerNichols @Anoniem: 511810 Python is ook een interpreted language.

Dat MatLab traag is heeft niet direct heel veel te maken met interpreted of niet, maar meer waar het voor geoptimaliseerd is. Voor matrix-calculaties worden onderliggend gewoon de BLAS en LAPACK libraries aangewend.

Dus als je je probleem in mooie matrix / vector oplossingen kan schrijven is het bloedje snel.
Daarnaast zie ik op Reddit meer dan genoeg oplossingen in MatLab die snel zijn

Python wordt wel eerst omgezet in bytecode en dat wordt uitgevoerd, dus puur interpreted is het ook weer niet. Dan heb je ook nog PyPy, wat er een JIT compiler overheen gooit. Mijn python-oplossing is nu in 2.3 sec klaar met de standaard python-runtime, met PyPy duurt het nog maar 410ms. Ter vergelijking, mijn oplossing in C++ (eigenlijk alleen maar C) heeft 150ms nodig dus dat is in vergelijking behoorlijk goed.

Verder helemaal met je verhaal eens, dus @ZieglerNichols het hangt er helemaal van af wat voor datastructuren je gebruikt voor de taal en eventueel zelfs interpreter die je gebruikt. Alles wat native al doet wat je wilt is waarschijnlijk veel sneller geïmplementeerd dan wanneer je het zelf moet schrijven in de taal waarin je bezig bent. Maar de manier van implementatie maakt daarbij ook nog veel uit. Zo heb ik op mijn 9 jaar oude laptop de volgende looptijden:

spoiler:

python3 met een list: 6.8s
python3 met een array: 5.7s
pypy3 met een list: 1.0s
pypy3 met een array: 3.0s

Ze doen allemaal exact hetzelfde maar gebruiken een andere interpreter, en daarbij is te zien dat de implementatie van de datastructuren dusdanig verschillend is dat performancewinst voor de ene een performanceverlies voor de andere betekent. En beide datastructuren zijn native, maar hebben toch verschillende performance. Dus dat iets op een manier werkt wil niet zeggen dat er geen andere manier is die hetzelfde kan, maar sneller. Je weet alleen nog niet hoe. Een native linkedlist zou zomaar een hoop performance voor je kunnen schelen, maar dat is niet de enige oplossing.

[ Voor 4% gewijzigd door DataGhost op 23-12-2020 21:59 ]

[ZieglerNichols]

Het leuke aan AoC vind ik dat AoC oplossingen niet hetzelfde doel hebben als productie-code genereren. Daarom kan Matlab soms veel tijd besparen. Veel bugs in AoC hebben bijvoorbeeld te maken met type overflow, omdat dit in productie code belangrijk is, maar daar heb ik in Matlab niks mee te maken. Ik definieer een variabele x, zonder type, en daar kan alles in. Ik weet dat dit in praktijk soms problemen kan geven, maar voor AoC werkt het goed!

[Dido]

Weer de eerste gold star hier vandaag

spoiler:

Hoeveelste game of life is dit? Volgens mij minmaal de derde... achteraf voelt het alsof een generieke game-of-life simulator de moeite waard was geweest
De eerder gebruikte taktiek om voor alle actieve tiles alle neigbours te markeren in plaats van voor elke mogelijke cel zijn actieve neighbours te tellen had ik al eerder ingezet en maakt het leven hier ook weer een stuk simpeler

[Varienaja]

spoiler:

Deze link https://www.redblobgames.com/grids/hexagons/ had ik nog van een vorige AoC. Het kostte me enige moeite om te ontdekken waarom mijn aantal zwarte tegels zo snel groeide. Ik rekende eerst naïef met 26 (3D ) buren in plaats van 6...

[Dido]

Varienaja schreef op donderdag 24 december 2020 @ 07:54:

spoiler:

Deze link https://www.redblobgames.com/grids/hexagons/ had ik nog van een vorige AoC. Het kostte me enige moeite om te ontdekken waarom mijn aantal zwarte tegels zo snel groeide. Ik rekende eerst naïef met 26 (3D ) buren in plaats van 6...

spoiler:

Overengineering
Ik heb mijn grid trouwens heel simpel gehouden door op de x-as altijd +/- 2 te doen, en in de andere vier richtingen zowel z als x met 1 op te schuiven. Dat levert de facto ook hexagons op, met "gaten" in de rijen. Verder was dit daardoor maar 75% procent van het werk tov vierkante cells (6 richtingen tegenover 8 ).
Enige bugje vandaag zat in een voorbereidende stap in dele 1. Ik verving eerst alle "nw" door "a", "ne" door "b", enzovoort, zodat ik daarna simpeler kon parsen. Door een copy/paste foutje verving ik echter twee keer dezelfde richting, wat voor heel vage antwoorden zorgde

[Varienaja]

Dido schreef op donderdag 24 december 2020 @ 08:02:

spoiler:

Enige bugje vandaag zat in een voorbereidende stap in dele 1. Ik verving eerst alle "nw" door "a", "ne" door "b", enzovoort, zodat ik daarna simpeler kon parsen. Door een copy/paste foutje verving ik echter twee keer dezelfde richting, wat voor heel vage antwoorden zorgde

O dat zijn vervelende situaties. Vooral als je, zoals ik, in de gauwigheid geen code bouwt om te visualiseren wat er eigenlijk aan de hand is.

[armageddon_2k1]

Dag 24 in Kotlin

Wel nog aardstraag voor Part 2 (24 sec). Moet even kijken hoe dat komt.
Was wel erg leuk! Niet echt moeilijk overigens, had het in 1x typen meteen goed.

EDIT:
Wederom een simpele wijziging van collection gaat ie van 24 sec naar 400ms.

[ Voor 18% gewijzigd door armageddon_2k1 op 24-12-2020 09:17 ]

[eamelink]

De eerste 80% was zo'n beetje de puzzel oplossen. De tweede 80% was ontdekken dat 'nul of meer dan twee' niet hetzelfde is als 'alles behalve één'

[Hydra]

Pfoe. Best ff mee bezig geweest. Eerst in deel 1 een denkfout en toen toch maar een fatsoenlijk hex grid geimplementeerd. Daarna in deel 2 nog een tijdje vastgezeten:

spoiler:

Je moet de 'border' steeds verder uitbreiden als je een hashmap gebruikt, en dat had ik over 't hoofd gezien.

Anyway; Dag 24 in Kotlin. Wel voor mijn opschoonrondje; heb ik pas vanavond tijd voor.

[armageddon_2k1]

Valt me wel op dat ik de laatste week overschakel van voornamelijk functioneel naar imperatief. Simpele while loops en assignments. Dat lijkt vaak ordegroottes sneller te zijn, volgens mij omdat Kotlin geen goede persistent collections heeft. In Scala kan ik me herinneren dat het vaak niet zo traag was.

Maar misschien heb ik gewoon te weinig FP ervaring.

[Woy]

Deze was weer erg eenvoudig, alleen in deel 2 las ik even verkeerd. Bij de eerste regel las ik het alsof de tiles black zouden blijven, maar ze moesten juist naar wit gedraaid worden.

https://github.com/rverst.../blob/main/Y2020/Day24.cs

[Dricus]

Dag 24 (Kotlin)

Deze was heel goed te doen. En inderdaad de derde game of life variant. Deze vond ik wel wat leuker dan de vorige, vanwege het hexagonal grid wat je moet maken.

De performance is nog abominabel, met 8,5 seconden voor deel 2. Ik ga nog even zelf kijken of ik wat slimmigheidjes verzinnen kan om dat beter te krijgen, voordat ik naar andere code ga kijken .

@armageddon_2k1 Dat doe ik inderdaad ook. Het klopt volgens mij dat Kotlin geen goede persistent collections heeft. De immutable varianten gebruiken voor zover ik gezien heb allemaal een copy-on-write strategie om een nieuwe collection te maken op basis van een bestaande + een wijziging. En da's niet zo efficiënt .

[Woy]

@armageddon_2k1 ik wissel een beetje tussen functioneel en imperatief, op zich zie ik niet hele grote performance verschillen als de aanpak hetzelfde is. Imperatief kan het meestal net iets snell omdat je vaak wat geheugen allocaties kunt voorkomen.

Het is een beetje afhankelijk van het probleem wat ik kies, vandaag weer wat meer functioneel, maar ook niet volledig, want de loop van 100 vind ik makkelijk lezen als daadwerkelijk loop.

[Dricus]

Woy schreef op donderdag 24 december 2020 @ 09:30:
@armageddon_2k1 ik wissel een beetje tussen functioneel en imperatief, op zich zie ik niet hele grote performance verschillen als de aanpak hetzelfde is. Imperatief kan het meestal net iets snell omdat je vaak wat geheugen allocaties kunt voorkomen.

Het is een beetje afhankelijk van het probleem wat ik kies, vandaag weer wat meer functioneel, maar ook niet volledig, want de loop van 100 vind ik makkelijk lezen als daadwerkelijk loop.

Het gaat hier vooral om het al-dan-niet gebruik maken van immutable/persistent collections. Bij échte FP talen (Scala, Clojure, etc) zijn die efficiënt geïmplementeerd met RRB trees en HAMTs. Kotlin heeft wel immutable collections, maar die zijn niet gemaakt om met echte functional style code gebruikt te worden.

[Woy]

Dricus schreef op donderdag 24 december 2020 @ 09:35:
[...]

Het gaat hier vooral om het al-dan-niet gebruik maken van immutable/persistent collections. Bij échte FP talen (Scala, Clojure, etc) zijn die efficiënt geïmplementeerd met RRB trees en HAMTs. Kotlin heeft wel immutable collections, maar die zijn niet gemaakt om met echte functional style code gebruikt te worden.

Tuurlijk dat werkt zeker mee, maar imperatief mapt gewoon directer naar de daadwerkelijke executie op de processor. Functioneel krijg je er toch een extra stuk abstractie overheen, die natuurlijk grotendeels/geheel weg-geoptimaliseerd kan worden door de compiler/runtime. Het zal zeker geen ordes van grootte schelen, maar ik heb het idee dat je voor de allerhoogste performance met imperatief toch net iets beter zit. Daar zou ik in productie code bijna nooit voor die reden voor kiezen, want leesbaarheid/onderhoudbaarheid en implementatie snelheid is in 99% van de gevallen gewoon veel belangrijker.

In bijvoorbeeld C#, maar waarschijnlijk ook Kotlin zal je voor het loopen over een enumeratie een extra object en dus memory allocatie hebben, met een for-loop heb je alleen een stack-allocatie van je iteratie counter.

[ Voor 9% gewijzigd door Woy op 24-12-2020 09:52 ]

[eamelink]

Dricus schreef op donderdag 24 december 2020 @ 09:35:
Het gaat hier vooral om het al-dan-niet gebruik maken van immutable/persistent collections. Bij échte FP talen (Scala, Clojure, etc) zijn die efficiënt geïmplementeerd met RRB trees en HAMTs. Kotlin heeft wel immutable collections, maar die zijn niet gemaakt om met echte functional style code gebruikt te worden.

Hmm, dat verbaast me. Ik heb de afgelopen tien jaar voornamelijk Scala geprogrammeerd, met zo af en toe een flinke hap Java. Kotlin heeft me nooit echt getrokken; hoewel het is een significant en strict betere Java is, vind ik de verbetering te beperkt om de voordelen van Java los te laten. Scala vind ik aantrekkelijk als veel expressievere taal op de JVM.

Is het gebruikelijk om bijvoorbeeld de (immutable) Eclipse Collections te gebruiken met Kotlin? Ik vind ze wel aantrekkelijk (ook in Java), maar toch gebruik ik ze zelden vanwege de mismatch tussen het overweldigende gebruik van de standaardlib collecties in Java overal en deze collecties.

Maar voor zulke standalone puzzeltjes zou het wel geschikt zijn

[Mschamp]

Day 24 C#
Veel te lang bezig geweest voor ik door had dat ik een probleem had met de 0.

[FrankMennink]

Dag 24 in Python

spoiler:

Leuke variant op de game of life's die we eerder hebben gezien. Daardoor beide delen in 1 keer kunnen submitten. Ook hier alleen de relevante (zwarte tegels) coordinaten opgeslagen in een set en voor deel 2 alle neighbours van de zwarte tiles gepakt als set van mogelijke tiles die flippen.

Code runt in 2.9s. Kan vast sneller, maar ik vind t prima zo

[ydderf]

Dag 23 deel 2 zojuist ook afgerond. Ofja, eigenlijk had ik hem gisteren al afgerond, maar mijn antwoord werd niet goed bevonden. Totdat me vanmorgen opviel dat mijn antwoord wel heel erg op het antwoord van het voorbeeld leek
Op naar dag 24....

[Dido]

ydderf schreef op donderdag 24 december 2020 @ 11:18:
Dag 23 deel 2 zojuist ook afgerond. Ofja, eigenlijk had ik hem gisteren al afgerond, maar mijn antwoord werd niet goed bevonden. Totdat me vanmorgen opviel dat mijn antwoord wel heel erg op het antwoord van het voorbeeld leek
Op naar dag 24....

Dat heb ik ook gehad ja. 's Ochtends met een brakke harses zitten debuggen tot je met de voorbeeldinput het gezochte antwoord vindt, drie keer controleren, en dan dat antwoord op de site invoeren.

En dan natuurlijk opnieuw gaan zitten debuggen met nog maar een kop koffie

[Dricus]

Zo, ik heb de 8,5 seconden terug weten te brengen naar 280 milliseconden.

spoiler:

Ik houd een set bij van coördinaten van zwarte tiles en een 2D array van het hele grid voor snelle lookup. De set van zwarte tiles + het grid gebruik ik om te kijken welke zwarte tiles er wit moeten worden. In plaats van het hele grid door te akkeren voor de witte tiles, maak ik op basis van de witte neighbors van de set van zwarte tiles een lijst van witte tiles die zwart moeten worden. Volg je het nog? De code is duidelijker denk ik .

[Anoniem: 511810]

spoiler:

Oplossingin matlab gedaan, als 'grid' een staggered grid gebruikt zodat ik de standaard functies (convolute) kan gebruiken:
[...1 0 1 0 1 0 1...
...0 1 0 1 0 1 0 etc.
de kernel is dan
kernel=[0 1 0 1 0; ...
1 0 0 0 1; ...
0 1 0 1 0;];

run time 1.15 s

[Woy]

Dricus schreef op donderdag 24 december 2020 @ 12:32:
Zo, ik heb de 8,5 seconden terug weten te brengen naar 280 milliseconden.

spoiler:

Ik houd een set bij van coördinaten van zwarte tiles en een 2D array van het hele grid voor snelle lookup. De set van zwarte tiles + het grid gebruik ik om te kijken welke zwarte tiles er wit moeten worden. In plaats van het hele grid door te akkeren voor de witte tiles, maak ik op basis van de witte neighbors van de set van zwarte tiles een lijst van witte tiles die zwart moeten worden. Volg je het nog? De code is duidelijker denk ik .

spoiler:

Hoezo hou je uberhaupt een grid bij? Ik loop gewoon door de lijst van zwarte tiles van de vorige heen, en bereken daar een adjacency map door. Alle tiles die in de hasmap van de vorige turn zitten en 1 of 2 keer voorkomen, of niet in de vorige map voorkomen en 2 keer voorkomen zijn de nieuwe tiles.

Runtime is bij mij ~150 ms, en valt nog wel wat te optimaliseren.

[Asgardian]

Je kan je functie om aanliggende cellen op te zoeken cachen, misschien dat dat nog iets scheelt?

[Woy]

@Asgardian ik heb wel een lijst van de deltas vanaf een cel, maar welke cellen je moet opzoeken verschilt elke dag weer. Plus op zich is het optellen van een delta bij een coordinaat niet zo'n zware operatie ( twee optellingen ).

[Woy]

Ik heb mijn oplossing even omgeschreven naar een imperatieve oplossing, en zit nu op de 65ms, het algoritme is verder niet veranderd. De fuctionlere versie was ook nog wel wat te optimaliseren overigens.

[armageddon_2k1]

@Dricus Wel apart, ik gebruik geen van die kunstgrepen en zit ook rond 300ms in Kotlin. Maar mutable hash maps etc gaan hielp enorm.

[Singelaar]

Even iets heel anders:
Ging er iemand anders ook stuk bij het definieren van de functie: count_black_neighbours()? Ik heb toch maar een andere naam gekozen...

[DataGhost]

Singelaar schreef op donderdag 24 december 2020 @ 15:45:
Even iets heel anders:
Ging er iemand anders ook stuk bij het definieren van de functie: count_black_neighbours()? Ik heb toch maar een andere naam gekozen...

Um, nee. Dat was bij mij gewoon een built-in method van de native datastructuur die ik gebruikte dus daar heb ik helemaal geen aparte functie voor nodig gehad. En tbh, racisme in een kerstpuzzel over tegeltjes zien is wel erg vergezocht.

spoiler:

Als we daar toch bezig zijn, bij mij is het len(black), volgens mij kan je daar ook nog wel wat stereotypes bij verzinnen

[ Voor 13% gewijzigd door DataGhost op 24-12-2020 15:50 ]

[Varienaja]

Dag 24 in Java.

spoiler:

Ik had eerst een HashMap<Point,Boolean> om te onthouden welke tile zwart en welke wit was. Bij het fatsoeneren heb ik hiervan een Set gemaakt, met daarin alleen de zwarte Points. Dat maakt alles veel eenvoudiger zeg

[Woy]

Singelaar schreef op donderdag 24 december 2020 @ 15:45:
Even iets heel anders:
Ging er iemand anders ook stuk bij het definieren van de functie: count_black_neighbours()? Ik heb toch maar een andere naam gekozen...

black tiles matter

[MerijnB]

MerijnB schreef op woensdag 23 december 2020 @ 10:21:
Ik heb een paar dagen niet zoveel tijd gehad, ben nu weer aan het inhalen, nog even een verlate vraag over day 19 part 2.
Kan iemand me vertellen waarom uit het voorbeeld "babbbbaabbbbbabbbbbbaabaaabaaa" als match zou gelden? Ik vind wel een match, maar die heb ik al voordat alle rules zijn afgelopen, dat geldt dan toch niet denk ik? Heeft iemand nog een app die log kan genereren over dit voorbeeld oid?
Hier een past van mijn log.

Nu het stof van vandaag een beetje gezakt is, iemand die me hier mee kan helpen? Tx!

[Varienaja]

MerijnB schreef op donderdag 24 december 2020 @ 17:21:
Nu het stof van vandaag een beetje gezakt is, iemand die me hier mee kan helpen? Tx!

Ik wil niet flauw doen hoor, maar er posten hier velen hun code. Ik zou zeggen doe er je voordeel mee: copy, paste, debug en vergelijk met je eigen code We blijven wel tweakers hé!

[Anoniem: 511810]

MerijnB schreef op donderdag 24 december 2020 @ 17:21:
[...]


Nu het stof van vandaag een beetje gezakt is, iemand die me hier mee kan helpen? Tx!

Volgens mij gaat het niet lukken alsje achter elkaar de rules gaat interpreteren (te langzaam,in ieder geval bij mij)

spoiler:

wat ik gedaan heb, en volgens mij iedereen?, is een grote regexp maken waar alle rules inzitten, en die loslaten op de individuele strings.
Moet ook, want je string moet aan alle regels voldoen die uiteindelijk in de lijst voorkomen en niet maar een subset. Het zou bijvoorbeeld kunnen zijn dat je string dan eigenlijk te kort is en er nog een stuk aan hoort).

Alsje wilt kun je mijn matlab code bekijken, linkje staat hierboven wel ergens. Daar zit ook dag 19 tussen. Deel1 heb ik op de 'lompe' manier opgelost en in matlabkun je rustig breakpoints zetten en de output bekijken.

[DataGhost]

Anoniem: 511810 schreef op donderdag 24 december 2020 @ 18:30:
[...]


Volgens mij gaat het niet lukken alsje achter elkaar de rules gaat interpreteren (te langzaam,in ieder geval bij mij)

spoiler:

wat ik gedaan heb, en volgens mij iedereen?, is een grote regexp maken waar alle rules inzitten, en die loslaten op de individuele strings.
Moet ook, want je string moet aan alle regels voldoen die uiteindelijk in de lijst voorkomen en niet maar een subset. Het zou bijvoorbeeld kunnen zijn dat je string dan eigenlijk te kort is en er nog een stuk aan hoort).

Alsje wilt kun je mijn matlab code bekijken, linkje staat hierboven wel ergens. Daar zit ook dag 19 tussen. Deel1 heb ik op de 'lompe' manier opgelost en in matlabkun je rustig breakpoints zetten en de output bekijken.

spoiler:

Lang niet iedereen. Ik had het direct al afgeschreven (met mij nog anderen) omdat het simpelweg geen reguliere grammatica is, dus die kan ook niet met een reguliere expressie beschreven worden. In deel 1 was het dat wel, maar je kon er donder op zeggen dat het in deel 2 niet het geval zou zijn, en dan moet je alsnog iets anders vanaf scratch gaan implementeren. Ook ging ik ervan uit (wederom ten onrechte) dat de input zodanig gevormd zou zijn dat het een regex van 1GB of groter zou opleveren na alle substituties, dus het leek me op meerdere vlakken onhandig om dat als implementatie te kiezen.

Dat er in de praktijk regex-engines zijn die niet-reguliere expressies accepteren betekent niet dat het dan opeens wel een reguliere expressie is. Daarom is m.i. in deel 2 de substitutie te "vriendelijk" gekozen waardoor het in pcre bijvoorbeeld nog steeds te doen is. Ik denk dat de bedoeling inderdaad was om in deel 1 mensen wat meer kennis te laten maken met reguliere expressies, maar dat in deel 2 duidelijk had moeten worden in welke gevallen die niet bruikbaar zijn.

@MerijnB je moet altijd een volledige match hebben. Een regel "a" "b" "b" matcht dus niet "a", "ab" of "abbb", maar alleen "abb". Afhankelijk van wat voor oplossingsrichting je gekozen hebt moet je waarschijnlijk opletten dat een "match" met een van de gesubstitueerde regels niet per se de juiste is. Probeer eerst even na te denken waarom dat zo is, anders heb ik een "spoiler" in de vorm van een voorbeeld wat ik eerder heb gemaakt, wat waarschijnlijk fout gaat met de code die je nu hebt.

[MerijnB]

Varienaja schreef op donderdag 24 december 2020 @ 18:29:
[...]
Ik wil niet flauw doen hoor, maar er posten hier velen hun code. Ik zou zeggen doe er je voordeel mee: copy, paste, debug en vergelijk met je eigen code We blijven wel tweakers hé!

Mij lijkt uitzoeken waar ik een fout in mijn code heb / waar ik de regels verkeerd interpreteer meer des tweakers dan iemand anders z'n code copy/pasten

Anoniem: 511810 schreef op donderdag 24 december 2020 @ 18:30:
[...]


Volgens mij gaat het niet lukken alsje achter elkaar de rules gaat interpreteren (te langzaam,in ieder geval bij mij)

Deel 1 ging prima en best vlot ook, deel 2 weet ik nog niet natuurlijk

DataGhost schreef op donderdag 24 december 2020 @ 19:02:
[...]

spoiler:

Lang niet iedereen. Ik had het direct al afgeschreven (met mij nog anderen) omdat het simpelweg geen reguliere grammatica is, dus die kan ook niet met een reguliere expressie beschreven worden. In deel 1 was het dat wel, maar je kon er donder op zeggen dat het in deel 2 niet het geval zou zijn, en dan moet je alsnog iets anders vanaf scratch gaan implementeren. Ook ging ik ervan uit (wederom ten onrechte) dat de input zodanig gevormd zou zijn dat het een regex van 1GB of groter zou opleveren na alle substituties, dus het leek me op meerdere vlakken onhandig om dat als implementatie te kiezen.

Dat er in de praktijk regex-engines zijn die niet-reguliere expressies accepteren betekent niet dat het dan opeens wel een reguliere expressie is. Daarom is m.i. in deel 2 de substitutie te "vriendelijk" gekozen waardoor het in pcre bijvoorbeeld nog steeds te doen is. Ik denk dat de bedoeling inderdaad was om in deel 1 mensen wat meer kennis te laten maken met reguliere expressies, maar dat in deel 2 duidelijk had moeten worden in welke gevallen die niet bruikbaar zijn.

@MerijnB je moet altijd een volledige match hebben. Een regel "a" "b" "b" matcht dus niet "a", "ab" of "abbb", maar alleen "abb". Afhankelijk van wat voor oplossingsrichting je gekozen hebt moet je waarschijnlijk opletten dat een "match" met een van de gesubstitueerde regels niet per se de juiste is. Probeer eerst even na te denken waarom dat zo is, anders heb ik een "spoiler" in de vorm van een voorbeeld wat ik eerder heb gemaakt, wat waarschijnlijk fout gaat met de code die je nu hebt.

Dank, daar kan ik wat mee, ga ik even naar kijken!

@DataGhost wat zou de uitkomst moeten zijn van je voorbeeld?

Nvm ik zie het (en je hebt ws gelijk).

[Varienaja]

Joepie! Dat was een eenvoudige uitsmijter. Nu kan ik terug naar bed en eindelijk uitslapen

Dag 25 in Java.

[ Voor 43% gewijzigd door Varienaja op 25-12-2020 06:25 ]

[Asgardian]

Leuke puzzel vandaag, vooral goed lezen. 3e op leaderboard geëindigd.

Moeilijkste dagen by far: monster messages waar ik bijna 7 uur over heb gedaan en de crab cubs, bijna 6 uur en de zeemonster puzzel (4 uur). Die drie nog eens goed bekijken hoe hier van te leren.

Hoogtepunt was de allergens puzzel (189), maar verder bijna altijd buiten de top 1000, (gemiddeld 2000, mediaan 1600). Alles voor dag 13 binnen 1 uur opgelost.

Was echt een belevenis, elke dag iets voor 6:00 opgestaan. Dan zijn 25 dagen wel veel. Maar met kinderen is dat enige rustige uurtje zo 's ochtends vroeg ook wel weer ideaal voor de puzzel.

Christofer Ohlsson en Niels gefeliciteerd met plek 1 en 2! Ennuh ik gebruik gewoon de 'stars' ordering :-)

[Dido]

Varienaja schreef op vrijdag 25 december 2020 @ 06:22:
Joepie! Dat was een eenvoudige uitsmijter. Nu kan ik terug naar bed en eindelijk uitslapen

En dan zit ik bij deel 2 alsnog gewoon 5 minuten die tekst te lezen, me afvragend wat ik moet doen

Maar, yeay Plek 5 En dat leaderboard heeft wel geholpen om (bijna) elke dag om 6 uur te beginnen!
Vanaf morgen gewoon uitslapen in mijn kerstvakantie

[ZieglerNichols]

Laatste dag in Matlab: https://pastebin.com/XAGLgDN2 . Was een makkelijke afsluiter! Het was weer erg leuk dit jaar. Blij met mijn 6e plek op de leaderboard!

[Dricus]

Dag 25 (Kotlin)

Fijn, zo'n lekker makkelijke uitsmijter.

spoiler:

Ik zat ook nog uitgebreid deel 2 te lezen in de verwachting dat er nog meer zou komen .

[Woy]

Inderdaad dag25 is een makkie: https://github.com/rverst.../blob/main/Y2020/Day25.cs

Ik ben benieuwd of er nog een shortcut mogelijk is, of inderdaad gewoon lekker makkelijk brute-forcen.

[Woy]

@Dricus nette oplossing! Ik heb gewoon de simpele lelijke versie gedaan, geen zin om netter te maken vandaag, ik moet mijn kado's nog in gaan pakken

[Dricus]

Woy schreef op vrijdag 25 december 2020 @ 07:46:
@Dricus nette oplossing! Ik heb gewoon de simpele lelijke versie gedaan, geen zin om netter te maken vandaag, ik moet mijn kado's nog in gaan pakken

Dankje! Ik had tussen het marineren van de veganistische kalfshaasparfait en het opschuimen van de pastinaakbouillon nog net even tijd om mijn code een beetje op te schonen.

[Hydra]

Nou dit is wel de slechtste uitleg ooit. WTF.

spoiler:

Edit: Ik heb naar jullie code gekeken en ik snap nu wat er gebeurt, maar ik snap nog steeds echt de uitleg hierbij niet. Ik kom vanuit de tekst echt niet uit op dat beide dingen tegelijkertijd in de loop gebeuren. Ben ik nu zo dom?

Helaas als je eenmaal de code van een ander gezien hebt, is het extreem triviaal. En ook geen leuke deel 2. Nouja. Jammer.

[ Voor 80% gewijzigd door Hydra op 25-12-2020 08:14 ]

[Hydra]

En de mijne.

[Hydra]

Dricus schreef op vrijdag 25 december 2020 @ 07:23:
Dag 25 (Kotlin)

Fijn, zo'n lekker makkelijke uitsmijter.

Mooi! Ik ga 'em later nog ombouwen denk ik. Eerst 24 even opschonen nog.

[armageddon_2k1]

Dag 25 in Kotlin

Deze was wel heeeeeeeeeel erg makkelijk zeg. In 5 minuten opgeschreven en in 1x goed (nu nog even opschonen). Kwestie van even goed lezen, maar de tekst was vrij duidelijk.

Anyway, lekker makkelijk einde zodat ik niet de hele dag met mijn hoofd ergens anders ben De eerste keer dat ik AoC helemaal gedaan heb!

Fijne kerst allemaal!

[armageddon_2k1]

Dricus schreef op vrijdag 25 december 2020 @ 07:23:
Dag 25 (Kotlin)

Fijn, zo'n lekker makkelijke uitsmijter.

spoiler:

Ik zat ook nog uitgebreid deel 2 te lezen in de verwachting dat er nog meer zou komen .

Deze is heel mooi.

[Woy]

Hydra schreef op vrijdag 25 december 2020 @ 07:59:

spoiler:

Edit: Ik heb naar jullie code gekeken en ik snap nu wat er gebeurt, maar ik snap nog steeds echt de uitleg hierbij niet. Ik kom vanuit de tekst echt niet uit op dat beide dingen tegelijkertijd in de loop gebeuren. Ben ik nu zo dom?

spoiler:

Er staat ook niet dat het beide tegelijk in de loop gebeurt. Maar de eerste stap is de public key vinden, en dan dezelfde transformatie met jouw loopcount op de public key van het andere device. Aangezien je twee maal dezelfde transformatie moet doen met jouw loopcount ( eenmaal met subject 7 om jouw key te vinden, en eenmaal met subject public key van het andere device ) kun je dat direct in dezelfde loop doen. Op het moment dat je jouw key vindt, heb je ook precies de private key.

[Hydra]

armageddon_2k1 schreef op vrijdag 25 december 2020 @ 08:32:
Deze was wel heeeeeeeeeel erg makkelijk zeg. In 5 minuten opgeschreven en in 1x goed (nu nog even opschonen). Kwestie van even goed lezen, maar de tekst was vrij duidelijk.

Okay, ligt aan mij dus

[Hydra]

armageddon_2k1 schreef op vrijdag 25 december 2020 @ 08:35:
Deze is heel mooi.

Ja, het stoort me dat ik er zelf niet opkom een loop tail-recursive te maken. Moet ik nog aan werken.

[armageddon_2k1]

Hydra schreef op vrijdag 25 december 2020 @ 08:51:
[...]


Ja, het stoort me dat ik er zelf niet opkom een loop tail-recursive te maken. Moet ik nog aan werken.

Ik kom er zelf ook niet op. Vind het mooi wat Dricus doet. Ligt er maar net aan waar je voorkeur ligt denk ik. Vanwege ontwikkelsnelheid maak ik nou eerst altijd gewoon imperatief loopje. Daarna bouw ik het om. Ik ontwikkel vaak door wat code neer te plempen en breakpoints te zetten en er doorheen te stappen om dubbel te checken. Als ik dan megafunctioneel met al die Kotlin extension functies bezig ben is dat een stuk lastiger vind ik.

Als het allemaal werkt en gecheckt wordt met wat tests ga ik het ombouwen.

Daarnaast vind ik sequences nu eventjes erg leuk.

[ Voor 3% gewijzigd door armageddon_2k1 op 25-12-2020 08:57 ]

[Hydra]

armageddon_2k1 schreef op vrijdag 25 december 2020 @ 08:56:
Ik kom er zelf ook niet op. Vind het mooi wat Dricus doet. Ligt er maar net aan waar je voorkeur ligt denk ik. Vanwege ontwikkelsnelheid maak ik nou eerst altijd gewoon imperatief loopje. Daarna bouw ik het om.

Ja, zo begin ik ook. Mijn eerste opzet is vrijwel altijd iteratief. Zo zie je maar dat 22 jaar imperatief programmeren behoorlijk ingesleten zit En het gaat mij er ook niet zozeer om dat ik vind dat alles perse tailrecursive moet, ik stoor me eraan dat ik niet op het idee kom Maar heb dankzij de code van @Dricus hier nu wel wat meer gevoel voor ontwikkeld.

Ik ontwikkel vaak door wat code neer te plempen en breakpoints te zetten en er doorheen te stappen om dubbel te checken. Als ik dan megafunctioneel met al die Kotlin extension functies bezig ben is dat een stuk lastiger vind ik.

Als het allemaal werkt en gecheckt wordt met wat tests ga ik het ombouwen.

Daarnaast vind ik sequences nu eventjes erg leuk.

Ik knal voor deel 1 zo snel mogelijk wat code neer en check 't tegen de voorbeeld input. Werkt 't; mooi. Zo niet; breakpoints en erdoorheen steppen. Vooral bij de eerste opdrachten gaat 't meestal in 1 keer goed. Maar in de latere dagen gaat dat tegen me werken omdat ik de tekst verkeerd geinterpreteerd heb. Dat leidt dan vaak tot aardig wat frustraties aan mijn kant.

Het is ook een heel andere manier van werken dan je normale 'day to day' werk. Ik merk wel dat ik vaak te snel wil. Vanochtend ook. Ik begrijp ook echt nog steeds de tekst niet. Maargoed; ben altijd al beter geweest in formules lezen dan ellenlange teksten.

[Mschamp]

Ben er ook geraakt. Deel 2 heeft wel veel te lang geduurd. Eerste keer dat ik deelnam. Proficiat iedereen en
bedankt. Heel leuk om te doen en op deze manier bij te leren. Fijne Kerst!

[ Voor 18% gewijzigd door Mschamp op 25-12-2020 09:48 ]

[Dricus]

Hydra schreef op vrijdag 25 december 2020 @ 09:10:
Ja, zo begin ik ook. Mijn eerste opzet is vrijwel altijd iteratief. Zo zie je maar dat 22 jaar imperatief programmeren behoorlijk ingesleten zit En het gaat mij er ook niet zozeer om dat ik vind dat alles perse tailrecursive moet, ik stoor me eraan dat ik niet op het idee kom Maar heb dankzij de code van @Dricus hier nu wel wat meer gevoel voor ontwikkeld.

Het is nooit te laat om te leren! Ik programmeer al zo'n 30 jaar bijna uitsluitend in imperatieve talen en heb me de functional style pas in de laatste paar jaren meer eigen kunnen maken. Daarbij heeft het enorm geholpen dat de meeste mainstream imperatieve talen zo veel concepten uit FP overgenomen hebben!

Ik knal voor deel 1 zo snel mogelijk wat code neer en check 't tegen de voorbeeld input. Werkt 't; mooi. Zo niet; breakpoints en erdoorheen steppen. Vooral bij de eerste opdrachten gaat 't meestal in 1 keer goed. Maar in de latere dagen gaat dat tegen me werken omdat ik de tekst verkeerd geinterpreteerd heb. Dat leidt dan vaak tot aardig wat frustraties aan mijn kant.

Ik werk al heel wat jaren met Test Driven Development. Daarmee leer je jezelf aan om in kleine stappen te denken en tussenresultaten te valideren. Voor AoC heb ik de moeilijkere puzzels ook veelal in kleine stapjes aangepakt. Daardoor houd je het overzicht over de code die je maakt en ben je meer bezig met het oplossen van het probleem, dan met het worstelen met je code.

Het is ook een heel andere manier van werken dan je normale 'day to day' werk. Ik merk wel dat ik vaak te snel wil. Vanochtend ook. Ik begrijp ook echt nog steeds de tekst niet. Maargoed; ben altijd al beter geweest in formules lezen dan ellenlange teksten.

Dat is wel erg herkenbaar! Mijn haast zat hem vooral in onzorgvuldig lezen, of de return 0 vergeten te vervangen door de echte oplossing .

[Hydra]

Dricus schreef op vrijdag 25 december 2020 @ 09:29:
Het is nooit te laat om te leren! Ik programmeer al zo'n 30 jaar bijna uitsluitend in imperatieve talen en heb me de functional style pas in de laatste paar jaren meer eigen kunnen maken. Daarbij heeft het enorm geholpen dat de meeste mainstream imperatieve talen zo veel concepten uit FP overgenomen hebben!

Dat doe ik ook wel hoor. Ik werk als sinds Java 8 op een meer functionele manier en vooral in Kotlin gebruik ik veel map, filter, etc. Ik had 't ook specifiek over dit soort opdrachten waarbij je een loop moet doen; dan kom ik niet snel op 't idee dit tail-recursive te doen. Recursion zelf natuurlijk wel, maar de stap om van een loop naar specifiek tail recursion te gaan zit er nog niet in. Ook omdat dat soort dingen bij de meeste collega's een "WTF is deze?" reactie teweeg zou brengen

Ik werk al heel wat jaren met Test Driven Development. Daarmee leer je jezelf aan om in kleine stappen te denken en tussenresultaten te valideren.

Ik ook hoor. Alleen ben je dan langer bezig. Dus ik gok er eerst op dat ik 't in 1 keer goed heb (want dan heb je in 5-10 minuten een oplossing). Lukt dat niet, dan moet ik op de 'juiste' manier aan de gang. En dan ben je een stuk langer bezig vaak.

En ik zie dan dat die gok de eerste 7 dagen ofzo werkt, maar daarna niet meer, omdat de opdrachten net te complex zijn om in 1 keer "YOLO" de code uit te schrijven.

Dat is wel erg herkenbaar! Mijn haast zat hem vooral in onzorgvuldig lezen, of de return 0 vergeten te vervangen door de echte oplossing .

Of gewoon de voorbeeldinput nog laten staan en daarvoor het resultaat te submitten En dan moet je een minuut wachten

[Varienaja]

Dido schreef op vrijdag 25 december 2020 @ 06:48:
En dat leaderboard heeft wel geholpen om (bijna) elke dag om 6 uur te beginnen!
Vanaf morgen gewoon uitslapen in mijn kerstvakantie

Ja zeg dat wel. Mooi iedere dag om kwart voor zes op. Wassen, aankleden en puzzelen! Zonder leaderbord had ik dat niet gedaan. En zonder jullie hulp en inspiratie had ik het ook niet tot het einde volgehouden. Mijn vrouw is blij dat deze bevlieging over is. En ben ook blij dat de wekker uit kan.

Iedereen bedankt voor het meedoen en meeposten. Prettige feestdagen allemaal!

[ppx17]

Varienaja schreef op vrijdag 25 december 2020 @ 10:10:
[...]
Ja zeg dat wel. Mooi iedere dag om kwart voor zes op. Wassen, aankleden en puzzelen! Zonder leaderbord had ik dat niet gedaan. En zonder jullie hulp en inspiratie had ik het ook niet tot het einde volgehouden. Mijn vrouw is blij dat deze bevlieging over is. En ben ook blij dat de wekker uit kan.

Iedereen bedankt voor het meedoen en meeposten. Prettige feestdagen allemaal!

Haha, dit vooral ja. Morgen de eerste keer een beetje uitslapen deze vakantie. Het was weer erg leuk om een beetje hoog in het leaderboard te blijven.

[Hydra]

Varienaja schreef op vrijdag 25 december 2020 @ 10:10:
Iedereen bedankt voor het meedoen en meeposten. Prettige feestdagen allemaal!

Hetzelfde! Ook aan de rest Ga het wel missen denk ik Ben uit 'pure ellende' maar begonnen met 2015 omzetten naar Kotin

[Hydra]

ppx17 schreef op vrijdag 25 december 2020 @ 10:11:
Haha, dit vooral ja. Morgen de eerste keer een beetje uitslapen deze vakantie. Het was weer erg leuk om een beetje hoog in het leaderboard te blijven.

Dat viel vies tegen. Voorgaande jaren ben ik redelijk hoog geeindigd maar een grote groep fanatiekelingen + 3 dagen ziek zijn, en je zit op plek 30

[Woy]

Pff, voor het leaderboard kan ik mij echt niet opwinden. Ik vind het puur leuk om de puzzels op te lossen, had er dan ook echt geen haast mee, en ben er ook zeker niet eerder voor opgestaan

[Dricus]

Hydra schreef op vrijdag 25 december 2020 @ 10:08:
Dat doe ik ook wel hoor. Ik werk als sinds Java 8 op een meer functionele manier en vooral in Kotlin gebruik ik veel map, filter, etc. Ik had 't ook specifiek over dit soort opdrachten waarbij je een loop moet doen; dan kom ik niet snel op 't idee dit tail-recursive te doen. Recursion zelf natuurlijk wel, maar de stap om van een loop naar specifiek tail recursion te gaan zit er nog niet in. Ook omdat dat soort dingen bij de meeste collega's een "WTF is deze?" reactie teweeg zou brengen

Ja, mee eens. Het zal nog wel even duren voor dat dat mainstream wordt. Kotlin is voor zover ik weet tussen de andere grote imperatieve talen wel een vreemde eend in de bijt met zijn support voor tail call optimization. Hmm, misschien ga ik over dit onderwerp op het werk eens een show & tell geven ter bevordering van de mainstreamisering van tailrec .

[Dricus]

Oh, en dank voor de leuke interactie die we hier gehad hebben. Ik vond het erg leuk en leerzaam! Hele fijne feestdagen toegewenst!

[Woy]

Dricus schreef op vrijdag 25 december 2020 @ 10:18:
[...]

Ja, mee eens. Het zal nog wel even duren voor dat dat mainstream wordt. Kotlin is voor zover ik weet tussen de andere grote imperatieve talen wel een vreemde eend in de bijt met zijn support voor tail call optimization. Hmm, misschien ga ik over dit onderwerp op het werk eens een show & tell geven ter bevordering van de mainstreamisering van tailrec .

Ja, ik vind het jammer dat dat niet in C# zit, de CLR schijnt er wel support voor te hebben.

[Dricus]

Woy schreef op vrijdag 25 december 2020 @ 10:33:
Ja, ik vind het jammer dat dat niet in C# zit, de CLR schijnt er wel support voor te hebben.

Dat klopt. De F# compiler ondersteunt wel tail call optimization.

[Daanoz]

Dido schreef op vrijdag 25 december 2020 @ 06:48:
[...]
En dat leaderboard heeft wel geholpen om (bijna) elke dag om 6 uur te beginnen!

Haha, dat was dit jaar voor mij juist een drama... Normaal gesproken vroeg de deur uit om de files voor te zijn, dat hoeft dit jaar niet, dan is het heel verleidelijk om toch nog wat langer te blijven liggen.

[Reynouts]

Zo, dat was weer een leuk jaar. Het viel me dit jaar op dat de puzzels over het algemeen iets makkelijker waren dan afgelopen jaren en er geen echte afhankelijkheden in de dagen zaten. Ook ontbrak dit jaar graph search, wat vorig jaar overdadig aanwezig was (net als de assembly). Ik had het idee dat door de moeilijkheidsgraad en de onafhankelijkheid ook meer mensen door bleven gaan in tegenstelling tot vorig jaar.

Al met al vond ik dit de perfecte workload als dagelijks puzzeltje. Dag 13 kostte me wel veel tijd op die desbetreffende zondag en over dag 20 heb ik langer dan een dag gedaan, mede omdat ik een aantal dagen ziek was. Maar geen van de puzzels waren onmogelijk, zonder dat je een vaag wiskundig truukje kende.

Ook leuk dat de simpele puzzels hier nog verder uitgewerkt, geoptimaliseerd en verbeterd werden door elkaars feedback en ideeën, gaaf!

Bedankt allemaal, een fijne kerst en tot volgend jaar!

[ Voor 4% gewijzigd door Reynouts op 25-12-2020 11:03 ]

[Soultaker]

Dag 25 in Wolfram Alpha (voorbeeld invoer, maar zelfde principe werkt ook voor de officiële test data!).

(Echte oplossing in Python.)

Vond het wel leuke puzzels dit jaar. Helaas hier en daar wat herhaling t.o.v. vorig jaar en zelfs eerder dit jaar (cellular automata aka Conway's Game of Life), maar het is ook niet eenvoudig om elk jaar 25 originele problemen te verzinnen.

Ik was begonnen met het oplossen van de problemen in Haskell. Ik ben nu halverwege dus daar ben ik de rest van het jaar nog wel zoet mee, denk ik.

[ Voor 3% gewijzigd door Soultaker op 25-12-2020 16:36 ]

[ydderf]

Laten we het er voor vandaag maar op houden, dat de tekst lezen lastiger is dan de uiteindelijke code.
Ik had eigenlijk niet verwacht zo ver te komen, dus kan straks tevreden aan het kerst diner. Helaas wegens tijdgebrek drie sterren nog niet binnen, maar dat ga ik binnenkort nog wel proberen recht te trekken. Ik vond het leuk om te doen en heb her en der nog wat kunnen opsteken van de mede Tweakers in dit topic!

[Soultaker]

ydderf schreef op vrijdag 25 december 2020 @ 15:42:
Laten we het er voor vandaag maar op houden, dat de tekst lezen lastiger is dan de uiteindelijke code.

spoiler:

Eigenlijk hoef je loopSizeDoor helemaal niet te berekenen, hè

[ydderf]

Soultaker schreef op vrijdag 25 december 2020 @ 16:38:
[...]

spoiler:

Eigenlijk hoef je loopSizeDoor helemaal niet te berekenen, hè

Klopt, is eigenlijk een beetje overbodige bouwpuin of een voorbereiding voor een extra check .
Ik ben voor het laatste gegaan....

Tevens dag 24 deel 2 nog ff afgerond. Al heeft hij wel een minuutje nodig om de uitkomst te berekenen, vind ik dat voor de 1e kerstdag acceptabel.

[DataGhost]

ydderf schreef op vrijdag 25 december 2020 @ 16:49:
[...]


Klopt, is eigenlijk een beetje overbodige bouwpuin of een voorbereiding voor een extra check .
Ik ben voor het laatste gegaan....

Tevens dag 24 deel 2 nog ff afgerond. Al heeft hij wel een minuutje nodig om de uitkomst te berekenen, vind ik dat voor de 1e kerstdag acceptabel.

Ik heb wel een hint voor je om een andere oplossingsrichting uit te denken die je vrijwel instant het antwoord geeft, in plaats van na een minuut pas. Als je nou eens doet alsof

spoiler:

de vloer daadwerkelijk oneindig groot is en dat je ver weg van het midden alsnog zwarte tegeltjes kan vinden, moet je wel iets slimmers verzinnen, wat er daarna voor zorgt dat je oplossing ruim binnen een minuut klaar is. Mijn Python-oplossing doet er op mijn oude laptop 820ms over om met zo'n 4000 tegeltjes als antwoord terug te komen. Als ik dan handmatig de volgende tegeltjes toevoeg voor de eerste ronde:
(-100000000,-100000000)
(-100000001,-100000001)
(100000000,100000000)
(100000001,100000001)
is het uiteindelijke antwoord na slechts 1.2 seconden ongeveer 7000 zwarte tegeltjes. Jouw huidige code gaat dit niet vóór 2025 oplossen.

[ElkeBxl]

Finished! Dag 25 was inderdaad een makkelijke eens ik het goed had gelezen. Ik moest wel eerst dag 20 deel 2 nog verder oplossen, maar daar zullen we maar over de code zwijgen...
Ik ben te lui om het verder op te kuisen...

Was leuk om mee te doen, dit is mijn eerste AoC die ik afwerk

[CMG]

Varienaja schreef op vrijdag 25 december 2020 @ 10:10:
[...]
Ja zeg dat wel. Mooi iedere dag om kwart voor zes op. Wassen, aankleden en puzzelen! Zonder leaderbord had ik dat niet gedaan. En zonder jullie hulp en inspiratie had ik het ook niet tot het einde volgehouden. Mijn vrouw is blij dat deze bevlieging over is. En ben ook blij dat de wekker uit kan.

Iedereen bedankt voor het meedoen en meeposten. Prettige feestdagen allemaal!

Haha, ja, hier zijn ze ook blij dat het voorbij is. En ik stond er niet eens extra vroeg voor op (deed elke dag nadag ik de kids naar school gebracht had/we samen ontbeten hadden de challenge live streamen op Twitch).

Zelf vind ik het erg jammer dat het nu voorbij is, maar ik heb nog een dag of 10 te editen voor YT; dus mijn AoC is voorlopig nog niet voorbij 😅 maar verheug me nu al op volgend jaar

Denk erover om de andere jaren ook te gaan livestreamen, maar ik vermoed dat dat thuis te veel gedoe gaat opleveren 😅

[ydderf]

Iets later dan sommige, maar ook hier zijn alle 50 sterren binnen.
Moest nog ff zweten met dag 19 deel 2 en dag 20 deel 2.

Bij dag 19 deel 2 (oneindige loop met rules met combinaties van A en B ) een tijdje lopen te stoeien, maar bij elke oplossing had mijn laptop alle 32GB intern geheugen nodig voor ruim een uur zonder met een oplossing te komen. Uiteindelijk een simpele oplossing bedacht die onder de 20msec beide delen uitvoert;

spoiler:

Voor elke input kijk ik of de eerste letters overeenkomen met een van de rules 42. Vervolgens verwijder ik de eerste letters en kijk ik weer of de passen bij een rule 42. Dit herhalen totdat de string op is, of er geen match is. Vervolgens hetzelfde voor regel 31 met de eventuele resterende karakters.
Wanneer alle karakters passen, dan is het een geldige tekst.

Bij dag 20 deel 2 (tegels aan elkaar plakken en een monster vinden) een tijd aan het klooien geweest omdat ik de tegels niet correct aan elkaar plakte (wel de juiste maar niet in de juiste oriëntatie). Het vervelende was alleen dat hiermee het antwoord van het voorbeeld wel klopte en met de echte input ook monsters werden gevonden. Alleen natuurlijk niet het juiste aantal. Maar gelukkig na wat debuggen dit ook kunnen oplossen.
Meteen maar een aantal hulp functies gemaakt die waarschijnlijk volgens jaar ook wel weer van pas komen.

Nu nog ff een aantal dagen doorkijken hoe andere het hebben opgelost en wat ik slimmer/anders had kunnen doen.

[ Voor 3% gewijzigd door ydderf op 29-12-2020 20:00 ]

[Hydra]

Ik mis het wel hoor. Altijd een raar 'gat' tussen 25 dec en 1 jan

[Singelaar]

Hahaha zeker. Het voelt 'leeg'. Maar ook wel stress vrij, ik was wel toe aan vrij van aoc.
Maar eh, wat begint er 1 januari voor jou?

[Hydra]

Singelaar schreef op woensdag 30 december 2020 @ 15:07:
Hahaha zeker. Het voelt 'leeg'. Maar ook wel stress vrij, ik was wel toe aan vrij van aoc.
Maar eh, wat begint er 1 januari voor jou?

Gewoon weer werk en een nieuw jaar Niks bijzonders verder

[Camulos]

Ik zit al een tijdje vast in Dag 23, en met name in het voorbeeld dat op de site staat.

Voorbeeld move 7

code:

cups:  7  2  5  8  4  1 (9) 3  6 
pick up: 3, 6, 7
destination: 8

result: 8  3  6  7  4  1  9  2  5

Maar als ik de regels volg krijg je toch:

code:

cups:  7  2  5  8  4  1 (9) 3  6 
pick up: 3, 6, 7
destination: 8

haal cups weg:
intermediate: 2  5  8  4  1  9

insert bij 8
result: 2  5  8  3  6  7  4  1  9

Ik vermoed een denk fout met het wrappen in de cirkel, maar ik zie hem niet, wie-o-wie heeft de gouden tip voor me?

[Mschamp]

Camulos schreef op donderdag 31 december 2020 @ 13:41:
Ik zit al een tijdje vast in Dag 23, en met name in het voorbeeld dat op de site staat.

Voorbeeld move 7

code:

cups:  7  2  5  8  4  1 (9) 3  6 
pick up: 3, 6, 7
destination: 8

result: 8  3  6  7  4  1  9  2  5

Maar als ik de regels volg krijg je toch:

code:

cups:  7  2  5  8  4  1 (9) 3  6 
pick up: 3, 6, 7
destination: 8

haal cups weg:
intermediate: 2  5  8  4  1  9

insert bij 8
result: 2  5  8  3  6  7  4  1  9

Ik vermooed een denk fout met het wrappen in de circel, maar ik zie hem niet, wie-o-wie heeft de gouden tip voor me?

Dat klopt toch: het is een cirkel dus er is niet echt een eerste element, enkel een volgorde. Schrijf het eens in een cirkel en vergelijk dan (of haal de 2 elementen vooraan jouw lijst weg, en zet ze eens achteraan)

[Camulos]

Mschamp schreef op donderdag 31 december 2020 @ 13:44:
[...]


Dat klopt toch: het is een cirkel dus er is niet echt een eerste element, enkel een volgorde. Schrijf het eens in een cirkel en vergelijk dan (of haal de 2 elementen vooraan jouw lijst weg, en zet ze eens achteraan)

dat zie ik wel, dat de eerste elementen achteraan zou kunnen zetten, but why?
Impliceert dit dat de start-index ook op hetzelfde start-index moet blijven staan?
(aka dat de 9 niet verplaatst in de platte lijst?)

[Mschamp]

Camulos schreef op donderdag 31 december 2020 @ 13:47:
[...]


dat zie ik wel, dat de eerste elementen achteraan zou kunnen zetten, but why?
Impliceert dit dat de start-index ook op hetzelfde start-index moet blijven staan?
(aka dat de 9 niet verplaatst in de platte lijst?)

Er is niet echt een eerste element (of dat is toch hoe ik het opgelost heb) voor je antwoord moet je ook bekijken tov de beker met tag '1'. In het voorbeeld is gewoon een keuze gemaakt wat als 1 getoond wordt, en jij (en ik ook) gebruiken blijkbaar een ander algoritme waardoor ons 1e element anders is. Zou voor je resultaat geen verschil mogen maken

[Camulos]

thnx @Mschamp ik zit inderdaad bijzonder scheef te kijken
representatie was wel correct, behalve dat mijn 'volgende element' nu moet matchen met de '2' in het voorbeeld.

[ll roel j]

Helaas door tijdsgebrek niet meer doorgegaan na dag 4
Dan maar het komende jaar rustig aan de puzzels oplossen en klaar zijn voor AoC 2021

Misschien in de tussentijd eens een cursus Python starten en ook AoC gebruiken om extra te leren.