Advent of Code 2020

[evanraalte]

Swedish Clown schreef op woensdag 16 december 2020 @ 16:38:
Same here, ben bij lange na nog nooit zo ver gekomen als dit jaar. Moet wel zeggen dat dit jaar ook veel leuker is dan vorig jaar met op zichzelf staande puzzels in plaats van een compleet software pakket in elkaar schroeven... (IntCode anyone...). Dat doe ik op me werk wel of wanneer ik bijdraag aan Open Source projecten

Yet.. Ik verwacht nog steeds een follow up op dag 8 haha!

[Varienaja]

Mijn bloated code nog voor vandaag. (Ook ik ben al verder dan ik ooit gekomen ben met Advent of Code. Het helpt dat ik elke dag precies die ene nieuwe opgave doe. Als je er een handvol moet inhalen duurt het veels te lang.)

[Hydra]

Heb een paar jaar afgemaakt, maar heb nu sowieso al verder dan vorig jaar

[Swedish Clown]

evanraalte schreef op woensdag 16 december 2020 @ 16:58:
[...]


Yet.. Ik verwacht nog steeds een follow up op dag 8 haha!

Same here en ik me code is compleet voorbereid daarvoor Met een beetje geluk ben ik in enkele minuten klaar.

[Hydra]

Ben met AoC 2015 begonnen. Die heb ik destijds in Java/Scala gedaan en ga ik nu ook omzetten in Kotlin. Wil ook toch ooit 2019 af gaan maken. Toch mooi om gewoon 'alles' te hebben.

[ZieglerNichols]

Ik vind dit jaar tot nu toe ook beter gaan dan vorige jaren. Hopelijk kan ik dit jaar alles afmaken. Vorige jaren altijd wel ergens afgehaakt.

[Mschamp]

Was mijn oplossing voor vandaag vergeten pushen blijkbaar. Bij deze toch nog gedaan: https://github.com/mscham...blob/master/2020/Day16.cs

[Swedish Clown]

Jezus wat heb ik er een puinzooi van gemaakt... Zat enorm te kutten met het bepalen van de posities waar ik zie dat veel anderen dit "op het oog" doen wilde ik dit gewoon direct in de code hebben staan.

[Kazu]

Ik ben helemaal verbaasd dat ik dit event nu voor het eerst tegen kom Waarom hoor ik hier nu pas over?!

Ontzettend leuk gedaan, overigens! Meteen door alle puzzels van de eerste vier dagen gegaan, en hopelijk heb ik de tijd en motivatie om nog voor kerst helemaal bij te zijn

Ik heb mezelf in ieder geval meteen even aangemeld voor het Tweakers leaderboard, en ook even een DM gestuurd. De enige die het in Golang doet, zo te zien

[heuveltje]

code:

['departure platform', 16]
['departure time', 10]
['departure track', 17]
['departure location', 4]
['departure date', 7]
['departure station', 0]
['arrival track', 13]

Heb ik weer hoe de f kom ik ergens aan een 0
Nu te laat, morgen maar verder debuggen

[Soultaker]

heuveltje schreef op donderdag 17 december 2020 @ 00:20:
Heb ik weer hoe de f kom ik ergens aan een 0
Nu te laat, morgen maar verder debuggen

Zijn dat je kolomnummers (i.e. tussen 0 en 20?) Daar kan best een 0 tussen zitten.

[heuveltje]

Soultaker schreef op donderdag 17 december 2020 @ 00:23:
[...]

Zijn dat je kolomnummers (i.e. tussen 0 en 20?) Daar kan best een 0 tussen zitten.

Lifesaver !!!
Was inderdaad kolommen aan het vermenigvuldigen ipv de waardes

Krijg je er van als je dingen nog snel af wil maken.
Weer een sterretje erbij

* heuveltje is naar bed

[Varienaja]

Woei vandaag was Dag 11 in het kwadraat! Tijd heb ik tijd verloren door diepe for-nestings en dom gekozen variabelenamen. Geluk bij een ongeluk was dat ik de kinderen uit bed moest halen en te eten geven. Toen ik na een half uur terug bij de pc kwam, stond het correcte antwoord voor onderdeel B al klaar.

Code presenteer ik nog niet. Die moet eerst opgeschoond en vooral performanter gemaakt worden.

[Dido]

Zo, deel 2 was makkelijk vandaag, maar over deel 1 heb ik veel te lang gedaan

spoiler:

Eerst veel tijd kwijtgeraakt omdat ik de voorbeeldinput niet begreep. De subreddit heeft me geholpen om de voorbeelden juist te interpreteren.
Daarna mezelf het leven zuur gemaakt door mijn x/y/z coordinaten om te gooien om de tussenresultaten makkelijker te tonen, maar omdat ik dat maar half gedaan had sloeg het resultaat als *** op Dirk.

Deel twee was eenvoudig refactoren naar 1 extra dimensie, die ging in 1 keer goed.

[ydderf]

Ligt het aan mij dat ik het voorbeeld van dag 17 niet snap?

