Advent of Code 2019

[Daanoz]

Wederom komt december eraan, voor de puzzel fanaten is de Advent of Code er dus weer! Van 1 tot en met 25 december zijn er elke dag 2 puzzels beschikbaar, om zo het grote raadsel van dit jaar op te lossen. De raadsels zijn zo opgezet dat ze het beste met een stuk programmatuur kunnen worden opgelost. Uiteindelijk krijg je elke dag jou eigen unieke input, waarbij één bepaalde output hoort.

Een puzzel is gebruikelijk in een soort verhaal vorm geschreven. Een goed voorbeeld, ook om te oefenen vind je hier.

Ook in 2015, 2016, 2017 en 2018 deed de Tweakers community mee, dus ook dit jaar kunnen we weer aan de slag:
Advent of Code 2015
Advent of Code 2016
Advent of Code 2017 Leaderboard
Advent of Code 2018 Leaderboard

Je kan je aanmelden via website: https://www.adventofcode.com. Op de website is er weer een tweakers leaderboard. Dit is dezelfde als vorig jaar, meld je hier aan met code:

Members only: Leaderboard code

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Discussie over de puzzels mag, maar probeer niets te spoilen voor de rest! (of gebruik de spoiler tag)

Members only: Deelnemerslijst

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Stuur Daanoz even een PM om ook in de lijst te komen. Zet hierbij de link naar de code en de taal/talen die je gebruikt.

[Voor 23% gewijzigd door Daanoz op 22-12-2019 13:12]

[veldsla]

Oh dear, ik zei vorig jaar nog zo hard dat ik niet mee zou doen, maar als dag 1 er straks staat dan moet het toch eventjes...En als je eenmaal begonnen bent...

Misschien van de gelegenheid gebruik maken om eens uitgebreider met Julia kennis te maken.

[steveman]

Ohja, ik wil die van 2016 eigenlijk nog afmaken

[MerijnB]

Ik ben benieuwd hoe hij dit jaar is, ik heb die van vorig jaar voor het eerst niet afgemaakt, op het eind was het wmb gewoon te veel werk voor 'even leuk'.

[Daanoz]

Eens, veel waren vorig jaar net even te veel werk om even tussendoor te doen. Ik dacht op Reddit meegekregen te hebben dat ze door de opmerkingen daar wat gingen verbeteren.

[Gropah]

Ik ben zelf ook bij dag 15 afgehaakt, precies omdat het te veel werk werd om even leuk te doen. Het was de eerste keer dat ik mee deed, dus weet niet of dat normaal was, maar ik hoop dan ook dat het dit jaar wat minder "werk" en iets meer "gepuzzel" is.

Overigens ga ik het dit jaar gebruiken om wat bekend te raken met Kotlin. Vroeger veel Java gedaan en recentelijk weer voor Android. Er zijn wat dingetjes die ik niet lekker vind werken, die in Kotlin makkelijker zouden moeten werken. Ben benieuwd.

[Sithistar]

Nr 1 op ipad met google sheets.

[Reynouts]

Dit is mijn derde keer dat ik meedoe.

Vorig jaar begonnen met C++, maar dat duurde toch te lang, omdat sommige puzzels uberhaupt erg pittig waren. Toen maar overgeschakeld naar Python, werkt toch een stuk makkelijker voor dit soort situaties.

Dit jaar ga ik weer voor Python en dan lekker zo "pythonic" mogelijk ;-)

Eerste dag was in elk geval weer erg simpel..

[Daanoz]

Ja, goed puzzeltje om erin te komen. Toch nog niet begonnen met Python en weer TypeScript gedaan, misschien later vandaag ook nog even een Python versie bouwen.

[Oogje]

Ik ga als Windows sysadmin eens kijken hoe ver ik kom met Powershell.

[Camulos]

YES! we zijn weer begonnen

[Bolukan]

Inkomer. Alleen parser gebruikt.

[farlane]

Mezelf maar weer eens pijnigen met Rust. Moet er toch een keer doorheen want Rust is veel beter dan al het andere op de hele wereld.

[armageddon_2k1]

farlane schreef op zondag 1 december 2019 @ 13:18:
Mezelf maar weer eens pijnigen met Rust. Moet er toch een keer doorheen want Rust is veel beter dan al het andere op de hele wereld.

Doen dan meteen WASM met Rust als je een echte masochist bent.

[Radiant]

Cool Ik ga het (voor zover de tijd weer toestaat ) weer proberen.

Dit wordt het jaar van de quick and dirty oplossingen denk ik

edit: In Python, want dat is nu eenmaal makkelijk. Al zou het supertof zijn om Rust hiermee te leren

[Voor 26% gewijzigd door Radiant op 01-12-2019 19:42]

[Bolukan]

Day 1: Parser en loopje
Day 2: Interpreter

spoiler:

Het lukt me achteraf, na het inleveren, het geheel te verwoorden in een formule van 145 tekens en die weer te versimpelen tot [cel 0] = constante*[cel 1]+[cel 2]+constante

[Voor 5% gewijzigd door Bolukan op 02-12-2019 13:27]

[ProAce]

Dit jaar weer eens proberen, vorig jaar niet af gemaakt, eens kijken hoever ik nu kom. Poging doen in Go, heb er niet super veel ervaring mee dus waarschijnlijk wordt het wat hacky. Zolang het werkt
https://github.com/ProAce/Advent-of-code

[ppx17]

Ik ga ook weer meedoen. Alles in php en als ik tijd/zin over heb in rust.

[tha_crazy]

Ik ga ook wederom een poging wagen (in de hoop hem deze keer wel eens af te maken )

Github: https://github.com/Vincentvwal/AdventOfCode2019
In C# en zo kort mogelijk terwijl we toch proberen leesbaar te blijven.

[Barreljan]

Ik ga ook meedoen in Python en zoals andere ook zeggen, dit keer verder komen en afmaken ipv afhaken na dag 4 ofzo.

Github: https://github.com/barreljan/aoc19

In 2017 even meegedaan maar toen was ik nog niet zo handig. Nu ook (met licensed PyCharm) een heel stuk kundiger

