Advent of Code 2017

[DRaakje]

ik had die hint niet nodig, maar bedacht hem nadat ik een half uur bezig was geweest om het dans algoritme te optimaliseren.

[ Voor 20% gewijzigd door DRaakje op 16-12-2017 15:26 ]

[Anoniem: 159174]

Toen ik de eerste opdracht las, wilde ik eigenlijk stoppen. Zo saai... Maar ff weggelegd voor de middag. Maar het tweede deel maakte het weer goed. Leuk om even na te denken hoe dit oplosbaar kon zijn.

[Reptile209]

Reptile209 schreef op vrijdag 15 december 2017 @ 09:41:
[...]
En nog een vraag: kan je nog ergens terugzien welke score's je per dagdeel hebt gekregen binnen de Tweakers Leaderboard?

Toch wat gevonden: via de link naar de API bij de private leaderboard kan je een pak met JSON data (https://adventofcode.com/.../private/view/189709.json) ophalen met alle timestamps. Volgens mij zou je daarmee de scorelijst opnieuw kunnen berekenen, dus ook je eigen punten per onderdeel. #boelwerk.

[Lye]

Ik vond vandaag vervelend. Doordat er geen voorbeeld output bij 2 beschikbaar was werd het erg lastig om mijn algoritme te kunnen debuggen.

[Anoniem: 420461]

Reptile209 schreef op zaterdag 16 december 2017 @ 20:45:
#boelwerk.

Even snel dan...

[ThaStealth]

Whoehoe, eerste tweaker die dag 17 afheeft,
Vandaag was redelijk simpel tov gisteren, wat wel vervelend is dat er zowel gister als vandaag geen voorbeeld was bij probleem 2, gister heb ik er lang op gezeten om te achterhalen waar mijn bug zat (wat eenvoudig zou zijn met een fatsoenlijk voorbeeld).

spoiler:

Ik heb wat tijd verknalt vandaag met het verkeerd lezen van opdracht 2, ze vragen niet de currPos+1 waarde maar de waarde van plek 1...

[Reptile209]

Anoniem: 420461 schreef op zondag 17 december 2017 @ 03:24:
[...]

Even snel dan...

Nice

[Hydra]

Dag 16

spoiler:

Deel een was simpel en ik had 't net voordat ik weg moest af. Deel 2 daarentegen was te brute-forcen maar de runtime was immens. Maarja, je moet toch weg en toen ik een paar uur later terug was, had 'ie wel gewoon een correct antwoord

Vandaag dus maar even weer mee verder gegaan (na deel 17) en kwam er redelijk snel achter dat de patronen redelijk korte cycles hebben.

Dag 17

spoiler:

Weer een leuke oplossing bedacht die natuurlijk in deel 2 waardeloos was. Duurde wel ff voordat ik een methode had gevonden om deel 2 te berekenen zonder al die operaties ook daadwerkelijk op collections te doen.

[Lye]

Nou had ik voor deel 2 van vandaag een mooie functionele oplossing bedacht, deze werkte maar wat was die verschrikkelijk traag zeg.. Het duurde om en nabij de 850ms om de oplossing te genereren.

Een meer imperatieve oplossing die praktisch hetzelfde doet is meer 3x zo snel met 300ms.. Dan maar op deze manier

[Anoniem: 1004565]

Vond deel 2 niet leuk...
Dit is een poging tot bruteforce

http://prntscr.com/hooect

https://github.com/DutchG...er/Rust/day17/src/main.rs

EDIT

na wat gepieker toch maar besloten gebruik te maken van een LinkedList. GGRR Rust std-lib, er is dus geen .insert(positie, element) functie voor de linkedlist uit de std-lib....
gelukkig beston er al een crate die dit wel kon!
Een runtime van ~1640 seconden, maarja...

https://github.com/DutchG...er/Rust/day17/src/main.rs

Het kan volgens mij hier en daar nog iets verbeterd worden...

[ Voor 58% gewijzigd door Anoniem: 1004565 op 18-12-2017 00:05 ]

[Hydra]

Kotlin Dag 18

Son-of-a-bitch. Kleine spoiler voor de mensen die vast zitten:

spoiler:

32 bits ints zijn niet groot genoeg voor de registers.

Toen ik dat eenmaal doorhad, had ik meteen het antwoord. En deel 2 was, afgezien van dat de aanpak compleet anders was, best simpel.

[rnark]

Erg leuke opdracht vandaag! Deel twee kostte me meer tijd dan ik verwacht had, kon de vinger niet leggen op een fout. Uiteindelijk de eerste paar instructies met de hand gedaan, toen was de fout snel boven tafel

[Peelee]

Son-of-a-bitch. Kleine spoiler voor de mensen die vast zitten:

spoiler:

32 bits ints zijn niet groot genoeg voor de registers.

Same here..

spoiler:

Ik dacht eerst dat ik een instructie verkeerd interpreteerde doordat ik plots negatieve waarden kreeg, tot ik ook in de gaten had dat het door een overflow kwam

[Soultaker]

Hoe efficiënt is jullie oplossing voor deel 2 van dag 17 (Spinlock)?

Met K=303 (mijn invoer) en N=50,000,000 is de voor de hand liggende O(NK) oplossing nog best traag. Ik kan wel een manier bedenken om het in O(N log K) te doen, maar eigenlijk is het de factor N die kleiner moet worden, en daar heb ik geen goed idee voor.

Anoniem: 1004565 schreef op zondag 17 december 2017 @ 16:38:
na wat gepieker toch maar besloten gebruik te maken van een LinkedList. GGRR Rust std-lib, er is dus geen .insert(positie, element) functie voor de linkedlist uit de std-lib....
gelukkig beston er al een crate die dit wel kon!
Een runtime van ~1640 seconden, maarja...

Je hebt helemaal geen expliciete linked list nodig, je kunt gewoon indices van 0 t/m N als identifiers gebruiken, en je hoeft alleen maar de successor van elke node op te slaan. Daarvoor is een array van integers genoeg, zoals in m'n Python oplossing:
https://github.com/maksve...b/master/2017/17B-slow.py

edit: dit is sowieso geen handige aanpak. Zie P.O. Box' reactie hieronder.

[ Voor 4% gewijzigd door Soultaker op 18-12-2017 13:43 ]

[P.O. Box]

Soultaker schreef op maandag 18 december 2017 @ 13:12:
Hoe efficiënt is jullie oplossing voor deel 2 van dag 17 (Spinlock)?

Met K=303 (mijn invoer) en N=50,000,000 is de voor de hand liggende O(NK) oplossing nog best traag. Ik kan wel een manier bedenken om het in O(N log K) te doen, maar eigenlijk is het de factor N die kleiner moet worden, en daar heb ik geen goed idee voor.


[...]

Je hebt helemaal geen expliciete linked list nodig, je kunt gewoon indices van 0 t/m N als identifiers gebruiken, en je hoeft alleen maar de successor van elke node op te slaan. Daarvoor is een array van integers genoeg, zoals in m'n Python oplossing:
https://github.com/maksve...e/blob/master/2017/17B.py

spoiler:

Je hoeft de de list sowieso niet vast te leggen, omdat je altijd het 2e element nodig hebt. Alle overige elementen vastleggen is daarmee overbodig zolang de wegschrijf-positie niet gelijk is aan 1. In php ging daardoor mijn loopje van heul lang (heb hem niet afgewacht) naar enkele seconden voor 50.000.000....

[Soultaker]

P.O. Box schreef op maandag 18 december 2017 @ 13:31:
(spoiler voor 17B)

Ahh, dat had ik nog helemaal niet bedacht (terwijl dat veel meer lijkt op m'n aanpak van dag 17A). Slim! Dat maakt de implementatie sowieso O(N) en inderdaad redelijk snel (nog steeds meerdere seconden in Python, maar PyPy helpt).

[Anoniem: 159174]

Deel 1 ging prima, deel twee gaat even op de plank. Het moet wel leuk en combineerbaar met andere zaken blijven. Mis nu met C wel de taalconstructies als objecten, queues etc... Tja, eigen keus he..

[kenneth]

Zoals verwacht erg weinig tijd gehad na dag 8. Nu de lessen van de eerste week mentaal verwerkt zijn kijk ik opeens opvallend anders naar de problemen. Ik denk sneller in termen van folds, state machines en adt's. Zo was dag 9 eenvoudig toen het kwartje eenmaal viel en het kwartje valt steeds sneller. Ik was eerst bezig met een redelijk imperatieve oplossing maar het voelde al snel te omslachtig. Ik vind deze oplossing best elegant en aangezien ik op reddit dezelfde aanpak veel voorbij zag komen zal dat oordeel wel kloppen

Goed, halverwege dag 10 en de komende anderhalve week vakantie. Ik heb jullie hopelijk voor maandag bijgehaald

[veldsla]

Jammer dat de dag 18 opdracht niet in het weekend viel. Nu geen tijd om de code van vorig jaar op te ruimen. Wel een geinige variatie dit jaar.

[EagleTitan]

De halve dag besteed aan deel 2 omdat

spoiler:

de condition check voor de jump keek of niet 0 in plaats van groter dan 0

En dat maakte voor deel 1 geen verschil in de uitkomst, dus je merkt het ook niet

[ Voor 18% gewijzigd door EagleTitan op 18-12-2017 15:45 ]

[Hydra]

kenneth schreef op maandag 18 december 2017 @ 14:45:
Zoals verwacht erg weinig tijd gehad na dag 8. Nu de lessen van de eerste week mentaal verwerkt zijn kijk ik opeens opvallend anders naar de problemen. Ik denk sneller in termen van folds, state machines en adt's.

Precies! En dat vind ik ook zo cool van dit soort challenges. Zit toch al een tijdje in 't vak en het traint lekker de hersenspiertjes. Komt nog eens bij dat ik redelijk handig met Kotlin begin te worden en dat gaat in de nabije toekomst ook handig zijn.

Nadeel is alleen dat ik voor m'n werk nog Java type en ik continue puntcomma's vergeet en zo veel meer code moet schrijven

[wmkuipers]

Verwarrende deel 2 vandaag, heeft me veel tijd gekost.

[Quadro!]

Ik vond deel 2 wel tof vandaag! Ik heb alleen geen flauw idee hoe je fatsoenlijk concurrent dingen in Haskell doet, dus maar even snel iets in Go in elkaar geklust. Als ik meer tijd heb probeer ik hem nog wel in Haskell op te lossen.

[Soultaker]

Quadro! schreef op maandag 18 december 2017 @ 19:59:
Ik vond deel 2 wel tof vandaag! Ik heb alleen geen flauw idee hoe je fatsoenlijk concurrent dingen in Haskell doet, dus maar even snel iets in Go in elkaar geklust.

Je hoeft geen multithreading te gebruiken.

spoiler:

Je kunt gewoon twee machines maken en om-en-om een stap uitvoeren. Als een machine een rcv instructie probeert uit te voeren terwijl er geen uitvoer van de ander machine beschikbaar is, laat je 'm een stap overslaan.

(Python voorbeeld.) Dat moet in Haskell ook gewoon kunnen; sterker nog, dat is niet veel ingewikkelder dan de aanpak van deel 1.

[P.O. Box]

kan iemand die deel 2 van dag 18 heeft opgelost mijn zijn input en zijn antwoord PM'en? Ik krijg namelijk een oplossing, maar de site zegt dat mijn oplossing niet goed is, however, hij is wel goed voor iemand anders zijn opgave. Ik zal vast een fout gemaakt hebben, maar wil dat even uitsluiten door iemand anders zijn input te testen en te kijken of ik dan het juist antwoord (wat jij dus dan al hebt getoetst) wél krijg....

nevermind... ik zat program-0 te tellen grrrr....

[ Voor 6% gewijzigd door P.O. Box op 18-12-2017 22:36 ]

[Bee.nl]

Heel lang zitten staren op dag 18 deel 2. De code had ik vrij snel en alles leek te kloppen, maar toch kwam er steeds niet het juiste antwoord uit. Was ik gewoon vergeten om het eerste argument bij de jump te checken. Het kon immers zowel een registerwaarde als een vast getal zijn

Mijn php-oplossing voor vandaag. It ain't pretty, maar na zo lang staren was ik er wel even klaar mee.

[vliegnerd]

Bee.nl schreef op maandag 18 december 2017 @ 22:52:
Heel lang zitten staren op dag 18 deel 2. De code had ik vrij snel en alles leek te kloppen, maar toch kwam er steeds niet het juiste antwoord uit. Was ik gewoon vergeten om het eerste argument bij de jump te checken.

Precies dat... 2 uur frustratie ofzo.

[EagleTitan]

Zo, dat was day 19. Redelijk simpel

[Hydra]

Dag 19

Toch best ff mee bezig geweest.

spoiler:

M'n eerste richting was een DF search maar dat werkte niet lekker doordat je moet gaan springen en je dus sommige cells meerdere keren 'bezoekt'. Toen maar een 'domme' iteratieve approach gebruikt.

Wel veel code kunnen hergebruiken weer

[Soultaker]

Hydra schreef op dinsdag 19 december 2017 @ 09:49:
Dag 19

Toch best ff mee bezig geweest.

Ik denk dat je het probleem ingewikkelder hebt geïnterpreteerd dan nodig was.

spoiler:

Er zijn geen splitsingen in de invoer. Dus is het onderscheid tussen DFS en BFS ook betekenisloos, en hoef je ook geen visited set bij te houden.

Wel veel code kunnen hergebruiken weer

Meh, code hergebruiken is overrated Ik vond m'n oplossing simpel genoeg: https://github.com/maksve...de/blob/master/2017/19.py

[Hydra]

Soultaker schreef op dinsdag 19 december 2017 @ 10:59:
Ik denk dat je het probleem ingewikkelder hebt geïnterpreteerd dan nodig was.

spoiler:

Er zijn geen splitsingen in de invoer. Dus is het onderscheid tussen DFS en BFS ook betekenisloos, en hoef je ook geen visited set bij te houden.

Klopt, maar toen ik 't werkend had, was ik er aardig klaar mee

spoiler:

Die 'visited' is ook alleen om uit te vogelen op turns welke kant ik op moet, hiermee schakel ik de 'vorige' uit. Komt ook omdat ik bestaande code gebruik die voor mij uitvogelt wat de buren van een bepaald 'punt' zijn. Voor een turn is dat of de volgende of de vorige stap. Ik had ook prima alleen de vorige bij kunnen houden.

[Klaasvaak]

Vanmorgen tijdens het ontbijt aan deel 1 begonnen, maar met m'n slaperige kop een "if if " geschreven in plaats van een "if else if". Toen ik na het werk weer verder keek, was het probleem gelukkig zo gevonden. Deel twee was vandaag wel heel erg simpel.

[Anoniem: 1004565]

https://github.com/DutchG...er/Rust/day19/src/main.rs

Leuk! Mijn brein kraakte alleen wel een beetje.... Mijn loop bleef namelijk doorlopen eerst, waardoor ik veel meer letters kreeg dan eigenlijk moest... :3

[Hydra]

Dag 20 In Kotlin

Niet helemaal happy mee.

spoiler:

Hoewel ik de juiste antwoorden direct kreeg gaat dit niet werken voor alle inputs omdat ik niet detecteer of particles elkaar nog kunnen raken. Ik itereer gewoon 'dom' 500 keer en ga er dan maar vanuit dat het wel gelukt is.

Nouja. It compiles; let's ship it!

[Soultaker]

Hydra schreef op woensdag 20 december 2017 @ 08:24:

spoiler:

Hoewel ik de juiste antwoorden direct kreeg gaat dit niet werken voor alle inputs omdat ik niet detecteer of particles elkaar nog kunnen raken. Ik itereer gewoon 'dom' 500 keer en ga er dan maar vanuit dat het wel gelukt is.

Mja, voor deel 1

spoiler:

hoef je maar één tijdpunt ver in de toekomst te kiezen (e.g. t=1000000000), en kun je alle posities op dat tijdstip uitrekenen. Een taal met variable-length integers helpt omdat je je dan geen zorgen hoeft te maken over overflow.

. Voor deel 2

spoiler:

moet je eigenlijk wel itereren

.

Ik heb wel wat ideeën voor hoe je het netter op kunt lossen, maar het format van Advent of Code nodigt daar niet echt toe uit (zeker niet als je voor de score speelt: dan is een quick and dirty oplossing bijna altijd beter).

[Peelee]

Vandaag bracht herinneringen boven aan menige fysica en mechanica cursus, niet zo moeilijk maar wel leuk

spoiler:

Als alternatieve, niet-itererende oplossing heb ik voor deel 1 enkel gecheckt welke van de particles de laagste versnellingsvector heeft.
In de 'long run' zal die uiteindelijk het traagste van punt (0,0,0) weggaan, ongeacht z'n initiële snelheid en positie.

[EnnaN]

Peelee schreef op woensdag 20 december 2017 @ 10:57:
Vandaag bracht herinneringen boven aan menige fysica en mechanica cursus, niet zo moeilijk maar wel leuk

spoiler:

Als alternatieve, niet-itererende oplossing heb ik voor deel 1 enkel gecheckt welke van de particles de laagste versnellingsvector heeft.
In de 'long run' zal die uiteindelijk het traagste van punt (0,0,0) weggaan, ongeacht z'n initiële snelheid en positie.

Ja, die had ik ook, maar het klopt niet helemaal tenzij je goed je best doet bij de tie-breaker. Ik had de mazzel dat het voor mijn input goed gaat, maar het is wel tricky .

spoiler:

Als je versnelling gelijk is, dan is degene die het dichtste bij blijft degene met de laagste (absolute) snelheid. Dus je kan de absolute snelheid als tie-breaker gebruiken.

Dat kan ook goed gaan, behalve als je (voorbeeld van reddit gejat) deze input had ergens:

p=<0,0,0>, v=<0,0,0>, a=<1,0,0>
p=<0,0,0>, v=<-1,0,0>, a=<1,0,0>

pixel 0 lijkt dichterbij want is dichter bij nulpunt in de tie-breaker, maar pixel 1 gaat eerst 'de andere kant op', en komt dus vervolgens dichter bij te liggen.

[Peelee]

Goed gezien inderdaad!

spoiler:

Dan speelt de initiele snelheid ook een rol, of als die ook nog eens gelijk is de beginpositie

[EnnaN]

Peelee schreef op woensdag 20 december 2017 @ 11:27:
Goed gezien inderdaad!

spoiler:

Dan speelt de initiele snelheid ook een rol, of als die ook nog eens gelijk is de beginpositie

spoiler:

ja, maar je kan dus niet alleen de absoulte beginsnelheid nemen! een simpele tweede check op snelheid (en positie) is dus in dat voorbeeld ook niet genoeg!

[veldsla]

Het antwoord vinden bij dag 20 door te kijken naar de output leidde vlotjes tot de juiste oplossing. Het vinden van de juiste condities om de loop te breken vond ik nog het lastigst. Misschien kan het ook wel efficienter...

Nu nog tijd vinden voor dag19...

[Anoniem: 1004565]

Heel FromStr implementaties! Staat wel heel netjes naar mijn idee...
een conditie om de loop te breaken heb ik niet, ik laat m gewoon runnen en de getallen blijven vanzelf hetzelfde... ^^

https://github.com/DutchG...ree/master/Rust/day20/src

[The Fox NL]

veldsla schreef op woensdag 20 december 2017 @ 13:43:
Het antwoord vinden bij dag 20 door te kijken naar de output leidde vlotjes tot de juiste oplossing. Het vinden van de juiste condities om de loop te breken vond ik nog het lastigst. Misschien kan het ook wel efficienter...

Nu nog tijd vinden voor dag19...

spoiler:

Ik heb voor deel 2 de loop op 10.000 iteraties gezet. Duurde nogal lang met met gebruik van Linq, dus breekpunt gezet en gekeken hoeveel deeltjes er nog over waren. Dat veranderde niet meer, dus dat getal als antwoord ingevuld en het was goed. Later bleek dat 100 iteraties al ruim voldoende was.

Deel 1:

spoiler:

Gewoon het deeltje met de laagste versnelling gezocht en dat was er gelukkig maar 1. Waren het er meer, dan had je met Velocity en Position rekening moeten gaan houden.

[Reptile209]

Teeeeering zeg... echt anderhalf uur zitten worstelen met dag 20 deel 2.

spoiler:

Tests gingen prima, maar op de input waren er maar 6 particles weg na 1e6 iteraties. Voorbeelden uit github kwamen voor mijn input op ~500 survivors in <1000 cycles. Bleek ik bij het for-loopje dat over de x, y en z-coordinaat loopt de z over te slaan (< 2 in plaats van < 3, off-by-one).

#fuckmylife, opgelost .

Deel 1:

spoiler:

Voor ieder deeltje in 1 stap de positie op t = 1e7 berekend met x = x0 + v0 *t + a0 * t^2, en dan kijken welke de kleinste afstand oplevert. Appeltje-eitje.

[rnark]

Leuke opdracht weer vandaag, was even puzzelen.

spoiler:

Het woordje 'otherwise' had ik even gemist bij het proces dat het programma volgt. Ik checkte dus of de grootte deelbaar was door 3 en baseerde daar de rest op. Oeps...

[ThaStealth]

Leuke opdracht, vooral het roteren en flippen was even nadenken. Zie dat veel mensen er moeite mee hebben, ben dus best wel trots op mezelf dat ik als 1 van de eerste Tweakers hem opgelost heb

[veldsla]

Meh...geen zin om lang over na te denken en al helemaal niet om rotaties op string representaties van matrices the gaan implementeren.....Dus R

[Soultaker]

Damn, ik dacht dat Dag 21 niet te brute-forcen zou zijn, maar dat bleek wel het geval. Had me een hoop programmeertijd kunnen besparen door een paar seconden geduld te hebben.

Ik heb uiteindelijk een oplossing geschreven die in O(N) tijd runt (waarbij N het aantal iteraties is). Ik denk dat de meeste anderen een exponentiëel algoritme geïmplementeerd hebben. Code: https://github.com/maksve...de/blob/master/2017/21.py

Pro tip: het kan ook nóg sneller: in O(log N) tijd (als je het aantal patronen in de invoer als constante beschouwt, en integer operaties in O(1) uitvoert).

De truc is als volgt:

spoiler:

als je begint met een 3x3 tegel, heb je na 3 stappen een 9x9 tegel (3x3 -> 4x4 -> 6x6 -> 9x9). Die 9x9 tegel kun je zien als vier 3x3 tegels die zich onafhankelijk ontwikkelen; dat wil zeggen: het patroon na nog N stappen is gelijk aan het patroon dat je krijgt als je ieder kwadrant los transformeert en vervolgens de resultaten aan elkaar plakt.

Dit werkt niet met stappen van 1 omdat bij de stap van 6x6 -> 9x9 de de grenzen van de invoertegels niet overeenkomen met die van de vorige stap.)

Het gevolg hiervan is dat je per iteratie niet het hele grid hoeft bij te houden, maar alleen per 3x3 tegel in de invoer, het aantal van die tegels in het grid. Zo kun je dus in constante tijd drie iteraties vooruit berekenen. Als het totale aantal iteraties niet deelbaar is door 3, moet je op het eind nog 1 of 2 losse stappen doen.

Om dit naar O(log N) te optimaliseren (wat ik dus niet gedaan heb)

spoiler:

kun je de transformatiestap van 3x3 tegels naar 3x3 tegels schrijven als een vierkante matrix en die in logaritmische tijd tot de macht N/3 verheffen

[Hydra]

Lang mee bezig geweest door een stomme bug. Dag 21, Kotlin

Stomme fout gemaakt:

spoiler:

val size = if (field.size % 3 == 0) 3 else 2

in plaats van:

val size = if (field.size % 2 == 0) 2 else 3

[Reynouts]

Dit vond ik een pittige opdracht!

Het duurde al even voordat ik door had wat er precies moest gebeuren en dan nog knutselen met de rotaties/flips. Numpy is dan handig

[Anoniem: 420461]

Aan het GoT-leaderboard en de stats te zien vonden meer mensen het een lastige - zo te zien de lastigste tot nu toe...

[EagleTitan]

Dag 21 en dag 22 in Go.

Vond ze wel weer meevallen. Ben daarentegen nog steeds aan het worstelen met deel 2 van dag 20

[Hydra]

22 in Kotlin

Leuke opdracht. Vrij simpel en leverde mooie code op IMHO.

Edit: Damn, net te laat!

EagleTitan schreef op vrijdag 22 december 2017 @ 09:19:
dag 22 in Go.

Da's een hoop code...

[ Voor 39% gewijzigd door Hydra op 22-12-2017 09:21 ]

[EagleTitan]

Hydra schreef op vrijdag 22 december 2017 @ 09:20:

[...]


Da's een hoop code...

Go is best verbose inderdaad.

[Hydra]

EagleTitan schreef op vrijdag 22 december 2017 @ 09:25:
Go is best verbose inderdaad.

Ja, niks ten nadele van jou hoor, maar we hebben nogal eens discussies waarbij sommigen claimen dat Go zoveel makkelijker is dan Java. Heb er zelf redelijk veel mee gedaan (simpele REST service en wat commandline tooltjes) maar ik word eigenlijk gek van hoe omslachtig 't allemaal is. Simplistic != easy. Java is van zichzelf al erg verbose (nu ik veel in Kotlin bezig ben is het vaak best wel 'meh') maar ik zie vrijwel alleen maar AoC code in Go waarbij de Java versie gewoon minder code bevat.

[veldsla]

De kracht van verbose code, en ja Rust is ook nogal verbose, is denk ik niet het verbose zijn tijdens de initiele ontwikkeling, maar vooral het vertrouwen wat je kunt hebben tijdens het refactoren en optimaliseren. Ik doe zelf niks met Go, maar ik hoop dat het daar ook geldt. Hoe meer expliciete types des te beter de compiler kan assisteren als je in de code gaat spitten.

Rust newtypes zoals dit (uit mijn dag 22) bestaan alleen tijdens het compileren en worden helemaal weg geoptimaliseerd. Ze dragen wel bij tot de leesbaarheid en zorgen dat de type checker explicieter kan controleren.

[Hydra]

veldsla schreef op vrijdag 22 december 2017 @ 10:11:
De kracht van verbose code, en ja Rust is ook nogal verbose, is denk ik niet het verbose zijn tijdens de initiele ontwikkeling, maar vooral het vertrouwen wat je kunt hebben tijdens het refactoren en optimaliseren. Ik doe zelf niks met Go, maar ik hoop dat het daar ook geldt. Hoe meer expliciete types des te beter de compiler kan assisteren als je in de code gaat spitten.

Da's een beetje het punt. Een type-system; top. Ik ben Java dev en in AoC met Kotlin bezig en beiden zijn strongly typed. Maar Go heeft daarbovenop een hoop 'busywork' dat niks toevoegt IMHO.

Ik ben overigens wel helemaal over als het op Kotlin aankomt. M'n dagelijks werk is Java en ik vind Kotlin gewoon 100% een betere taal. Er is niks waar ik zo iets van heb dat Java beter is, en dat zegt nogal wat

[Lye]

Hydra schreef op vrijdag 22 december 2017 @ 10:38:
[...]


Da's een beetje het punt. Een type-system; top. Ik ben Java dev en in AoC met Kotlin bezig en beiden zijn strongly typed. Maar Go heeft daarbovenop een hoop 'busywork' dat niks toevoegt IMHO.

Ik ben overigens wel helemaal over als het op Kotlin aankomt. M'n dagelijks werk is Java en ik vind Kotlin gewoon 100% een betere taal. Er is niks waar ik zo iets van heb dat Java beter is, en dat zegt nogal wat

Ik ben ook Java dev waarbij ik sinds vorig jaar zoveel mogelijk overzet naar Kotlin. Is inderdaad een prachtige taal al zijn er nog wel een aantal kleine zaken die in Java net iets robuuster danwel volwassener Nou staat Kotlin nog in zijn kinderschoenen en elke update maakt het echt een stuk beter, maar simpele dingen zijn soms echt nog heel erg raar.

[Hydra]

Lye schreef op vrijdag 22 december 2017 @ 10:53:
Ik ben ook Java dev waarbij ik sinds vorig jaar zoveel mogelijk overzet naar Kotlin. Is inderdaad een prachtige taal al zijn er nog wel een aantal kleine zaken die in Java net iets robuuster danwel volwassener Nou staat Kotlin nog in zijn kinderschoenen en elke update maakt het echt een stuk beter, maar simpele dingen zijn soms echt nog heel erg raar.

Ik heb nog niet professioneel met Kotlin gewerkt. Puur uit interesse; kun je voorbeelden noemen?

[Lye]

Hydra schreef op vrijdag 22 december 2017 @ 10:58:
[...]


Ik heb nog niet professioneel met Kotlin gewerkt. Puur uit interesse; kun je voorbeelden noemen?

Type inference is niet in alle gevallen perfect. Bijvoorbeeld het volgende:

code:

charArrayOf('a', 'b', 'c').let(::String) // Werkt niet
charArrayOf('a', 'b', 'c').let { String(it) } // Gaat prima

In Java zou zo'n constructie gewoon werken, niet dat dit een veel voorkomende situatie is (normaal gesproken zou je snel terugvallen op joinToString of iets dergelijks, maar ik kwam het toevallig afgelopen week tegen.

Ook is er in Kotlin nog geen makkelijke manier om Sequences parallel uit te voeren zonder je eigen boilerplate code er omheen te gooien. Natuurlijk is ook dit geen groot probleem, maar ten opzichte van de eenvoudigheid van Java's parallelStream is het toch wel een groot gelag.

Kotlin heeft geen static variabelen, behalve via companion objects of top level variabelen, dit zijn prima oplossingen maar maken het -naar mijn mening- net iets onduidelijker. Dit geldt helemaal voor companion objects, die zowel een virtue als een vice zijn. Neem de volgende situatie:

code:

class SomeClass {
    companion object {
        const val SOME_CONSTANT = 5
    }

    fun a() = SOME_CONSTANT
}

const val SOME_CONSTANT = 3

Het is voor mij nu niet duidelijk welke constante gebruikt wordt in a(). Vanuit Java's perspectief zou de top level constante gebruikt moeten worden (immers worden deze functies/variabelen/constanten onderdeel van de class), echter blijkt de constante uit het companion object gebruikt te worden.

Het zijn van die kleine dingen, maar die zijn -wat mij betreft- toch net iets duidelijker en consistenter in Java. Maar zoals ik al zei, Kotlin staat nog in zijn kinderschoenen en elke update maakt het beter. Jetbrains zet grote stappen met de taal en het is naar mijn mening ook zeker een taal die in de toekomst meer marktaandeel inpikt van Java, wat je nu al ziet op het gebied van ontwikkeling van Android apps.

Overigens heb ook ik nog niet heel veel professioneel met Kotlin gedaan, het zijn vooral kleine projectjes. Ik ben echter wel benieuwd hoe Kotlin zich houdt in grotere projecten.

[ Voor 4% gewijzigd door Lye op 22-12-2017 11:17 ]

[Anoniem: 1004565]

part 1... Erg vaag waar je nou begon in de Grid, of dat nou op (0, 0) was, of exact in het midden...
Kwam er ook pas na veel frustratie achter dat het om een infinite Grid ging.... GRR

https://github.com/DutchG...ree/master/Rust/day22/src

[Soultaker]

Anoniem: 1004565 schreef op vrijdag 22 december 2017 @ 11:17:
part 1... Erg vaag waar je nou begon in de Grid, of dat nou op (0, 0) was, of exact in het midden...
Kwam er ook pas na veel frustratie achter dat het om een infinite Grid ging.... GRR

Dat wordt toch allebei direct duidelijk bij het eerste voorbeeld?

Volgens mij is het dit jaar voor het eerst dat er consequent voorbeeldinvoer en -uitvoer gegeven wordt. Dat kan een hoop onduidelijkheden voorkomen, mits de lezer ze niet compleet negeert

[Reynouts]

Ik moet de opdrachten ook vaak een aantal keer doorlezen. Soms denk je dat je het hebt begrepen, snap je niet waarom je uitkomst niet klopt en lees je daarna de opdracht maar nog een keer en mistte je iets.

Hier was het mij gelukkig wel meteen duidelijk. Eerste alinea noemen ze de infinite grid en later dat je in het midden van je input map begint.

Op naar de laatste dagen!

[Anoniem: 1004565]

https://github.com/DutchG...ree/master/Rust/day22/src

Heel veel duplicate code, ben er nog niet tevreden mee...maar 't werkt... straks even refactoren

[veldsla]

Zo dan maar, kleine tweak en het is weer sneller dan de Go versie 0.5s tegen 1s. Kan nog 100ms af als ik een andere hasher kies.

Ik zie dat @Anoniem: 1004565 Rust versie een stuk harder gaat (maar het verkeerde antwoord geeft? Misschien een extra newline in de input...). Ik gok dat het aan de Vec ligt ipv de hashmap. Scheelt wel flink 130ms voor jouw oplossing

De mem::replace variant is exact even snel.

Ik heb het nog even zonder newline op de laatste regel geprobeerd, maar krijg nog steeds niet het juiste antwoord. Ik heb mijn input gecommit, dus check het zelf. Voor de zekerheid hieronder het antwoord

spoiler:

5322 en 2512079

[ Voor 75% gewijzigd door veldsla op 22-12-2017 13:29 ]

[Anoniem: 1004565]

veldsla schreef op vrijdag 22 december 2017 @ 12:45:
Zo dan maar, kleine tweak en het is weer sneller dan de Go versie 0.5s tegen 1s. Kan nog 100ms af als ik een andere hasher kies.

Voor enums is het in Rust volgens mij erg snel om mem::replace te gebruiken om 'm aan te passen!
EDIT:
Fout antwoord?
wellicht ligt het aan de manier waarop ik de richting initialiseer in het begin...En in mijn input in VScode plakte VScode er idd een newline achter in eerste instantie, die moest ik nog even weghalen. (en de startpositie bij mij is 12/12...mss verschilt dat nog per persoon??)

[ Voor 30% gewijzigd door Anoniem: 1004565 op 22-12-2017 13:15 ]

[Hydra]

Anoniem: 1004565 schreef op vrijdag 22 december 2017 @ 11:17:
part 1... Erg vaag waar je nou begon in de Grid, of dat nou op (0, 0) was, of exact in het midden...
Kwam er ook pas na veel frustratie achter dat het om een infinite Grid ging.... GRR

Als AoC je iets leert, is het het goed lezen van de instructies

En waardevolle input @Lye, thanks!

[ Voor 5% gewijzigd door Hydra op 22-12-2017 13:25 ]

[veldsla]

Anoniem: 1004565 schreef op vrijdag 22 december 2017 @ 12:53:
wellicht ligt het aan de manier waarop ik de richting initialiseer in het begin...

Check. That's it

[Anoniem: 1004565]

veldsla schreef op vrijdag 22 december 2017 @ 12:45:
Zo dan maar, kleine tweak en het is weer sneller dan de Go versie 0.5s tegen 1s. Kan nog 100ms af als ik een andere hasher kies.

Ik zie dat @Anoniem: 1004565 Rust versie een stuk harder gaat (maar het verkeerde antwoord geeft? Misschien een extra newline in de input...). Ik gok dat het aan de Vec ligt ipv de hashmap. Scheelt wel flink 130ms voor jouw oplossing

De mem::replace variant is exact even snel.

Ik heb het nog even zonder newline op de laatste regel geprobeerd, maar krijg nog steeds niet het juiste antwoord. Ik heb mijn input gecommit, dus check het zelf. Voor de zekerheid hieronder het antwoord

spoiler:

5322 en 2512079

Heb mn oplossing herschreven, werkt nu ook voor jouw input zonder dat er dingen aangepast hoeven te worden! https://github.com/DutchG.../Rust/day22/src/walker.rs

[Lye]

Nou had ik vandaag al een oplossing waar ik niet blij mee was. Het duurde ongeveer 2 seconden nodig om te draaien, wat naar mijn mening veel te lang is.
Dus de boel herschreven en in plaats van een map met punten bij te houden een daadwerkelijk grid te bouwen (al gebruik ik stiekem op de achtergrond alsnog een map), dit zorgt er voor dat ik de runtime naar minder dan 700ms gaat, toch bijna 3x zo snel. Al een heel stuk blijer met deze oplossing, al is het nog niet perfect, ik wil het graag onder de 500ms houden

[Hydra]

Dag 23 in Kotlin

Niet happy mee. Deel 1 was te simpel; kopie van dag 18. Deel 2 heb ik moeten 'valsspelen' omdat ik in een compleet verkeerde denkrichting zat.

spoiler:

Als je dan leest op Reddit dat je 'gewoon' die assembly met de hand moet vertalen is het simpel,
maar eigenlijk saai.

Onbevredigend resultaat.

[ Voor 5% gewijzigd door Hydra op 23-12-2017 09:45 ]

[veldsla]

Er zijn vast mensen die het leuk vinden, maar met de hand een beetje door zo'n progsel lopen om te kijken wanneer 107900 107899 wordt is niet mijn hobby.

[Anoniem: 1004565]

Ik had nog mijn bunny-assembly code van vorig jaar...deel 1 was zo klaar...deel 2 is nog steeds aan 't rekenen ^^

https://github.com/DutchG...er/Rust/day23/src/main.rs

EDIT:

nu vooraf geen Initialisatie meer van de registers, zodra ik nu een register opvraag die nog niet in mn btreemap zit, word hij automatisch met value 0 ge-insert

[ Voor 30% gewijzigd door Anoniem: 1004565 op 23-12-2017 11:59 ]

[veldsla]

Op reddit stond iets van 10^13 operaties, dus zelfs mijn vlotte versie van vorig jaar die zo'n 180M instructies per seconde deed zou er dik 15 uur over doen.

[Peelee]

Deel 2 is nu ook niet onmiddellijk m'n meest favoriete oefening van dit jaar..
Hopelijk nog 2 mooie dagen te gaan

[Anoniem: 420461]

Deel 1 was inderdaad erg simpel - ik vertrouwde het zelfs even niet, maar het antwoord was goed, dus...

spoiler:

Deel 2 gedaan met omzetten van de assembly naar PHP-code en die steeds verder indikken tot een paar regels.

[Bee.nl]

De opdracht van vandaag vind ik maar matig. Iedereen heeft ook dezelfde input volgens mij. Deel 1 is bijna een copy paste van dag 18 en deel 2 doet me weinig.

[DRaakje]

Ik vond hem erg mooi. Ik denk dat ik 2 uur bezig ben geweest met erachter komen wat er nou aan de hand was op volledig de verkeerde manier. Uiteindelijk is de tijd om het op te lossen sneller als part 1.

hier een hint om je op weg te helpen.

Hint 1

spoiler:

Toen ik de code omzette naar c# werd het duidelijk wat het probeerde te doen.

Hint 2

spoiler:

variable g word elke keer gereset.

[ Voor 8% gewijzigd door DRaakje op 23-12-2017 20:46 ]

[The Fox NL]

Pfff, poos bezig met dag 22 deel 2. Output klopte maar niet, blijkt dat ik een copy-paste fout gemaakt had en naar rechts ging ipv omkeren

[Hydra]

Dag 24 in Kotlin

Had eerder gezegd een moeilijkere opdracht verwacht.

spoiler:

Gewoon een recursieve search door de searchspace.

[Daanoz]

Ik had inderdaad ook gedacht dat er nog wel wat optimalizaties nodig waren om sneller door de dataset te zoeken... Maar met een eerste test run op de echte dataset van 1 seconde niet echt van toepassing .

[Soultaker]

Aangezien het probleem NP-hard is kun je ook niet veel beter doen dan brute-force.

De meeste oplossingen zullen bijvoorbeeld niet werken voor een invoer die uit twintig keer 0/1 bestaat. Je kunt voor die situatie wel optimaliseren, maar dat is bij de testinvoer niet nodig (dus waarom zou je) en het maakt je algoritme niet fundamenteel sneller (het blijft exponentiële tijd kosten, in het ergste geval).

[veldsla]

Zo. was ik toch even een tijdje aan het zoeken wat ik fout had gedaan. En ja...het was dom.

[Hydra]

Soultaker schreef op zondag 24 december 2017 @ 12:52:
De meeste oplossingen zullen bijvoorbeeld niet werken voor een invoer die uit twintig keer 0/1 bestaat. Je kunt voor die situatie wel optimaliseren, maar dat is bij de testinvoer niet nodig (dus waarom zou je) en het maakt je algoritme niet fundamenteel sneller (het blijft exponentiële tijd kosten, in het ergste geval).

Ik had niet naar de 'echte' invoer gekeken en voor de test-invoer gewoon quick 'n dirty een 'geef me alle permutaties van de lijst' functie gebruikt. Dat werkt wel voor 8! (grofweg) maar niet echt voor 56!

[zerok]

EagleTitan schreef op maandag 18 december 2017 @ 15:44:
De halve dag besteed aan deel 2 omdat

spoiler:

de condition check voor de jump keek of niet 0 in plaats van groter dan 0

En dat maakte voor deel 1 geen verschil in de uitkomst, dus je merkt het ook niet

Ah thanks. Ik had hetzelfde probleem.

[Reynouts]

Deze dag was een leuke voor het zelfvertrouwen voor het sluitstuk van morgen. Ik ben benieuwd!

[Daanoz]

Done!

Zaten toch wel weer leuke puzzels bij dit jaar . Op naar volgend jaar!

spoiler:

Ik vraag me wel af waar de naughty / nice list op de home pagina op gebaseerd wordt...? Het lijkt te maken te hebben me wie de puzzels wel of niet voltooid heeft?

[ Voor 3% gewijzigd door Daanoz op 25-12-2017 09:12 ]

[Hydra]

Dag 25 in Kotlin

Erg simpel. Meeste werk zat in 't parsen van de input en het puur voor de lol zelf implementeren van de tape. Gelukkig maar; denk niet dat de fam 't leuk zou vinden als ik de hele dag bezig was

Fijne kerst iedereen!

Daanoz schreef op maandag 25 december 2017 @ 09:11:

spoiler:

Ik vraag me wel af waar de naughty / nice list op de home pagina op gebaseerd wordt...? Het lijkt te maken te hebben me wie de puzzels wel of niet voltooid heeft?

spoiler:

Donations? Gokje.

[ Voor 31% gewijzigd door Hydra op 25-12-2017 09:44 ]

[veldsla]

Dag 25 is altijd wel te doen. Eet-ze iedereen!

[Peelee]

Het zit er op, dat wordt afkicken de komende dagen..

Fijne kerst!

[Reptile209]

Hydra schreef op maandag 25 december 2017 @ 09:41:
Dag 25 in Kotlin

Erg simpel. Meeste werk zat in 't parsen van de input en het puur voor de lol zelf implementeren van de tape. Gelukkig maar; denk niet dat de fam 't leuk zou vinden als ik de hele dag bezig was

Fijne kerst iedereen!


[...]

spoiler:

Donations? Gokje.

Nope

spoiler:

/me stond namelijk in het Nice-rijtje, en heb zeker weten geen donatie gedaan . Andere optie: gebruik van een Twitter-account?

[Anoniem: 420461]

Beetje een anti-climax, maar goed. Erg leuk om te doen dit - ik ga het ook missen. Volgend jaar weer!

Reptile209 schreef op maandag 25 december 2017 @ 11:17:

spoiler:

/me stond namelijk in het Nice-rijtje, en heb zeker weten geen donatie gedaan . Andere optie: gebruik van een Twitter-account?

spoiler:

Nah...gewoon jij als nice en 9 random namen voor de andere slots

[Bee.nl]

Zo, het zit er weer op Traditiegetrouw was vandaag een simpele opdracht (php). Ik miste dit jaar wel een paar opdrachten die echt moeilijk zijn en brute-forcen niet mogelijk is. Desalniettemin was het weer erg leuk om te doen.

[ Voor 15% gewijzigd door Bee.nl op 25-12-2017 11:29 ]

[Anoniem: 1004565]

Jammer dat ik nog niet alles opgelost heb, en nu de bonus-ster niet krijg. Het valt me ook op dat ik nu niet meer bij de input van dag 25 kan, part 1 van dag 25 heb ik wel opgelost..., maar ik kom gewoon niet meer bij de input omdat 't knopje verdwenen is

Fijne kerst en gelukkig nieuwjaar allemaal!

[Anoniem: 420461]

Anoniem: 1004565 schreef op maandag 25 december 2017 @ 12:23:
Het valt me ook op dat ik nu niet meer bij de input van dag 25 kan...

http://adventofcode.com/2017/day/25/input

[Anoniem: 1004565]

Anoniem: 420461 schreef op maandag 25 december 2017 @ 12:31:
[...]

http://adventofcode.com/2017/day/25/input

yayy! hahaha, wilde mn oplossing namelijk iets beter maken dan alleen maar if's en else statements... hehehe

[ydderf]

Ik loop nog een beetje achter bij de meeste (wegens ontbreken tijd en kennis ;-)
Maar dag drie is ook opgelost met mijn beperkte python kennis.

https://github.com/ydderfBackwards/AdventOfCode2017

Ik ben alleen lang aan het klooien geweest om een twee dimensionale array te maken.

Dacht eerst dat de onderstaande code de truc deed, maar dit bleek een copy van lijsten te zijn.

code:

myArray = [[0]*Size]*Size

Daarna maar hardcoded, maar is beetje veel werk met grote array's

code:

myArray = [[0,0,0],[0,0,0],[0,0,0]]

Ook nog wat gevonden met "numpy", maar die kent Atom niet (niet verder gezocht waarom niet).

Uiteindelijk maar opgelost met:

code:

myArray = [[0 for j in range(Size)] for i in range(Size)]

Is dit de handigste manier of zijn er nog betere manieren?

[Anoniem: 420461]

Nog even gekeken, maar de eerste naughty = The Easter Bunny, eerste Nice ben ik, en daarna alleen maar willekeurige namen van de leaderboard, ongeacht het aantal sterren.

[Soultaker]

ydderf schreef op maandag 25 december 2017 @ 19:47:
Uiteindelijk maar opgelost met:

code:

myArray = [[0 for j in range(Size)] for i in range(Size)]

Is dit de handigste manier of zijn er nog betere manieren?

Zo doe ik het meestal ook. Je kunt nog kiezen voor de tussenvorm:

Python:

myArray = [[0]*Size for i in range(Size)]

Verder is in Python een dictionary vaak een goed alternatief voor een meerdimensionale array, zeker als je van te voren niet weet hoe groot je array moet worden.

Lezen en schrijven werkt dan zo:

Python:

d = dict()  # of: d = {}
d[1, 2] = 3
print(d[1, 2])  # 3

Als je de waarden wil initialiseren kan dat bijvoorbeeld zo:

Python:

d = dict(((i, j), 0) for i in range(10) for j in range(10))
print(myArray[1, 2])  # 0

Maar aangezien het hele voordeel van een dict juist is dat je de dimensies niet van te voren hoeft te bepalen, kun je beter niet initialiseren en een default-waarde gebruiken voor niet-bestaande keys. Daar zijn verschillende manieren voor:

Python:

d = dict()
print(d[1, 2] if (1, 2) in d else 0)  # 0
print(d.get((1, 2), 0))  # 0

Tenslotte kun je nog gebruikmaken van een defaultdict, wat een dictionary is die een functie meekrijgt om nieuwe waarden mee te generen. Dag 3 deel 2 kun je daarmee bijvoorbeeld zo oplossen: https://gist.github.com/m...a0e9df40fdc535#file-3b-py

[MerijnB]

Liep een beetje achter maar ben ook weer klaar voor dit jaar, het was weer leuk, alhoewel ik het gevoel heb dat het iets makkelijker was dan vorig jaar, hebben meer deelnemers dit?

[Soultaker]

Ik had sowieso het idee dat er vrij veel overlap is in het soort problemen tussen nu en vorig jaar, dus als je eerder hebt meegedaan, komt veel je bekend voor en zul je wellicht sneller een oplossing in elkaar kunnen draaien.