Voorbeeld input z=0, cycle 0 (ik heb de # vervangen voor letters)

code:

.A.
..B
CDE

A -> 1 actieve buur (B ) -> wordt niet actief
B -> 3 actieve buur (ADE) -> blijf actief
C -> 1 actieve buur (D) -> wordt niet actief
D -> 3 actieve buur (BCE) -> blijf actief
E -> 2 actieve buur (BD) -> blijf actief

Dan verwacht ik voor z=0, cycle 1:

code:

...
X.B
.DE

X was inactief maar had A, C en D als actieve buren, dus moet actief worden.

Maar volgens het voorbeeld is het:

code:

#.#
.##
.#.

Ik heb de tekst 10x doorgelezen en nog een bak koffie genomen, maar zie niet waar mijn denkfout zit....

Edit: Het duurde ff, maar het kwartje is gevallen. Iets ruimer kijken dan wat je ziet....

[ Voor 6% gewijzigd door ydderf op 17-12-2020 11:25 ]

[Dido]

ydderf schreef op donderdag 17 december 2020 @ 08:08:
Ik heb de tekst 10x doorgelezen en nog een bak koffie genomen, maar zie niet waar mijn denkfout zit....

Bekend probleem.

Lege rijen/kolommen worden niet getoond.

Als je de voorbeeldoutput leest als:

code:

.....
.....
.#.#.
..##.
..#..

Wordt het al duidelijker (en zie je dat jouw verwachting ook niet helemaal correct is )

[Varienaja]

Dido schreef op donderdag 17 december 2020 @ 08:19:
Lege rijen/kolommen worden niet getoond.

Oh ja nu zie ik het ook. Vies voorbeeld zeg! Omdat ik tijdens het coderen een grid toonde dat zeker groot genoeg was, was me dit niet opgevallen.

[Mschamp]

Vond vandaag nog meevallen. Al vermoed ik dat het beter kan, is nogal veel kopieren en plakken bij aan te pas gekomen en heel veel lussen in lussen. Misschien probeer ik het later nog wat beter te maken. https://github.com/mscham...blob/master/2020/Day17.cs

[evanraalte]

https://github.com/evanra...lob/master/day17/day17.py

spoiler:

Had een vrij mooie part1 implementatie gemaakt, helaas zonder schaalbaarheid in coordinaten.. Voor tijd redenen maar niet gekozen om part 1 te herschrijven zodat de code toepasbaar was voor deel 2. Schaalbaarheid zou daarnaast ook mogelijk ten koste gaan van de leesbaarheid.


Indien iemand een tip heeft om de code in deze structuur wat schaalbaarder, doch leesbaar te houden, dan hoor ik het graag

[Dricus]

Dag 17 (Kotlin)

Zo, even mijn spuuglelijke code delen (zodat @Varienaja weet dat hij zich nergens voor hoeft te schamen ). Eerlijk gezegd vond ik deze niet heel bijzonder. Het is vooral een probleem dat zich erg lastig laat debuggen en zich heel goed leent voor subtiele off-by-1 foutjes. Ik vond het vooral "tedious".

[Dricus]

Dido schreef op donderdag 17 december 2020 @ 08:02:
als *** op Dirk.

Hee, dat ben ik!

[ Voor 20% gewijzigd door Dricus op 17-12-2020 09:05 ]

[armageddon_2k1]

Dag 17 in Kotlin

Deze was niet heel moeilijk. Ik had hem redelijk goed opgezet voor Part 1. Wat alleen teveel tijd kwijt met de print-routine, terwijl ik die helemaal niet nodig had.

Voor Part 2 trapte ik bijna in de valkuil het veel te veel te gaan generaliseren. Maar ik heb het gewoon lekker lomp gedaan en generiek gemaakt voor 3 en 4 dimensies. Niet voor N dimensies. Ook mijn neighborcalculatie kan vast mooier, maar in had geen zin meer in een generieke 'combinatie'-functie schrijven. Flatmap galore!

spoiler:

Enige waar je op moet letten dat in part 2 alles zich in w=0 afspeelt en dus ook de neighbors alleen maar w=0 kunnen zijn.

[ Voor 10% gewijzigd door armageddon_2k1 op 17-12-2020 09:14 ]

[eamelink]

Leuk puzzeltje . Deel 2 kostte ongeveer tien seconden

spoiler:

Heb geen 'ruimtelijke' representatie gebruikt. Puur een lijst met actieve posities, die elk een bericht sturen naar alle aanliggende posities. Per positie de binnenkomende berichten opgeteld, en daarna aan de hand van de criteria gefilterd op wat er dan actief blijft, danwel wordt. Dat is de nieuwe set.

Wederom lekker ge-fold-left dus

[ Voor 6% gewijzigd door eamelink op 17-12-2020 09:20 ]

[armageddon_2k1]

eamelink schreef op donderdag 17 december 2020 @ 09:17:
Leuk puzzeltje . Deel 2 kostte ongeveer tien seconden

spoiler:

Heb geen 'ruimtelijke' representatie gebruikt. Puur een lijst met actieve posities, die elk een bericht sturen naar alle aanliggende posities. Per positie de binnenkomende berichten opgeteld, en daarna aan de hand van de criteria gefilterd op wat er dan actief blijft, danwel wordt. Dat is de nieuwe set.

Wederom lekker ge-fold-left dus

Elegant! Heb je code om te delen?

[Hydra]

Ik lees volgens mij compleet verkeerd. Hoe kan je van:

code:

z=0
.#.
..#
###

Naar:

code:

z=0
#.#
.##
.#.

Gaan? 0,0,0 is inactive en heeft in cycle nul 1 neighbor. "If a cube is inactive but exactly 3 of its neighbors are active, the cube becomes active. Otherwise, the cube remains inactive." Hoe dan???

Edit: Ah shit, wat @Dido dus zegt. Zucht.

Ik vind 'em stom.

[ Voor 9% gewijzigd door Hydra op 17-12-2020 09:40 ]

[Verwijderd]

Deze was echt makkelijk;)

spoiler:

Matlab convn functie:
data(:,:,n,n)=input challenge
kernel=ones(n,n,n,n)
dan 6 keer: data functi van convn(data,kernel)
(beetje spelen met voorwaarden)
en dan alles optellen en voila.

ja verliest wat met string handling in inlezen van complexe structuren maar voor dit soort spul is het onverslaanbaar

[eamelink]

armageddon_2k1 schreef op donderdag 17 december 2020 @ 09:29:
[...]


Elegant! Heb je code om te delen?

https://gist.github.com/e...2387f30ee237ab42b301c4ad2

[Hydra]

Oh lol, heb deel 1 nu werkend!

spoiler:

Heb een hele mooie Point3D class gemaakt, maar ja, deel 2 heeft een extra dimensie. Oops

[eamelink]

Jullie zijn trouwens wel doorzetters hoor, volgens de algemene stats op AoC is er minder dan 20% van de begingroep over, maar op het Tweakers leaderboard doet nog zo'n beetje de helft lekker mee

Zo stijg ik natuurlijk nooit in de ranking!

[ZieglerNichols]

Verwijderd schreef op donderdag 17 december 2020 @ 09:45:
Deze was echt makkelijk;)

spoiler:

Matlab convn functie:
data(:,:,n,n)=input challenge
kernel=ones(n,n,n,n)
dan 6 keer: data functi van convn(data,kernel)
(beetje spelen met voorwaarden)
en dan alles optellen en voila.

ja verliest wat met string handling in inlezen van complexe structuren maar voor dit soort spul is het onverslaanbaar

Nice! Ik heb zelf die

spoiler:

convn()

functie zitten klussen : https://pastebin.com/iMcMu4Th

[Reynouts]

Varienaja schreef op donderdag 17 december 2020 @ 07:38:
Woei vandaag was Dag 11 in het kwadraat! Tijd heb ik tijd verloren door diepe for-nestings en dom gekozen variabelenamen. Geluk bij een ongeluk was dat ik de kinderen uit bed moest halen en te eten geven. Toen ik na een half uur terug bij de pc kwam, stond het correcte antwoord voor onderdeel B al klaar.

Code presenteer ik nog niet. Die moet eerst opgeschoond en vooral performanter gemaakt worden.

Jammer, het is juist leuk en interessant om te zien waar je mee komt in eerste instantie!