[Dutch_Gh0st]

Ik doe ook weer mee dit jaar, wederom in Rust, en ook in Zig.
Github: https://github.com/DutchGhost/Advent-Of-Code-2019

[kamustra]

Ik doe ook eens mee! In Matlab, daar kan ik vrij vlot mee overweg, zonder nog extra compilers of libraries te installeren.

[gekkie]

farlane schreef op zondag 1 december 2019 @ 13:18:
Mezelf maar weer eens pijnigen met Rust. Moet er toch een keer doorheen want Rust is veel beter dan al het andere op de hele wereld.

Elke regel cadeautjes unwrap()'en

[Boudewijn]

Ik doe mee met Python3. Heb afgelopen 2 jaar op vacantie elke dag wel een puzzletje opgelost. Vond de editie van vorig jaar erg veel tijd kosten, die van 2016 was een stuk goedkoper qua investering.

Eens kijken hoever ik kom. Voor mij zelf is de fun om alles netjes met TDD te doen en een beetje mooi maar efficient.

[Voor 16% gewijzigd door Boudewijn op 02-12-2019 17:07]

[veldsla]

Het is nog steeds leuk. Julia experiment gaat aardig, (1-based arrays was vooral gisteren erg jammer). Compacte scriptjes, maar wel lijkt de performance een beetje tegen te vallen, warme run op 0.2s om de boel te parsen en twee hashmapjes met 100k keys aan te maken/intersecten.

Maar Julia performance is sowieso een vak apart geloof ik, vermijden REPL / global scope, type annotaties toevoegen, maar nog steeds geen idee wanneer er gealloceerd wordt, GC tijd. Dat is met Rust toch wel even wat anders.

[Rmg]

Voor mij is het een mooi excuus om eens aan Golang te beginnen, bij dag 3 begin ik aardig performance impact te voelen, eens kijken of ik daar nog eens wat aan doe

[dcm360]

Zoals gebruikelijk ben ik ook weer begonnen in Scala, nu eens zien of ik het langer dan een week vol ga houden. Het gaat mij vooral om het vinden van de oplossing met redelijk elegante code, performance maakt mij niet echt uit (deel 2 van dag 3 duurde 1.6s).

[ProAce]

Dag 3 koste wat tijd voor ik het efficient had opgezet, uiteindelijk draaien beide oplossingen in 0.2 seconden. Al met al best tevreden

[Beneveerg]

Zijn de antwoorden voor iedereen anders?

Ik heb de day1 part one nu afgerond. Ik heb wel de input die je krijg in een lokaal bestand gezet en daarmee gewerkt. Of is het de bedoeling dat je die input ook van het web afhaalt?

[Rmg]

Beneveerg schreef op dinsdag 3 december 2019 @ 15:24:
Zijn de antwoorden voor iedereen anders?

Ik heb de day1 part one nu afgerond. Ik heb wel de input die je krijg in een lokaal bestand gezet en daarmee gewerkt. Of is het de bedoeling dat je die input ook van het web afhaalt?

Uhh wat bedoel je met de antwoorden? Het resultaat van de berekeningen zal hetzelfde zijn. Het antwoord als in de code die iedereen schrijft zal tot op zekere hoogte uniek zijn.

Hoe je die input in je programma krijgt is eigen keus.

[Beneveerg]

Met antwoorden bedoel ik inderdaad het resultaat uit de berekening. Bedankt!

[MerijnB]

Beneveerg schreef op dinsdag 3 december 2019 @ 15:28:
Met antwoorden bedoel ik inderdaad het resultaat uit de berekening. Bedankt!

De input is uniek* voor iederen, maar per persoon wel steeds hetzelfde (dus als jij vandaag de input voor dag 1 ophaalt is die hetzelfde als dat jij morgen de input voor dag 1 ophaalt).

vast niet helemaal uniek, maar iig niet voor iedereen hetzelfde.

[Voor 19% gewijzigd door MerijnB op 03-12-2019 15:32]

[kaesve]

Tot nu toe kom ik weg met een paar regels javascript direct in de console op de inputpagina. Scheelt me weer moeite om de input te downloaden en een los script te maken en runnen

Ik haal met een vrij naive oplossing in javascript ook ~0.2s per deel van dag

[armageddon_2k1]

Zo, vandaag even de eerste 3 dagen ingelopen. Leuk om te doen
Ik gebruik Kotlin overigens omdat ik daar het snelst in ben. Scala ook nog overwogen, maar is al weer iets te lang geleden en ik wil me meer buigen op het oplossen dan het leren van een taal.

In mijn eerste opzet werkte alles eigenlijk wel, dus ik ga niet verder optimizen:

code:

Day 1, Part One: [knip] in 13ms
Day 1, Part Two: [knip] in 1ms
Day 2, Part One: [knip] in 0ms
Day 2, Part Two: [knip] in 8ms
Day 3, Part One: [knip] in 142ms
Day 3, Part Two: [knip] in 140ms

[Voor 37% gewijzigd door armageddon_2k1 op 03-12-2019 17:19]

[tha_crazy]

Ik had gehoopt vandaag dag 3 ook gelijk te kunnen doen, maar ben bang dat ik daar niet aan toe ga komen.
Dus morgen een dubbele puzzel

[diabolofan]

Ik doe ook weer mee! https://github.com/gercobrandwijk/AdventOfCode
Vorig jaar na dag 14 gestopt, eens kijken hoe lang ik het nu kan volhouden..!

In ieder geval al weer wat geleerd:

spoiler:

Voor dag 3 duurt de bereking dubbel zo lang als ik een 2d array (int[,]) gebruik ipv een vector in een vector (int[][]) om het 'bord' op te slaan (C#). Sowieso vond ik dat lastig, voor mijn data had ik namelijk een 'bord' nodig van 17000x17000.. Daarbij wordt in verhouding voor het benaderen van posities in die vectoren traag, om te bepalen of dat veld al geinitialiseerd was.

[ProAce]

diabolofan schreef op dinsdag 3 december 2019 @ 21:21:
Ik doe ook weer mee! https://github.com/gercobrandwijk/AdventOfCode
Vorig jaar na dag 14 gestopt, eens kijken hoe lang ik het nu kan volhouden..!

In ieder geval al weer wat geleerd:


***members only***

spoiler:

In plaats van je predefined array zou je ook gebruik kunnen maken van een map zoals ik in mijn oplossing (die nog wel wat netter kan), zo hoef je niet een groot array te reserveren en schaalt het naar het aantal stappen die je moet zetten.

[diabolofan]

spoiler:

Ik zat er in mijn hoofd mee dat ik een x, y en een object wilde opslaan, wat dus niet lukte in een dictionary/map. Nu als key van de dictionary een string gedaan, waarbij de key dan dus is "x_y", en dan gaat het inderdaad stukje sneller. Nu op 190 ms, nog steeds niet heel goed..

[Gropah]

ProAce schreef op dinsdag 3 december 2019 @ 21:28:
[...]

spoiler:

In plaats van je predefined array zou je ook gebruik kunnen maken van een map zoals ik in mijn oplossing (die nog wel wat netter kan), zo hoef je niet een groot array te reserveren en schaalt het naar het aantal stappen die je moet zetten.

spoiler:

Ik heb het met een nested arrays geprobeerd in java kotlin en bij mijn persoonlijk input liep hij uit z'n heap. Dus toen maar overgeschakeld op de map (wat ik eigenlijk gewoon vanaf het begin had moeten doen. Scheelde ook weer hoofdpunt met offsets etc.

[Beneveerg]

Ik had mij voor genomen om meer met PowerShell te gaan doen. Nadeel is dat ik niet iets kan/wil maken wat geen doel heeft. Dit is dan ook de perfecte manier om mijzelf uit te dagen. Nette code is dan niet het doel, werkende code wel.

Dag 1 was goed te doen. Dag 2, deel 1 heb ik heel wat langer over gedaan.

https://github.com/bengreeve/AdventCode/

[momania]

Ja hoor, ben ook weer van de partij!
Geen idee weer voor hoelang, maar goed

Heb mezelf maar voorgenomen AoC++ te worden, misschien geeft dat wat extra stimulans it jaar.

[P_Tingen]

Hier nog iemand met 1-based arrays. Ik werk in Progress 4GL en ik heb de maker van AoC een berichtje gestuurd of hij volgend jaar ook eens een paar opgaven er in kan doen die uitgaan van een 1-based array, al was het alleen maar zodat de 0-based mensen ook eens een kleine achterstand hebben

Vorig jaar ook halverwege afgehaakt, dag 15 was een soort spel waarbij elfen en goblins om beurten een stap in een maze moesten doen. Dit was echt een brug te ver voor mij

[Gropah]

Die van vandaag was wel weer (erg) makkelijk. Opzich wel fijn, was een leuke manier om wat collection operations te leren in kotlin

P_Tingen schreef op woensdag 4 december 2019 @ 10:27:
Hier nog iemand met 1-based arrays. Ik werk in Progress 4GL en ik heb de maker van AoC een berichtje gestuurd of hij volgend jaar ook eens een paar opgaven er in kan doen die uitgaan van een 1-based array, al was het alleen maar zodat de 0-based mensen ook eens een kleine achterstand hebben

Misschien moet je dit opvatten als dat 0-based superieur is?

Vorig jaar ook halverwege afgehaakt, dag 15 was een soort spel waarbij elfen en goblins om beurten een stap in een maze moesten doen. Dit was echt een brug te ver voor mij

Bij dag 15 ben ik vorig jaar ook afgehaakt. Dat was niet meer een leuk puzzeltje om te maken, dat was gewoon werken.

[CMG]

Ik heb gisteren avond ook maar even de opdrachten gedaan, erg leuk om te doen. Heb ook het leaderboard gejoined, maar omdat ik zo laat begonnen ben, sta ik maar 34e, kijken of dat nog veranderd te komende dagen

[Beneveerg]

Ik loop vast op deel 2 van dag 2. Niet zozeer op het programmeer stuk, maar meer op welke berekening je moet doen.

Als een uitkomst bekend is, maar de twee inputs niet, hoe bereken je dan de inputs. Hoe heet z'n berekening?

[DataGhost]

Beneveerg schreef op woensdag 4 december 2019 @ 11:27:
Ik loop vast op deel 2 van dag 2. Niet zozeer op het programmeer stuk, maar meer op welke berekening je moet doen.

Als een uitkomst bekend is, maar de twee inputs niet, hoe bereken je dan de inputs. Hoe heet z'n berekening?

Een inverse. Maar daar is niet zomaar een algemene oplossing voor die je kan Googlen, dus zal je het zelf moeten programmeren. Het is ook niet gezegd dat dat zomaar mogelijk is, aangezien code en data door elkaar lopen, en writable zijn
Ik wil niet direct te veel hints geven omdat dan de oplossing snel duidelijk is Maar bedenk je dat de eerste paar dagen redelijk makkelijk zijn.

@MerijnB hieronder: dat is dus "te veel hints" IMO.

[Voor 14% gewijzigd door DataGhost op 04-12-2019 11:57]

[MerijnB]

Beneveerg schreef op woensdag 4 december 2019 @ 11:27:
Ik loop vast op deel 2 van dag 2. Niet zozeer op het programmeer stuk, maar meer op welke berekening je moet doen.

Als een uitkomst bekend is, maar de twee inputs niet, hoe bereken je dan de inputs. Hoe heet z'n berekening?

Als je alle mogelijke inputs probeert om te kijken welke matched?

@DataGhost tja, ik snap je, maar ik vond jou omschrijving een beetje cryptisch In ieder geval (zoals je al zei) zijn de problemen op dit moment nog zo simpel dat het niet veel uitmaakt (je kunt het nu nog oplossen met brute force).

[Voor 22% gewijzigd door MerijnB op 04-12-2019 13:18]

[CMG]

Beneveerg schreef op woensdag 4 december 2019 @ 11:27:
Ik loop vast op deel 2 van dag 2. Niet zozeer op het programmeer stuk, maar meer op welke berekening je moet doen.

Als een uitkomst bekend is, maar de twee inputs niet, hoe bereken je dan de inputs. Hoe heet z'n berekening?

spoiler: Uitleg

Ze zeggen dat je 2 input variables hebt (die je in deel 1 hebt moeten aanpassen naar 12 en 2).

De mogelijke ranges zijn 0..99 for beide.

Wat je dus moet doen, is de logica van deel 1 binnen een nested loop
[code=js]
for(verb = 0; verb <= 99; verb++)
{
for(noun = 0; noun <= 99; noun++)
{
// Hier de 'originele' functie aanroepen met deze twee waardes aangepast
// als de uitkomst gelijk is aan de gezochte waarde dan weet je welke combinatie je door moet geven.
}
}
[/code]

[P_Tingen]

Beneveerg schreef op woensdag 4 december 2019 @ 11:27:
Ik loop vast op deel 2 van dag 2. Niet zozeer op het programmeer stuk, maar meer op welke berekening je moet doen.

Als een uitkomst bekend is, maar de twee inputs niet, hoe bereken je dan de inputs. Hoe heet z'n berekening?

Als ik er echt niet uitkom, spiek ik soms even bij mensen die het wel hebben opgelost. Omdat zo ongeveer geen hond dat in mijn programmeertaal doet, moet ik het toch altijd 'vertalen'. Python oplossingen zijn vaak goed leesbaar

spoiler:

In het geval van dag 2 heb ik de berekening in een eigen functie gestopt die ik aanroep met de noun en de verb. Door alle mogelijke combinaties er een voor een in te gooien en te checken of de uitkomst is wat ik verwacht, weet ik het antwoord.

[sayang1991]

Note to self: goed lezen....

Moet zeggen dat alle oplossingen tot nu toe goed te vinden zijn al winnen ze op het moment geen schoonheidsprijs.

[P_Tingen]

Gropah schreef op woensdag 4 december 2019 @ 10:50:
Misschien moet je dit opvatten als dat 0-based superieur is?

Hahaha, laten we dáár eens een religieuze oorlog over gaan beginnen, weer eens wat anders dan spaties vs tabs

Beide hebben voor- en nadelen, maar mijn pech is dat de meerderheid het verkeerde systeem een ander systeem gebruikt dan ik. Alhoewel die meerderheid ook weer niet zó groot is, check Wikipedia: Comparison of programming languages (array) en sorteer op default base-index.

Op SO las ik: In defend of "1", most people in the world use that one. Most programmers use "0".

En ik denk dat dat de kern is van het verschil. Voor zaken die dicht bij de computer liggen is 0-based handiger, voor zaken die dingen in het 'echte' leven representeren is 1-based handiger.

[Boudewijn]

Die van vandaag is wel heel makkelijk. Paar minuten werk.


Ben nog even aan het broeden om die van gisteren te optimaliseren.

[ThomasG]

P_Tingen schreef op woensdag 4 december 2019 @ 12:05:
[...]

Hahaha, laten we dáár eens een religieuze oorlog over gaan beginnen, weer eens wat anders dan spaties vs tabs

Beide hebben voor- en nadelen, maar mijn pech is dat de meerderheid het verkeerde systeem een ander systeem gebruikt dan ik. Alhoewel die meerderheid ook weer niet zó groot is, check Wikipedia: Comparison of programming languages (array) en sorteer op default base-index.

Op SO las ik: In defend of "1", most people in the world use that one. Most programmers use "0".

En ik denk dat dat de kern is van het verschil. Voor zaken die dicht bij de computer liggen is 0-based handiger, voor zaken die dingen in het 'echte' leven representeren is 1-based handiger.

Het ligt aan de historie van de taal of het 0 of 1 is. In talen uit de C-familie was/is de array notatie sugarcoating voor geheugen adres van array + offset van het element, waardoor het dus automatisch 0-based is omdat het eerste element een offset heeft van 0. Talen die op een andere manier zijn ontstaan beginnen vaak bij 1, omdat dat "logischer" is.

[Hydra]

ThomasG schreef op woensdag 4 december 2019 @ 12:57:Talen die op een andere manier zijn ontstaan beginnen vaak bij 1, omdat dat "logischer" is.

Omdat de makers dat logischer vonden. Je kunt dan niet simpelweg iets als dit doen:

code:

lijst = a, b, c, d
willekeurigGetal = 42452443
willekeurigItem = list[willekeurigGetal modulo list.length]

Je moet dan iedere keer rekening houden met het omrekenen naar een 0-based index. Wij tellen dan misschien vanaf 1, maar als je gaat rekenen is zero-based simpeler over het algemeen. En computers zijn rekenmachines; het is voor ons makkelijker hier rekening mee te houden dan iedere keer zelf te moeten compenseren.

Het doel van 1-based talen was om het vooral voor gebruikers simpeler te maken, maar stiekem maken ze het moeilijker, omdat ze je juist dwingen complexere rekensommetjes te doen. Oftewel; het was eigenlijk gewoon een stom idee

(disclaimer: puur mijn mening natuurlijk)

[Mawlana]

Zo, heb day 1-4 net gedaan. Dag 3 heb ik lang over gedaan. Dit jaar met Python.

spoiler:

Aanvankelijk sloeg ik de coördinaten van iedere instructie op, niet de tussenliggende stappen (vb: voor R12 sloeg ik 1 coördinaat op in plaats van 12).

[armageddon_2k1]

Vandaag was echt easy

[CMG]

armageddon_2k1 schreef op woensdag 4 december 2019 @ 16:46:
Vandaag was echt easy

Yup, vanmorgen was zo gepiept

[Barreljan]

Ik zit nog in dag 3 ... toe nou Had wat in te halen

[P_Tingen]

Hydra schreef op woensdag 4 december 2019 @ 13:29:
[...]
Omdat de makers dat logischer vonden. Je kunt dan niet simpelweg iets als dit doen:

code:

lijst = a, b, c, d
willekeurigGetal = 42452443
willekeurigItem = list[willekeurigGetal modulo list.length]

Je moet dan iedere keer rekening houden met het omrekenen naar een 0-based index. Wij tellen dan misschien vanaf 1, maar als je gaat rekenen is zero-based simpeler over het algemeen. En computers zijn rekenmachines; het is voor ons makkelijker hier rekening mee te houden dan iedere keer zelf te moeten compenseren.

Het doel van 1-based talen was om het vooral voor gebruikers simpeler te maken, maar stiekem maken ze het moeilijker, omdat ze je juist dwingen complexere rekensommetjes te doen. Oftewel; het was eigenlijk gewoon een stom idee

(disclaimer: puur mijn mening natuurlijk)

Het is maar net waar je vaker mee werkt. De momenten dat ik er vuistdiep in zit is met name tijdens het debuggen en dan vind ik het persoonlijker gemakkelijker wanneer het 1-based is. Binnen de taal waar ik in werk (Progress 4GL) gebruik ik arrays vaak in combinatie met comma separated lists van dingen. En daarbij loop ik vaak door de lijst heen met een constructie als DO i = 1 TO NUM-ENTRIES(cList). De NUM-ENTRIES functie wordt erg vaak gebruikt en dan is het weer prettig dat Progress 1-based is.

Maar uiteraard ben ik niet anders gewend. En daarbij is het ook weer niet zo complex om er +1 of -1 bij te zetten. Je moet alleen wel de goede kant opgaan en je zit - natuurlijk - altijd eerst verkeerd.

[Hydra]

P_Tingen schreef op woensdag 4 december 2019 @ 20:04:
Maar uiteraard ben ik niet anders gewend.

Ja, dat is het ook vooral. Gewenning. Heb een blauwe maandag Coldfusion gedaan, ook 1-based, en ik vond het afschuwelijk.

[- peter -]

Ik ga er dit jaar ook maar weer eens mee bezig, en grijp de gelegenheid aan om Rust te leren. Maar wel op mn gemakje

[Soultaker]

Re: array indices laten beginnen bij 0 of 1: Dijkstra heeft al in 1982 overtuigend beargumenteerd dat beginnen bij 0 het meest logische is. Zie: EWD 831: Why numbering should start at zero (PDF).

[Sharkware]

Vandaag ook maar begonnen. Op mijn mobiel, vanuit mijn strandstoel in Cancún... Vrouw doet een kruiswoordpuzzel, ik AdventOfCode :-)
ps: No worries, heb al wat dagen met actie achter me, dus dagje coden kon/mocht wel.