eamelink schreef op donderdag 17 december 2020 @ 09:46:
[...]


https://gist.github.com/e...2387f30ee237ab42b301c4ad2

Toffe manier om het zo op te lossen

evanraalte schreef op donderdag 17 december 2020 @ 08:35:
https://github.com/evanra...lob/master/day17/day17.py

spoiler:

Had een vrij mooie part1 implementatie gemaakt, helaas zonder schaalbaarheid in coordinaten.. Voor tijd redenen maar niet gekozen om part 1 te herschrijven zodat de code toepasbaar was voor deel 2. Schaalbaarheid zou daarnaast ook mogelijk ten koste gaan van de leesbaarheid.


Indien iemand een tip heeft om de code in deze structuur wat schaalbaarder, doch leesbaar te houden, dan hoor ik het graag

Leuk om te zien. Ik heb een vergelijkbare opzet gekozen, waardoor deel 2 deel 1 "opgegeten" heeft Helaas dus geen directe tip om het schaalbaar te maken, maar denk dat het wel prima te doen is met wat extra variabelen over de dimensies. Ik heb er wel voor gekozen om direct de "#" om te zetten naar 1 en "." naar 0. Ik heb ook itertools.product gebruikt, erg handig voor de headings.

Om tuples op te tellen kun je ook iets gebruiken in de vorm van

code:

tuple(map(sum, zip(position, heading)))

Misschien niet leesbaarder, maar wel schaalbaar voor langere tuples. Heb je al een ministapje naar een schaalbare oplossing

[Verwijderd]

ZieglerNichols schreef op donderdag 17 december 2020 @ 10:10:
[...]


Nice! Ik heb zelf die

spoiler:

convn()

functie zitten klussen : https://pastebin.com/iMcMu4Th

Ook leuk!, voor die game of life (stoelendans opdracht) kon ie overigens ook gebruikt worden, ook voor deel 2

[Hydra]

Zo, en done. Wat een domme fouten heb ik gemaakt. Toch grappig dat halverwege m'n eerste kop koffie wel 't kwartje viel.

Dag 17 in Kotlin

spoiler:

Eerst heel veel tijd gestoken in een 3D point class, generiek om te kunnen hergebruiken. Blijkt natuurlijk in deel 2 dat er een extra dimensie bijkomt. Dus de hele bende maar gegeneraliseerd naar lijsten van coordinaten...

[Hydra]

eamelink schreef op donderdag 17 december 2020 @ 10:07:
Jullie zijn trouwens wel doorzetters hoor, volgens de algemene stats op AoC is er minder dan 20% van de begingroep over, maar op het Tweakers leaderboard doet nog zo'n beetje de helft lekker mee

Zo stijg ik natuurlijk nooit in de ranking!

Dat valt mij ook vies tegen. Voorgaande jaren lukte het me best aardig om in de top 10 te blijven, maar er zitten nu een heel stel fanatiekelingen tussen

[Emiel L]

Mijn oplossing in Swift hier.

Ik heb gekozen om alles met sets te doen.

spoiler:

De input wordt geparsed naar een set met alleen de actieve coordinaten er in. Om te itereren wordt een nieuwe set coordinaten gemaakt met daarin alle actieve coordinaten plus hun omliggende coordinaten.
Daar itereer ik doorheen door per coordinaat het aantal actieve omliggende coordinaten te tellen in de huidige set. Voldoet deze aan de criteria dan voeg ik 'm toe aan een nieuwe set. Deze nieuwe set vervangt de beginset en zo begint het proces weer opnieuw.

Running time: 1.9432059526443481 seconden.

[ Voor 3% gewijzigd door Emiel L op 17-12-2020 10:38 ]

[veldsla]

Forgive me DRY-god, for I have copy-pasted

[Hydra]

armageddon_2k1 schreef op donderdag 17 december 2020 @ 09:13:
Dag 17 in Kotlin

Deze was niet heel moeilijk. Ik had hem redelijk goed opgezet voor Part 1. Wat alleen teveel tijd kwijt met de print-routine, terwijl ik die helemaal niet nodig had.

Naast m'n shiny Point3D class was ik daar ook veel te veel tijd aan kwijt. Al met al wel blij met het resultaat.

[coop]

Misschien ooit eens naar kijken of een generieke oplossing voor elke hoeveelheid dimensies te maken (mijzelf kennende waarschijnlijk niet).
Voor nu heb ik de functies voor deel 1 een extra loop gegeven voor de 4de dimensie. 0.5s in deel 1 naar 20s in deel 2.

[ Voor 12% gewijzigd door coop op 06-12-2021 13:48 ]

[armageddon_2k1]

Hydra schreef op donderdag 17 december 2020 @ 10:41:
[...]


Naast m'n shiny Point3D class was ik daar ook veel te veel tijd aan kwijt. Al met al wel blij met het resultaat.

Heb hem nu generiek gemaakt naar N-dimensies. Dat was een eitje uiteindelijk.

https://github.com/rj-cod...rjcoding/aoc2020/Day17.kt

[ydderf]

Dag 17 ook gelukt ondanks dat ik ergens nog steeds niet helemaal snap hoe de opdracht werkt, maar op één of andere manier snapt mijn programma het wel. Edit: Het kwartje is gevallen. Soms moet je ff een rij verder kijken dan je input lang is
Ik denk dat ik ook meteen de meest simpele straight forward oplossing heb gemaakt met een hoop for-loops.
Deel twee had ik wel iets spannender verwacht met een resultaat na een paar miljoen cycles oid.

Straks nog ff kijken naar deel 2 van dag 16....
Maar ondertussen al verder gekomen dan ik ooit gekomen ben, en ook weinig gebruik van de spoilers hoeven te maken.

[ Voor 7% gewijzigd door ydderf op 17-12-2020 11:16 ]

[ZieglerNichols]

coop schreef op donderdag 17 december 2020 @ 10:41:
Misschien ooit eens naar kijken of een generieke oplossing voor elke hoeveelheid dimensies te maken (mijzelf kennende waarschijnlijk niet).
Voor nu heb ik de functies voor deel 1 een extra loop gegeven voor de 4de dimensie. 0.5s in deel 1 naar 20s in deel 2.
https://github.com/tluijf...020/blob/main/Day%2017.py

Mijn Matlab oplossing voor deel 2 runt in 0.06 seconde. Ik doe alles met matrix operaties, dus geen loops.

[Hydra]

armageddon_2k1 schreef op donderdag 17 december 2020 @ 10:48:
[...]


Heb hem nu generiek gemaakt naar N-dimensies. Dat was een eitje uiteindelijk.