In het leadboard te vinden onder anonymous user #758881. Tot nu toe alleen dag 1, 2 & 3 gedaan (in Python). Zodra ik thuis ben of het moeilijk wordt zal ik wel op C# overstappen.

Heb wel wat ervaring met codingame.com (echt een aanrader), maar dit is de eerste keer dat ik AoC doe.

[Voor 9% gewijzigd door Sharkware op 05-12-2019 03:56]

[P_Tingen]

Soultaker schreef op donderdag 5 december 2019 @ 00:23:
Re: array indices laten beginnen bij 0 of 1: Dijkstra heeft al in 1982 overtuigend beargumenteerd dat beginnen bij 0 het meest logische is. Zie: EWD 831: Why numbering should start at zero (PDF).

Nou, niks ten nadele van Edsger Dijkstra, maar ook hier speelt smaak een rol:

That is ugly, so for the lower bound we prefer the ≤

Zoals gezegd is het een kwestie van gewenning. Beide hebben voor en nadelen. Hét grote nadeel van 0-based vind ik de onlogica die er in opgesloten zit: het eerste element in de reeks is element 0. De tegenstelling tussen "eerste" en "nul" zit mij hier het meeste dwars.

Maar (had ik het al gezegd?) het is vooral gewenning.

[bakkerjangert]