https://github.com/rj-cod...rjcoding/aoc2020/Day17.kt

Oh lol; ik heb net precies hetzelfde gedaan!

Ik ben hard aan het crushen op fold-left Heb er voorgaande jaren weinig gebruik van gemaakt, maar dat is een stukje waar ik wel echt beter in geworden ben.

[armageddon_2k1]

Hydra schreef op donderdag 17 december 2020 @ 11:10:
[...]


Oh lol; ik heb net precies hetzelfde gedaan!

Ik ben hard aan het crushen op fold-left Heb er voorgaande jaren weinig gebruik van gemaakt, maar dat is een stukje waar ik wel echt beter in geworden ben.

Ik heb hem nu nog een keer opgeschoond en voor een keer 'partition' gebruikt.
Nu ben ik helemaal happy

[evanraalte]

@Reynouts Thanks, dat was net wat ik nodig had. Heb het voor mezelf nog wat makkelijker gemaakt door dit te defineren

spoiler:

add_t = lambda x,y : tuple(map(sum,zip(x,y)))

.

[Hydra]

Varienaja schreef op donderdag 17 december 2020 @ 07:38:
Code presenteer ik nog niet.

Aww?

[Verwijderd]

ZieglerNichols schreef op donderdag 17 december 2020 @ 10:59:
[...]


Mijn Matlab oplossing voor deel 2 runt in 0.06 seconde. Ik doe alles met matrix operaties, dus geen loops.

Hmm, kom er niet zonder 1 loopje, : --> 90 ms.

[FrankMennink]

Dag 17 in Python. Zat ook in het begin te klooien met het begrijpen van de voorbeeld output na de eerste cycle, dat had wel wat handiger gekund Verder blij met execution times, 0.1s voor deel 1, 4.4s voor deel 2

[ThoNohT]

Ik vind die kotlin code hier wel steeds moeilijker te begrijpen..

spoiler:

(1 until dim).fold((-1 .. 1).map { listOf(it) } ) { points, _ ->
points.flatMap { p -> (-1 .. 1).map { p + it } }
}.filterNot { it.all { it == 0 } }

... Dit zegt mij echt weinig

Anyway, dag 17 in F#. Lekker veel met sets gedaan.

[Hydra]

ThoNohT schreef op donderdag 17 december 2020 @ 12:04:
Ik vind die kotlin code hier wel steeds moeilijker te begrijpen..

spoiler:

(1 until dim).fold((-1 .. 1).map { listOf(it) } ) { points, _ ->
points.flatMap { p -> (-1 .. 1).map { p + it } }
}.filterNot { it.all { it == 0 } }

... Dit zegt mij echt weinig

Ik maak daar alle 'neighbor' punten aan. Het is een generieke functie die werkt voor punten met 2,3 of meer dimensies. Wat 'ie eigenlijk doet is beginnen bij 1 dimensie, en in een 'loop' elke extra dimensie voor alle punten erbij plakken. En tenslotte filtert 'ie punt (0,0, etc) uit die lijst.

Ik werk ook in 'productie' met Kotlin, maar als ik daar zo iets complex zou moeten doen zou er zeker een stuk uitleg bovenstaan. Het is niet erg leesbare code.

Ik leg met alle plezier de individuele stapjes in die code uit als je nog iets niet begrijpt

[ Voor 15% gewijzigd door Hydra op 17-12-2020 12:10 ]

[ThoNohT]

Hydra schreef op donderdag 17 december 2020 @ 12:08:
[...]


Ik maak daar alle 'neighbor' punten aan. Het is een generieke functie die werkt voor punten met 2,3 of meer dimensies. Wat 'ie eigenlijk doet is beginnen bij 1 dimensie, en in een 'loop' elke extra dimensie voor alle punten erbij plakken. En tenslotte filtert 'ie punt (0,0, etc) uit die lijst.

Ik werk ook in 'productie' met Kotlin, maar als ik daar zo iets complex zou moeten doen zou er zeker een stuk uitleg bovenstaan. Het is niet erg leesbare code.

Ik leg met alle plezier de individuele stapjes in die code uit als je nog iets niet begrijpt

Ik geloof je graag, aan de naam zie ik ook dat je neighbors gaat aanmaken. Maar waar het recursief is zie ik niet. Oh wacht, dat zit natuurlijk in de fold verstopt. Nouja, ik zou er vast uitkomen op den duur, als ik heb uitgezocht wat alle constructies doen.

Ik zelf neig toch altijd naar een wat leesbaardere stijl ook bij deze opdrachten. Vind het ook fijner als ik later iets moet refactoren voor deel 2 of zo als ik nog snel begrijp wat ik heb gedaan Ach, het feit dat ik de taal nog nooit eerder heb gezien helpt natuurlijk niet.

Mijn neighbors functie heb ik niet in een fold geschreven, maar gewoon echt recursief in termen van zichzelf, en deze keer ook netjes staartrecursief gemaakt, de fold versie kwam hier niet zo direct bij mij naar boven, alhoewel ik nu wel zie hoe ik hem zou maken, dat lijkt alsnog niks op die Kotlin code .

[Hydra]

ThoNohT schreef op donderdag 17 december 2020 @ 12:15:
Ik geloof je graag, aan de naam zie ik ook dat je neighbors gaat aanmaken. Maar waar het recursief is zie ik niet. Oh wacht, dat zit natuurlijk in de fold verstopt. Nouja, ik zou er vast uitkomen op den duur, als ik heb uitgezocht wat alle constructies doen.

Het is niet recursief hoor. Ik 'loop' in de fold voor elke extra dimensie over alle punten heen, en vervang elk punt voor punt + -1, punt + 0 en punt + 1.

Ik zelf neig toch altijd naar een wat leesbaardere stijl ook bij deze opdrachten. Vind het ook fijner als ik later iets moet refactoren voor deel 2 of zo als ik nog snel begrijp wat ik heb gedaan Ach, het feit dat ik de taal nog nooit eerder heb gezien helpt natuurlijk niet.

De code is voor mij leesbaar, maar dat komt denk ik ook omdat ik zelf die oplossing bedacht heb. Maar heb vooral wel even na moeten denken over hoe ik die 'neighbors' functie voor meer dimensies kon generaliseren. Toen ik dat eenmaal bedacht had, volgde die code vanzelf.

Maar als je niet de methode kent (zoals ik al zei; het is niet recusries) en/of niet erg ervaren bent dan geloof ik wel dat die code slecht leesbaar is. Ik heb ook wel eens 'productie' code 'makkelijker' (/langer) gemaakt omdat collega's het niet konden volgen.

[armageddon_2k1]