Vandaag was niet zo moeilijk, alhoewel de hoeveelheid informatie een beetje overkill is. Meer een kwestie van goed begrijpend lezen dan dat het moeilijk is.

Heb er langer overgedaan vewacht doordat ik een string slice vergeleek met een integer en er maar niet achterkwam waarom deze toch altijd True terug geeft .

[CMG]

bakkerjangert schreef op donderdag 5 december 2019 @ 10:27:
Vandaag was niet zo moeilijk, alhoewel de hoeveelheid informatie een beetje overkill is. Meer een kwestie van goed begrijpend lezen dan dat het moeilijk is.

Heb er langer overgedaan vewacht doordat ik een string slice vergeleek met een integer en er maar niet achterkwam waarom deze toch altijd True terug geeft .

Ik vond het wel leuk dat we terug konden naar de 'cpu'; vond de eerste keer al jammer dat er geen variable instructie lengte was, dus dat was top

[CMG]

Trouwens, je kunt de opdrachten van vorige jaren ook nog doen; ik heb gisteren avond in bed nog even de eerste 5 dagen van 2015 gedaan, die zijn ook leuk

[Reynouts]

Vond deze dag redelijk saai, vooral inderdaad de vraag goed lezen en interpreteren, dan is de oplossing straight-forward. Vorig jaar waren er ook veel van dit soort assembly-like puzzels. Tot nu toe geen echte algoritmische challenge, maar die komen vast nog wel.

Gelukkig is er morgen weer een nieuwe puzzel!

[DataGhost]

P_Tingen schreef op donderdag 5 december 2019 @ 08:35:
[...]

Nou, niks ten nadele van Edsger Dijkstra, maar ook hier speelt smaak een rol:

[...]

Zoals gezegd is het een kwestie van gewenning. Beide hebben voor en nadelen. Hét grote nadeel van 0-based vind ik de onlogica die er in opgesloten zit: het eerste element in de reeks is element 0. De tegenstelling tussen "eerste" en "nul" zit mij hier het meeste dwars.

Maar (had ik het al gezegd?) het is vooral gewenning.

Mja, een aantal veelgebruikte wiskundige operaties hebben gewoon een natuurlijke tendens om op 0-indexed resultaten uit te komen, zoals het eerder aangehaalde voorbeeld van de modulo-operator bijvoorbeeld. Of als je een 1D-array hebt met daarin tupels van 3 elementen, ga je met 1-indexed gauw de mist in als je daar doorheen wilt loopen om van elke het eerste element te krijgen.

code:

// 0-indexed
for(int i=0; i<10; i++) print(waa[3*i]);

// 1-indexed
for(int i=1; i<=10; i++) print(waa[1+3*(i-1)])

Ik weet wel wat ik netter vind

Je moet "eerste" en "nul" misschien conceptueel zien als "nul elementen voorbij het eerste element", dat zou kunnen helpen voor je begrip.

[DRaakje]

Lijkt erg op de synacor challenge die ook van dezelfde maker is. Ik vind het wel gaaf.

[P_Tingen]

Reynouts schreef op donderdag 5 december 2019 @ 11:16:
Vond deze dag redelijk saai, vooral inderdaad de vraag goed lezen en interpreteren, dan is de oplossing straight-forward. Vorig jaar waren er ook veel van dit soort assembly-like puzzels. Tot nu toe geen echte algoritmische challenge, maar die komen vast nog wel.

Gelukkig is er morgen weer een nieuwe puzzel!

Ik heb eigenlijk een hekel aan dit soort opgaven. Het lijkt meer een opgave in tekstverklaren dan logisch nadenken. En soms zitten er zinnen in die je echt wel een aantal keer moet lezen om te snappen wat hij bedoelt. Gelukkig heeft hij wel vaak testvoorbeelden erbij.

[Hydra]

P_Tingen schreef op donderdag 5 december 2019 @ 13:13:
Ik heb eigenlijk een hekel aan dit soort opgaven. Het lijkt meer een opgave in tekstverklaren dan logisch nadenken. En soms zitten er zinnen in die je echt wel een aantal keer moet lezen om te snappen wat hij bedoelt. Gelukkig heeft hij wel vaak testvoorbeelden erbij.

Helemaal mee eens. Vorig jaar was het ook daardoor dat ik op een gegeven moment gekapt ben. Het kostte steeds meer tijd om alles te interpreteren, en er zaten enorm veel stappen in. Het was niet complex, maar gewoon veel. En dan gaat 't al snel op gewoon werk lijken.

[Boudewijn]

Ja dat heb ik met die van vandaag ook wel. Erg jammer, dit zijn wel de dingen waarop ik afhaak

[ProAce]

Persoonlijk vond ik het dan weer een erg leuke om te implementeren. Die mathematisch zware opdrachten zijn weer veel moeilijker. Gelukkig is er voor iedereen wat

[CMG]

Wat ik ook prettig vind, is dat, door de manier waarop ik deel een oplos, het aanpassen zodat hij deel 2 ook doet, vaak makkelijk en goed gaat, heb ook al gezien dat mensen door de insteek steeds opnieuw moeten beginnen, dan is de lol er ook snel van af denk ik.

[Boudewijn]

Ja dat sowieso. Ik merk dat ik heel erg focus op mooie code schrijven ipv snelle of korte code... en dingen overengineer. Dan is een extra feature bijna altijd semi-gratis.

[Gropah]

Boudewijn schreef op donderdag 5 december 2019 @ 22:26:
[...]
Dan is een extra feature bijna altijd semi-gratis.

Dat dacht ook ook voor de intopcode machine, maar ik zag die parameter modes even niet aankomen, dus daar ben ik nog wel even mee bezig geweest omdat ik toen een groot deel maar herschreven heb

[Boudewijn]

Uhh ja dat is wel een zure change ja. Ik ben er vanochtend ff aan begonnen en dacht toen "jeetje wat ben ik weer lekker tijd aan het opstoken" . Ach ja.


Zo maar even afmaken.

[P_Tingen]

Ik probeer er vaak al een beetje rekening mee te houden door de data op een gestructureerde manier op te slaan. Je weet nooit wat het tweede deel is, maar vaak moet je iets 'extra' doen met de data

[Hydra]

Vandaag vond ik wel weer erg leuk; tree/graph traversal problemen zijn wat mij betreft 'echte' CS problemen en vind ik veel leuker dan gewoon veel moeten implementeren.

P_Tingen schreef op vrijdag 6 december 2019 @ 08:24:
Ik probeer er vaak al een beetje rekening mee te houden door de data op een gestructureerde manier op te slaan. Je weet nooit wat het tweede deel is, maar vaak moet je iets 'extra' doen met de data

Ik werk zo weinig mogelijk vooruit voor deel 2 als ik deel 2 nog niet gelezen heb. Heb toch gemerkt dat 9 van de 10 keer je verkeerd zit

[Voor 50% gewijzigd door Hydra op 06-12-2019 10:40]

[P_Tingen]

Mee eens, ik vond die van vandaag ook wel leuk. Mooi daaraan vind ik dat je het met optimalisatie moet doen. Mijn eerste poging had dat niet waardoor het eindeloos bleef doorgaan.

@Hydra ja, ik bedoel eigenlijk meer dat ik er rekening mee hou door een beetje netjes te programmeren zodat aanpassingen nog goed mogelijk zijn.

[Voor 29% gewijzigd door P_Tingen op 06-12-2019 11:07]

[ProAce]

Ik ben nog wel benieuwd hoe anderen dit qua optimalisatie aangepakt hebben, ik heb het idee dat mijn oplossing nog efficienter kan maar hoe weet ik niet

[DataGhost]

P_Tingen schreef op vrijdag 6 december 2019 @ 11:06:
Mee eens, ik vond die van vandaag ook wel leuk. Mooi daaraan vind ik dat je het met optimalisatie moet doen. Mijn eerste poging had dat niet waardoor het eindeloos bleef doorgaan.

Ik denk dat je dan een verkeerde aanpak hebt gebruikt, aan redelijk wat logische oplossingen valt niks te optimaliseren en die zijn sowieso snel genoeg Mijn oplossingen voor vandaag lopen allebei in O(n) dus daar valt al niks meer aan te verbeteren. Ik heb een klein beetje moeite met me voorstellen hoe precies, maar volgens mij kan je ook wel O(n^2) algoritmes of langzamere algoritmes schrijven maar de input lijkt me nog dermate klein (bij mij 859 regels) dat zelfs zulke oplossingen snel moeten draaien.