In productie maak ik code altijd langer, want ik ben zelf de collega ook die het na een jaar ook nog moet begrijpen.

[Soultaker]

Mee eens dat het voorbeeld van dag 17 kut is. Ik zat me er ook over te verwonderen terwijl m'n code al correct was.

Bij deel 1 had ik gekozen om de actieve cubes in een set te stoppen (code) i.p.v. een 3D array van booleans, omdat ik verwacht had dat je voor deel 2 duizend of zo iteraties vooruit zou moeten denken, en de set-representatie schaalt beter als je er van uit gaat dat het grootste deel van de ruimte leeg blijft.

Maar het probleem bleek een andere richting op te gaan, dus achteraf gezien is mijn code misschien niet optimaal. Ik vermoed dat de multidimensionale array van booleans efficiënter is want

spoiler:

als je grid H x W als afmetingen heeft, en je wil N iteraties vooruit rekenen, dan heb je hooguit een array van grootte (H + 2×N, W + 2×N) nodig. Dus voor dit concrete probleem heb je 8 + 2×6 = 20 per dimensie, ofwel een array van 20⁴ = 160,000 elementen nodig.

[ThoNohT]

Hydra schreef op donderdag 17 december 2020 @ 12:23:
[...]

Het is niet recursief hoor. Ik 'loop' in de fold voor elke extra dimensie over alle punten heen, en vervang elk punt voor punt + -1, punt + 0 en punt + 1.

Fold is vaak zelf recursief gedefinieerd, maar met staartrecursie heel eenvoudig gewoon weer als een loopje te definiëren. Maar ik dacht dat je zelf ergens recursief had genoemd, en daarom was ik naar iets recursiefs aan het zoeken, en fold was het enige wat ik kon vinden.

Soultaker schreef op donderdag 17 december 2020 @ 13:01:

spoiler:

als je grid H x W als afmetingen heeft, en je wil N iteraties vooruit rekenen, dan heb je hooguit een array van grootte (H + 2×N, W + 2×N) nodig. Dus voor dit concrete probleem heb je 8 + 2×6 = 20 per dimensie, ofwel een array van 20⁴ = 160,000 elementen nodig.

spoiler:

Ik zou niet voor een multidimensionale array gaan hier. Elke stap kan hij in een of meerdere dimensies groter worden, en je hebt dan ook zo'n sparse array. Ik heb gewoon een set met coordinaten, en ik kijk bij neighbors gewoon per stuk of die coordinaten in de set voorkomen. Nieuwe elementen kunnen ook alleen ontstaan als neighbors van bestaande coordinaten, dus check deze allemaal om te kijken of er ergens nieuwe bijkomen.

Maar ik moet bekennen, mijn implementatie is niet de snelste. Met 11 seconden op zich nog wel te doen.

[ Voor 46% gewijzigd door ThoNohT op 17-12-2020 13:28 ]

[Emiel L]

Soultaker schreef op donderdag 17 december 2020 @ 13:01:
Mee eens dat het voorbeeld van dag 17 kut is. Ik zat me er ook over te verwonderen terwijl m'n code al correct was.

Bij deel 1 had ik gekozen om de actieve cubes in een set te stoppen (code) i.p.v. een 3D array van booleans, omdat ik verwacht had dat je voor deel 2 duizend of zo iteraties vooruit zou moeten denken, en de set-representatie schaalt beter als je er van uit gaat dat het grootste deel van de ruimte leeg blijft.

De set representatie schaalt fantastisch, maar als ik mijn oplossing (sets) vergelijk met die van een collega (gegoochel met arrays), is zijn oplossing zonder enige moeite toch sneller. Het opzoeken van items in een set is niet schrikbarend langzaam, maar vergeleken met een simpele array lookup ontzettend traag.

[Hydra]

ThoNohT schreef op donderdag 17 december 2020 @ 13:21:
Fold is vaak zelf recursief gedefinieerd

Hoezo? Er is niks recursiefs aan hoor . Het is gewoon iteratief iets met een accumulator doen. Een voorbeeldje van alles optellen via fold: values.fold(0) { a, b -> a + b }

Dat is iteraties gewoon:

code:

a = 0
for (v in values) {
  a = a + v
}
return a

Een fold is dus niks anders dan een start waarde (accumulator, a) en dan een functie die als input de accumulator en een waarde in de lijst heeft, en als uitput weer een accumulator.

[Hydra]

Emiel L schreef op donderdag 17 december 2020 @ 13:58:
De set representatie schaalt fantastisch, maar als ik mijn oplossing (sets) vergelijk met die van een collega (gegoochel met arrays), is zijn oplossing zonder enige moeite toch sneller. Het opzoeken van items in een set is niet schrikbarend langzaam, maar vergeleken met een simpele array lookup ontzettend traag.

Wat is 'ontzettend traag' dan? Part 2 van vandaag doet er bij mij 168ms over, en die gebruikt sets.

[dcm360]

Met sets heb je vooral het voordeel dat de performance niet beroerd is, terwijl je niet meer hoeft na te denken over hoe groot de array moet worden. Mijn oplossing is dan weet niet echt snel (3 seconden voor deel 2 op mijn werkpc, dus op een moderne pc zou dat 1.5 seconde kunnen zijn).