[Gropah]

ProAce schreef op vrijdag 6 december 2019 @ 11:12:
Ik ben nog wel benieuwd hoe anderen dit qua optimalisatie aangepakt hebben, ik heb het idee dat mijn oplossing nog efficienter kan maar hoe weet ik niet

spoiler:

Als ik je code zo snel lees, ga je nu voor elke unit in orbit de hele keten af om te bepalen wat de afstand is tot COM. Stel je hebt de keten COM-A-B-C-D-E en aan E hangen 10 nodes, dan ga voor het berekenen van het totaal aantal orbits je erg vaak door de keten heen, terwijl dat niet per se nodig is.

Wat ik heb gedaan is een tree gemaakt, waar ook de diepte in word opgeslagen, dus als {COM, 0}-{A,1}-{B,2} etc etc. Bij het berekenen van het aantal orbits hoef je dan maar 1 keer compleet door je datastructuur te gaan.

[P_Tingen]

@DataGhost stuur @Daanoz dan even een (GitHub) link waar ik je code kan bekijken, dan zet hij het in de TS.
Ik vind het altijd rete-interessant om te zien hoe anderen het aanpakken.

spoiler:

Deel 1 heb ik recursief gedaan door van elk object te bepalen hoeveel stappen het tot aan 'com' verwijderd is. Mijn fout was dat ik dat voor ELK object deed. Dus bij het schema hieronder berekende ik de afstand van bv D, maar ook van C, terwijl je bij D alleen maar de afstand van C + 1 hoeft te doen. Dus door van elk punt bij te houden hoe ver het van COM verwijderd was, ging mijn programma van oneindig naar retesnel

        G - H       J - K - L
       /           /
COM - B - C - D - E - F
               \
                I

Edit: @Gropah gmta

[ProAce]

Gropah schreef op vrijdag 6 december 2019 @ 11:25:
[...]

spoiler:

Als ik je code zo snel lees, ga je nu voor elke unit in orbit de hele keten af om te bepalen wat de afstand is tot COM. Stel je hebt de keten COM-A-B-C-D-E en aan E hangen 10 nodes, dan ga voor het berekenen van het totaal aantal orbits je erg vaak door de keten heen, terwijl dat niet per se nodig is.

Wat ik heb gedaan is een tree gemaakt, waar ook de diepte in word opgeslagen, dus als {COM, 0}-{A,1}-{B,2} etc etc. Bij het berekenen van het aantal orbits hoef je dan maar 1 keer compleet door je datastructuur te gaan.

spoiler:

Dat is inderdaad een nettere oplossing. Is jouw code ook ergens inzichtelijk? Wil AoC graag aanpakken om wat nieuwe technieken te leren, by trade ben ik Electrical Engineer en ik schrijf wel wat embedded code, maar dit is een vak apart weer

[Gropah]

ProAce schreef op vrijdag 6 december 2019 @ 11:33:
[...]

spoiler:

Dat is inderdaad een nettere oplossing. Is jouw code ook ergens inzichtelijk? Wil AoC graag aanpakken om wat nieuwe technieken te leren, by trade ben ik Electrical Engineer en ik schrijf wel wat embedded code, maar dit is een vak apart weer

spoiler:

Ik heb mijn code wel op github staan, maar in een private repo en ik denk niet dat ik die atm ga openbare hier op tweakers. Maar ik stuur je wel even de code in een DM.

[bakkerjangert]

Vandaag vond ik een zeer leuk probleem! Een probleem waar je eerst over na moet denken voor je begint met programmeren en welke op diverse manieren aan te vliegen is. Ben wel tevreden over mijn oplossing.

spoiler:

Ik heb een lijst met paden bepaald door eerst naar de eind nodes te zoeken en vandaar af steeds een stap terug te doen. Uit de tekst maakte ik op dat elke node maar één parentnode heeft dus per eind node is er maar één pad mogelijk. Zodoende een lijst gekregen met alle mogelijke paden waarmee de oplossing eenvoudig te bepalen was. Tevens was dit handige input voor part 2!

[Hydra]

ProAce schreef op vrijdag 6 december 2019 @ 11:12:
Ik ben nog wel benieuwd hoe anderen dit qua optimalisatie aangepakt hebben

M'n twee oplossingen (deel 1/2) samen hebben een koude runtime van 90ms ofzo, dan ga ik me niet druk maken over optimalisaties anders dan de code zo simpel mogelijk maken

Het werkt heel simpel met hash-table lookups en die zijn O(1)

[Voor 11% gewijzigd door Hydra op 06-12-2019 11:56]

[BernardV]

bakkerjangert schreef op vrijdag 6 december 2019 @ 11:48:
Vandaag vond ik een zeer leuk probleem! Een probleem waar je eerst over na moet denken voor je begint met programmeren en welke op diverse manieren aan te vliegen is. Ben wel tevreden over mijn oplossing.

spoiler:

Ik heb een lijst met paden bepaald door eerst naar de eind nodes te zoeken en vandaar af steeds een stap terug te doen. Uit de tekst maakte ik op dat elke node maar één parentnode heeft dus per eind node is er maar één pad mogelijk. Zodoende een lijst gekregen met alle mogelijke paden waarmee de oplossing eenvoudig te bepalen was. Tevens was dit handige input voor part 2!

spoiler:

Precies dit inderdaad, omdat je maar 1 parent hebt heb ik twee "lijsten" gemaakt van YOU->COM en SAN->COM, op de index van de eerste match in YOU is het dan alleen de afstand van die index tot SAN daarbij tellen. Dit resulteert in een oplossing van een 20ms volgens de CLI time functie

[ProAce]

Hydra schreef op vrijdag 6 december 2019 @ 11:55:
[...]


M'n twee oplossingen (deel 1/2) samen hebben een koude runtime van 90ms ofzo, dan ga ik me niet druk maken over optimalisaties anders dan de code zo simpel mogelijk maken

Het werkt heel simpel met hash-table lookups en die zijn O(1)