Wat er overigens aan te optimaliseren valt is dat de 'wereld' spiegelsymmetrisch is over de z-as (en in deel 2 waarschijnlijk ook de w-as, maar dat heb ik niet in detail bekeken.

Hydra schreef op donderdag 17 december 2020 @ 14:07:
[...]


Hoezo? Er is niks recursiefs aan hoor . Het is gewoon iteratief iets met een accumulator doen. Een voorbeeldje van alles optellen via fold: values.fold(0) { a, b -> a + b }

Dat is iteraties gewoon:

code:

a = 0
for (v in values) {
  a = a + v
}
return a

Een fold is dus niks anders dan een start waarde (accumulator, a) en dan een functie die als input de accumulator en een waarde in de lijst heeft, en als uitput weer een accumulator.

In principe is een fold gewoon tail recursive. Recursieve en iteratieve oplossingen zijn echter altijd naar elkaar om te schrijven, maar de definitie van een fold in een functionele programmeertaal zal eerder tail recursive dan iteratief zijn.

[Mawlana]

Het duurde even voordat ik het voorbeeld goed begreep. Toen het kwartje eenmaal viel was het een eitje.

[CMG]

sylvesterrr schreef op donderdag 17 december 2020 @ 14:19:
Het duurde even voordat ik het voorbeeld goed begreep. Toen het kwartje eenmaal viel was het een eitje.

Ik had 't bijna opgegeven omdat ik het voorbeeld niet begreep... ik dacht dat ik wat miste, maar kon het niet verklaren...

[Ethikka]

Uiteindelijk vandaag een factor 100 sneller gemaakt door wat data-optimalizatie (vector4 gebruiken ipv multidimensionele array) en daarmee voor het eerst GLM gebruikt. Zelf een kale vec4 maken moest ik zoveel extra voor doen om ze te gebruiken in unordered_map en unordered_set dat ik er wat simpel van werd.

Gek genoeg is mijn dag 15 zonder codewijzigingen in ene 20% langzamer als voorgaande dagen na het installeren van GLM (of iets anders), go figure.

Code: https://bitbucket.org/eth...src/master/2020/day17.cpp

[CMG]

Ethikka schreef op donderdag 17 december 2020 @ 14:55:
Uiteindelijk vandaag een factor 100 sneller gemaakt door wat data-optimalizatie (vector4 gebruiken ipv multidimensionele array) en daarmee voor het eerst GLM gebruikt. Zelf een kale vec4 maken moest ik zoveel extra voor doen om ze te gebruiken in unordered_map en unordered_set dat ik er wat simpel van werd.
...

Raar, ik heb een char[][][][] gemaakt en pre-poplated for de hele mogelijke search-space (steps * 2 + initial size) en deel 2 runt in 1,5s ongeveer hier?

[ThoNohT]

Hydra schreef op donderdag 17 december 2020 @ 14:07:
[...]
Hoezo? Er is niks recursiefs aan hoor . Het is gewoon iteratief iets met een accumulator doen. Een voorbeeldje van alles optellen via fold: values.fold(0) { a, b -> a + b }

Ik zei ook niet dat hij recursief is, alleen dat hij vaak recursief is gedefinieerd En fold is vaak ook een mooi hulpmiddel om een recursieve functie niet recursief te maken.

Hier voor het gemak de recursieve definitie in F# smaak:

code:

let rec fold f acc list =
    match list with
    | [] -> acc
    | x :: xs -> fold f (f acc x) xs

En die kan ik dus gebruiken als

code:

fold (+) 0 [1 ; 2 ; 3] => 6

Het mooie aan deze definitie is dat hij zelf staartrecursief is, en dus mooi naar een loopje gecompiled wordt.

Dus als ik niet precies weet hoe ik optellen in een loopje moet schrijven, dan krijg ik deze recursieve functie:

code:

let rec addList list =
    match list with
    | [] -> 0
    | x :: xs -> x + addList xs

Deze code is recursief, niet staartrecursief en daardoor dus mogelijk problematisch. Definieer hem daarna in fold (zoals hierboven) en ik heb hem heel gemakkelijk staartrecursief en makkelijker leesbaar gemaakt. Natuurlijk is + een veels te makkelijk voorbeeld, maar voor ingewikkeldere folds kan het wel degelijk zo werken.

Dit alles om uit te leggen waarom ik naar recursie aan het zoeken was Eigenlijk doet het er helemaal niet toe, en we hebben allebei natuurlijk gelijk. De implementatie van fold zal ook niet altijd zo zijn als ik hier schrijf, maar dit is wel een veelvoorkomende definitie.

spoiler:

Detail: De echte implementatie van fold in F# is met een loop Maargoed, hier werken ze met mutable state, waarschijnlijk omdat dat gewoon sneller is, en dit is dus niet echt in de sfeer van functioneel programmeren.

Bonus: Even gezocht bij andere talen. In Elm is hij wel recursief geimplementeerd.

[ Voor 12% gewijzigd door ThoNohT op 17-12-2020 16:40 ]

[Hydra]

ThoNohT schreef op donderdag 17 december 2020 @ 15:58:
Ik zei ook niet dat hij recursief is, alleen dat hij vaak recursief is gedefinieerd

Nou volgens mij gaan we een beetje in cirkels:

ThoNohT schreef op donderdag 17 december 2020 @ 12:15:
Ik geloof je graag, aan de naam zie ik ook dat je neighbors gaat aanmaken. Maar waar het recursief is zie ik niet. Oh wacht, dat zit natuurlijk in de fold verstopt.

Dus als het neerkomt op de definitie van "is" versus "is gedefinieerd als" tja; prima. Ik gebruik die termen anders. Je hoeft me in ieder geval recursie niet uit te gaan leggen.

[ Voor 4% gewijzigd door Hydra op 17-12-2020 17:13 ]

[ThoNohT]

Hydra schreef op donderdag 17 december 2020 @ 17:12:
Dus als het neerkomt op de definitie van "is" versus "is gedefinieerd als" tja; prima. Ik gebruik die termen anders. Je hoeft me in ieder geval recursie niet uit te gaan leggen.

Haha, het begon allemaal omdat ik het woord recursief in jouw post dacht te lezen, bleek daar niet te staan. Ik wees daarna de enige plek aan waar ik het me kon voorstellen. Maar achteraf dus niet belangrijk, want het stond er niet, dus had er ook niet naar hoeven zoeken.

De hele discussie daarna sloeg in mijn ogen alleen nog op of fold recursief is of niet. Sorry als ik wat teveel van stapel liep. het is nou eenmaal interessante materie

[Hydra]

ThoNohT schreef op donderdag 17 december 2020 @ 17:26:
het is nou eenmaal interessante materie

Dat zeker! In Kotlin is het een inline functie (want sneller), maar je kunt 'em in Kotlin ook relatief simpel tail recursive implementeren:

Java:

tailrec fun <A, T> Collection<T>.foldTailRec(acc: A, f: (A, T) -> A): A {
    if (isEmpty()) return acc
    return drop(1).foldTailRec(f(acc, first()), f)
}

Dit is een generieke tailrec kopie van de 'gewone' .fold (lang leve extension functions). Ik denk dat het afhankelijk ook is van de onderliggende runtime. Kotlin compileert gewoon naar bytecode en de JVM heeft geen notie van tail recursion. Dus dit is gewoon syntactic sugar van de Kotlin compiler.

[Varienaja]

Dricus schreef op donderdag 17 december 2020 @ 09:03:
Zo, even mijn spuuglelijke code delen (zodat @Varienaja weet dat hij zich nergens voor hoeft te schamen ).

Reynouts schreef op donderdag 17 december 2020 @ 10:12:
Jammer, het is juist leuk en interessant om te zien waar je mee komt in eerste instantie!

Hydra schreef op donderdag 17 december 2020 @ 11:45:
Aww?

Ok dan, kijk en huiver >klik<:

[Hydra]

Varienaja schreef op donderdag 17 december 2020 @ 18:21:
Ok dan, kijk en huiver >klik<:

Ik vind dat je sowieso dit topic gewonnen hebt.

[ThoNohT]

Na deze hele discussie kon het toch niet meer maken om mijn Neighbors functie niet naar een fold om te schrijven

[Woy]

Vandaag had ik niet echt tijd, dus net nog even snel gedaan. Part2 wel op de quick en dirty manier gedaan, misschien van het weekend nog even kijken om het wat netter op te lossen:

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

[Woy]

Toch nog een klein beetje gerefactored zodat ieder geval de meeste duplicaat code weg is, het kan nog wel wat mooier door het helemaal generiek te maken, maar dat lukt niet zo makkelijk met deze manier met tuples.

[MrHaas]

Dag 17 in Rust met behulp van const generics: https://github.com/arjand...ob/main/day17/src/main.rs .
Komt er eigenlijk op neer dat het type afhankelijk is van het aantal dimensies. Niet de meest performant oplossing, maar wel leuk concept imo.

[ydderf]

Zojuist Dag 16 ook afgerond. Stond nog open na tijdgebrek gisteren. Nog niet helemaal happy over de opzet, maar hij doet zijn dingetje. Ik heb soms toch te weinig kennis om goed te bepalen of ik nu een List of Array of Dict of struct (of combi van) moet nemen.

[jelknab]

Vandaag was een van de dagen dat ik part 2 echt super snel heb opgelost. Part 2 was niet meer dan overal even de dimensie bij pasten.
https://github.com/jelkna...ode%202020/Day17/Day17.cs

[Varienaja]

Day 17 gerefactored. Wat in vergelijking met iets als dit nog altijd een monster is.

[armageddon_2k1]

MrHaas schreef op donderdag 17 december 2020 @ 20:10:
Dag 17 in Rust met behulp van const generics: https://github.com/arjand...ob/main/day17/src/main.rs .
Komt er eigenlijk op neer dat het type afhankelijk is van het aantal dimensies. Niet de meest performant oplossing, maar wel leuk concept imo.

Je zou zeggen dat const voor een verbeterde binary zou zorgen toch die sneller is? Of wat is anders voordeel van const?

[joppybt]

Pfft, JavaScript is geen fijne taal om dit te doen. Veel te veel tijd gestoken in het dynamisch uitbreiden van de array's
Zelf houd ik me niet bezig met de performance maar heeft iemand het nog zo geoptimaliseerd:

spoiler:

Omdat je 2D begint zal de volgende dimensie symmetrisch zijn: bij deel 1 zal het vlak van z=-1 altijd gelijk zijn aan het vlak met z=+1. Zodoende hoef je maar de helft (+1) uit te rekenen.
In deel twee kan het waarschijnlijk nog meer schelen.

[DRaakje]

Mijn code in C#

https://pastebin.com/KQ99PbH5

Wel grappig vandaag, alles werkte ook in 1 keer. Nog beetje weten te optimaliseren en uiteindelijk van 2.5sec naar 450ms gegaan. Nog een laatste optimalisatie bracht dat naar 385ms.

spoiler:

Beste optimalisatie kwam van alleen de cubes opslaan die active waren en zijn buren. Verder het volledig uitschrijven van de neighbours generatie scheel ook weer 65ms.

[Varienaja]

DRaakje schreef op donderdag 17 december 2020 @ 22:00:
Beste optimalisatie kwam van alleen de cubes opslaan die active waren en zijn buren. Verder het volledig uitschrijven van de neighbours generatie scheel ook weer 65ms.

Oh.. mijn.. God..

Ik dacht dat er compilers waren die loop-unrolling toepasten, zodat je niet zelf dit soort gekkigheid moet gaan doen.

[ElkeBxl]

joppybt schreef op donderdag 17 december 2020 @ 22:00:
Pfft, JavaScript is geen fijne taal om dit te doen. Veel te veel tijd gestoken in het dynamisch uitbreiden van de array's

Ik heb er zelf in TypeScript ff op zitten vloeken voor het dynamisch uit te breiden, tot ik yield ging gebruiken. Maakte het veel eenvoudiger om alle neighbours te genereren.

[ThomasG]

Varienaja schreef op donderdag 17 december 2020 @ 22:17:
[...]

Oh.. mijn.. God..

Ik dacht dat er compilers waren die loop-unrolling toepasten, zodat je niet zelf dit soort gekkigheid moet gaan doen.

Dat doet de C# compiler ook. Echter, in zijn oude code gebruikte hij yield return, en dat wordt altijd omgezet naar een state-machine. Als hij in plaats van yield return te gebruiken zelf de enumerator zou vullen via een loop, zou de compiler dit gewoon optimaliseren.

[Alain]

Wat op zich wel grappig is. Ik hield een lijst bij met welke cubes ik al gecontroleerd had tijdens een cycle. Als ik deze lijst schrap en gewoon alle cubes elke keer weer check ga ik van bijna 7 seconden naar 1 seconde voor het tweede deel.

[Varienaja]

Grmbl.. alle voorbeelden goed. Uitkomst onderdeel A fout. Maar alle steekproeven die ik neem zijn goed. BAH!

^{...welke flapdrol typt daar dan ook int in plaats van long...}

[ Voor 26% gewijzigd door Varienaja op 18-12-2020 07:09 ]

[Dido]

Varienaja schreef op vrijdag 18 december 2020 @ 06:59:
Grmbl.. alle voorbeelden goed. Uitkomst onderdeel A fout. Maar alle steekproeven die ik neem zijn goed. BAH!

^{...welke flapdrol typt daar dan ook int in plaats van long...}

Ondertussen gebruik ik in AOC eigenlijk dat hele int type niet meer

Int32 overflow is toch met stip de meest voorkomende AOC bug, vermoed ik

[Mschamp]

Bij mij ook alle voorbeelden goed, eindresultaat niet, resultaat is te hoog (en heb er aan gedacht overal long te gebruiken, dat is het dus niet )

[ElkeBxl]

Vandaag was leuk! Dat is geleden van op unief dat ik nog eens met zo'n algoritmes bezig was.

spoiler:

Oh Dijkstra, we meet again old friend

Mijn oplossing in TypeScript

[Varienaja]

Dido schreef op vrijdag 18 december 2020 @ 07:49:
Ondertussen gebruik ik in AOC eigenlijk dat hele int type niet meer

Ja.. ik dus ook niet. Maar ik heb het toch per ongeluk zelf ingetypt denk ik...

Anyway.. ik moet weer eens nakijken hoe je een parser schrijft. Daar heb ik nog heel wat op te schonen vanavond. Nu moet ik eerst "echt" werk gaan doen.

[ Voor 3% gewijzigd door Varienaja op 18-12-2020 08:30 ]

[ZieglerNichols]

Dag 18 in Matlab: https://pastebin.com/kR6wFpgb
Niet erg efficient, maar het werkt.

[heuveltje]

day_18 was goed te doen. 1e sterretje van de dag is binnen
deel 2 moet ik nog refactoren, maar dat moet in een kwartier te doen zijn. jammer dat ik die nu even niet heb.

Had ik wel kunnen hebben als ik geen 20 min had gespendeerd aan mijn parser overbodig complex te maken..

spoiler:

hint: er zijn geen waardes hoger dan 9 in de input file

[ Voor 8% gewijzigd door heuveltje op 18-12-2020 09:10 ]

[_Mithrandir]

Behoorlijk stuk gelopen op part 2 dag 14. Maar ik heb hem gisteren toch opgelost, bleek uit eindelijk toch niet zo heel moeilijk. Wel een tijd bezig geweest met debuggen van me code.

Na vandaag vakantie dus is kijken of ik nog een inhaal sprintje kan doen

[eamelink]

Tssssssk, zeventien dagen alles met regular expressions gedaan, komen ze ineens met een non-regular language op de proppen

Ik dacht dat het een makkie zou zijn met parser combinators. Dat is ook zo, alleen ik ben echt wat roestiger dan gehoopt

Anyway, even ploeteren en hij deed het. Deel twee wel vreselijk opgelost, maar alleen het resultaat telt toch?

spoiler:

Ik maakte bij deel 1 geen tree met binary operations, maar een lijst met een eerste operand, en dan tuples van operatie en volgende operand; dat matcht immers precies met links-naar-rechts evaluatie.

Bij deel twee kom je dan in de knoop, maar je kan ook door de lijst recursen en twee operators vooruit kijken en als je een * met daarna een + ziet, eerst de + uitvoeren.

[Emiel L]

Oplossing in Swift: https://github.com/emielatsgt/aoc2020/tree/main/18

Op zich redelijk makkelijke opdracht maar wel bewerkelijk. Voor deel 2 was ik al bang dat dit zou gebeuren, dus ik mocht m'n

spoiler:

stack based

oplossing van deel 1 mooi refactoren.

Uiteindelijk ook niet heel ingewikkeld... ik

spoiler:

parse nu naar een lijst van onderdelen van de expressie

, daarna

spoiler:

isoleer ik de sub-expressies

om vervolgens

spoiler:

daar doorheen te lopen en eerst de sub-expressies op te lossen

. Je houdt dan een

spoiler:

simpele expressie met alleen nog + en * over

waarna de oplossing zich snel laat vinden.

[armageddon_2k1]

Okee, ik heb hulp nodig.
Heb een stackbased oplossing gedaan en alle voorbeelden passen voor Part 1 en Part 2.
Part 1 heb ik goed, maar voor Part 2 is mijn antwoord te laag? Voor alles gebruik ik Long.

Zie ik iets over het hoofd?
https://github.com/rj-cod...rjcoding/aoc2020/Day18.kt

[ Voor 4% gewijzigd door armageddon_2k1 op 18-12-2020 11:18 ]

[Hydra]

Lol!

spoiler:

Vanaf de wikipedia page shunting yard geimplementeerd voor deel 1, dat werkte niet lekker, dus maar overboord gegooid en gewoon recursief geparsed. Deel 2: operator precedence doet er toch toe. Oops!

Ach ja, ben ook nog maar een halve ochtend bezig...

[armageddon_2k1]

@Hydra

Ook al 2 uur bezig...

[ppx17]

18 in php.

spoiler:

Kon geen zin krijgen om een hele parser te schrijven met precedence en alles, dus ben gewoon gegaan voor een regex replace, waarbij de expression steeds verder vereenvoudigd word totdat er nog maar 1 getal over is.

[bakkerjangert]

Vandaag vond ik wel leuk om te doen. Ik ben een beetje aan het hobbyen in Python maar niet echt een programeur. Tot noch toe lukt het me nog steeds om de tot de juiste antwoorden te komen, zij het wellicht niet op de meest optimale manier. Dat vind ik ook het mooie aan AoC; in principe kan iedereen die wat affiniteit heeft met progremeren al wel een heel eind komen met wat if-statements en for / while loopjes. Sommige codes die hier worden gedeeld snap ik dan ook (nog) geen hout van.

Mijn code in Python vor dag 18.

[Woy]

Vandaag had ik al het idee dat ik mijn oplossing voor deel 1 niet in deel 2 kon gebruiken, maar bij advent of code probeer ik niet al te veel aannames te doen bij implementatie.

Het was dat ik niet meer uit mijn hoofd wist hoe

spoiler:

Shunting Yard

werkte dat ik het toch gewoon simpel opgelost heb. Deel 2 heb ik toch even snel gegoogled hoe dat ook alweer exact werkte en toch zo geimplementeerd. Toen deel 1 ook maar omgeschreven

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

Bij deel 2 maakte ik eerst nog de fout door alsnog de * de hogere precedence te geven

[ Voor 8% gewijzigd door Woy op 21-12-2020 16:14 ]

[Hydra]

Dag 18 in Kotlin

spoiler:

Gelukkig had ik m'n Shunting Yard implementatie gecommit voordat ik 'em weggooide! De reden dat 'ie niet werkte was omdat ik gewoon een kleine fout in de implementatie had zitten. Gelukkig was het een relatief kleine aanpassing.

Het is vrij smerige code, misschien dat ik 'em later nog eens aan ga passen. Voor nu prima Wel erg blij dat ik in ieder geval zelf de goeie oplossingsrichting gekozen heb, hoewel ik er wel een paar keer naast zat.

Oh en ja; mijn shunting yard doet niks met haakjes

[armageddon_2k1]

Dag 18 in Kotlin

spoiler:

Heb veel domme omwegen genomen en had gewoon het slimme moeten doen.

Eerst dacht ik een routine te maken die haakjes zet om de oorspronkelijke formule om de precedence op te lossen, maar dat was moeilijker dan ik dacht.

Daarna wilde ik alles in de evaluation functie oplossen, maar dat lukte alleen met de testinput en niet met de echte.

Daarna eigenlijk gewoon het logische gedaan en de subexpressies eruit gedestileerd, en recursief opgelost en de evaluation function vervangen om alleen rekening te houden met + en - en de hele haakjes routine eruit gesloopt.

Wel gehoord van Dijksta (pathfinding), maar niet van

spoiler:

Shunting Yard

. Weer wat leesvoer dus. Volgens mij heb ik een basic versie zelf daarvan bedacht dan

[ Voor 10% gewijzigd door armageddon_2k1 op 18-12-2020 12:05 ]