Mijn oplossingen samen draaien in 12ms, maar daarom ben ik nog steeds wel geïnteresseerd in manieren om slimmer met data om te gaan. Zoals bij dag 3 heb ik veel slimmere oplossingen gezien dan die van mij (als hobby programmeur) en dat is interessant om van te leren

[DataGhost]

P_Tingen schreef op vrijdag 6 december 2019 @ 11:29:
@DataGhost stuur @Daanoz dan even een (GitHub) link waar ik je code kan bekijken, dan zet hij het in de TS.
Ik vind het altijd rete-interessant om te zien hoe anderen het aanpakken.

spoiler:

Deel 1 heb ik recursief gedaan door van elk object te bepalen hoeveel stappen het tot aan 'com' verwijderd is. Mijn fout was dat ik dat voor ELK object deed. Dus bij het schema hieronder berekende ik de afstand van bv D, maar ook van C, terwijl je bij D alleen maar de afstand van C + 1 hoeft te doen. Dus door van elk punt bij te houden hoe ver het van COM verwijderd was, ging mijn programma van oneindig naar retesnel

        G - H       J - K - L
       /           /
COM - B - C - D - E - F
               \
                I

Edit: @Gropah gmta

Ik heb het niet op een publieke plek staan, ik heb een gist gemaakt van mijn oplossing van vandaag. Niet de netste code misschien, mja, het werkt en het is lineair Ik run dit in een custom frameworkje dus eigenlijk is alleen solveInstance (en getpath) boeiend.

Het eerste deel is dus een BFS en voor het tweede deel lees ik de boel andersom in (dus wordt m'n mapping 1:1 ipv 1:n) zodat ik heel makkelijk het pad terug naar COM kan vinden en het gezamelijke deel van de gezamelijke lengte af haal.

[Voor 10% gewijzigd door DataGhost op 06-12-2019 12:44]

[veldsla]

Ik heb een lekkere smerige oplossing voor deel 2, maar wel weer wat Julia dingen geleerd om te (mis)bruiken zoals missing values.

[Wintervacht]

P_Tingen schreef op donderdag 5 december 2019 @ 08:35:Hét grote nadeel van 0-based vind ik de onlogica die er in opgesloten zit: het eerste element in de reeks is element 0. De tegenstelling tussen "eerste" en "nul" zit mij hier het meeste dwars.

Bekijk het eens zo: ga met een stopwatch de tijd opnemen, milliseconden enzo daargelaten.
Je begint tellen bij 0, niet bij 1. Veel mensen beginnen bij hardop tellen bij 1, wat betekent dat er bij '2' welgeteld 1 seconde is verstreken. Dat is natuurlijk niet logisch.
Wanneer je bij 0 begint en je komt bij 1 aan, is er 1 eenheid (seconde, zandkorrel in de loper, array entry) verstreken/aanwezig.

Een array met 0-index is wat mij betreft een stuk logischer dan een 1-index.

[P_Tingen]

Wintervacht schreef op vrijdag 6 december 2019 @ 14:52:
[...]
Wanneer je bij 0 begint en je komt bij 1 aan, is er 1 eenheid (seconde, zandkorrel in de loper, array entry) verstreken/aanwezig.

En terwijl je in die seconde zit, hoe noem je die dan? Ik zou die de "eerste" seconde noemen. Noem je die bij 0-based dan de "nulste"?

[DataGhost]

Het verschil is vooral dat je met de ene telt hoeveel je er gehad hebt, en met de andere aan welke je begonnen bent. Veel mensen tellen op de snelweg hun twee seconden afstand ook als 1... 2! en dat werkt dus niet Bovendien, als je geboren wordt begin je ook bij 0. Dat is inderdaad je eerste levensjaar maar je bent nog 0, totdat je een keer jarig bent geweest. Zo onnatuurlijk is het dus ook weer niet.

[P_Tingen]

Nou ja, ik vind het prima verder. De taal waar ik in werk is 1-based. En of ik dat nou leuk vind of niet, ze gaan het niet veranderen. Daarbij ben ik ook niet anders gewend, het is alleen lastig wanneer ik met C# of Python aan het knutselen ben omdat ik er nog niet aan gewend ben.

[JeroenTheStig]

Ik doe dit jaar ook mee aan Advent of Code, en alhoewel ik een achterstand had in te halen, beleef ik er wel veel plezier aan. Ik vind het vooral erg tof om de GoF-patterns er op los te laten (zoals in één van de eerste opdrachten de interpreter pattern) en vandaag moest ik even mijn data structures en algoritme kennis wat oppoetsen om van 'YOU' naar 'SAN' te reizen.

spoiler:

In mijn dagelijkse werkzaamheden gebruik ik eigenlijk nooit zaken als backtracking, maar voor de opdracht van vandaag had ik dat wel nodig en ik was blij verrast dat ik uiteindelijk zonder te googelen uit dit backtrack-algoritme ben gekomen. Dat terwijl het denk ik al wel weer een jaar of 10 geleden is dat ik dergelijke oplossingen heb uitgeprogrammeerd.

[BernardV]

P_Tingen schreef op vrijdag 6 december 2019 @ 15:20:
[...]

En terwijl je in die seconde zit, hoe noem je die dan? Ik zou die de "eerste" seconde noemen. Noem je die bij 0-based dan de "nulste"?

Nee, dan zit je in de eerste seconde. Zie het als een levensjaar, iemand die net geboren is zit in het eerste levensjaar, maar is pas 1 als er daadwerkelijk een jaar verstreken is, tot die tijd is de leeftijd 0 jaar.

//EDIT: NVM, ik las niet door @DataGhost zei precies hetzelfde.

[Voor 7% gewijzigd door BernardV op 06-12-2019 22:14]

[P_Tingen]

Hoewel ik zelf over 0 versus 1-based arrays begonnen ben, stel ik voor dat we er over ophouden of anders een apart topic openen, alhoewel dat een vruchteloze exercitie zal zijn.

Zoals Wim Kan al ooit zei over discussie tussen wel- en niet-gelovigen: het lijkt op een wedstrijd tussen hockeyspelers en voetballers. De regels zijn een constant punt van discussie en over het gewenste formaat van de bal zullen ze tot in lengte van dagen van mening verschillen.