Advent of Code 2022

[YoToP]

Mijn Python code

spoiler:

kan totaal niet omgaan met andere hoogtes of ander aantal stacks. Vanavond maar even afkijkenleren hoe dat gemakkelijk dynamisch kan.

[ Voor 3% gewijzigd door YoToP op 05-12-2022 08:50 ]

[TrailBlazer]

Denk mijn snelste tijd tussen part1 en part2.

spoiler:

Plaatsen van een hekje was genoeg. Apart dat voor het oplossen van deel 2 minder code nodig was

[TrailBlazer]

YoToP schreef op maandag 5 december 2022 @ 08:49:
Mijn Python code

spoiler:

kan totaal niet omgaan met andere hoogtes of ander aantal stacks. Vanavond maar even afkijkenleren hoe dat gemakkelijk dynamisch kan.

spoiler:

Als je naar je code kijkt zie je duidelijk een verband tussen de index van de stack en waar de container staat in de input. Als je dit in een formule plaatst ben je al een heel eind.

Daarnaast heb je de functie startswith hiermee kan je kijken of een string begint met een bepaald karakter/string. Gebruik dit om te bepalen of een regel info over een move bevat of iets anders bijvoorbeeld.

[ Voor 15% gewijzigd door TrailBlazer op 05-12-2022 09:16 ]

[Remcoder]

spoiler:

Vandaag stond alles in het teken van Stacks.

Ik was vrijwel alle tijd kwijt met het parsen van de stacks, het moven daarna was gewoon gebruik maken van de features van Stack.

Uiteindelijk wel een vrij schone, dynamische oplossing gevonden waarmee ik maar 1x over de input heen loop.

Daarnaast ruzie gehad met IntelliJ die het nodig vond om de trailing whitespace automatisch te trimmen.

[breew]

dag 5 in R
Leuke puzzel... Baal er wel van dat ik de startpositie van de kratten over moest tikken omdat ik zo snel geen geautomatiseerde manier kon bedenken om die characters in te lezen.

spoiler:

Toen in eenmaal bedacht had dat ik gewoon character-vectors kon verplaatsen tussen list-elements, was het eigenlijk simpel. Part 1 en 2 waren daardoor ook identiek, alleen plaatste ik bij part 1 de 'reverse' van het te verplaatsen deel, en bij part 2 gewoon het te verplaatsen deel in zijn geheel.

[FrankMennink]

Dag 5 in Python

Met dank aan @jmerle voor het makkelijk inlezen van de nummers in de instructies, ik zag die methode gisteren en heb m gelijk meegenomen voor deze

[breew]

bakkerjangert schreef op maandag 5 december 2022 @ 08:29:
Leuke opdracht vandaag. Omdat ik enkele zaken handmatig invul had ik vandaag het meeste moeite met de switch tussen de test input en de echte input. Part 2 was een eitje gezien mijn opzet voor part 1.

Code in python

hah.. wij hebben (volgens mij, ik kan/ken geen python) exact dezelfde oplossing gekozen.. geinig

[ Voor 3% gewijzigd door breew op 05-12-2022 10:01 ]

[Osxy]

Dag 5 deel 1 was stuk lastiger dan de vorige dagen, deel 2 daarentegen was 2min doordat mijn gebouwde oplossing voor part 1 met 1 minimale aanpassing direct voor deel 2 werkte.

https://github.com/osxy/A.../AoC2022/AoC/Days/Day5.cs
Code kan nog wel wat netter maar moest aan werkdag beginnen.

[tarlitz]

Osxy schreef op maandag 5 december 2022 @ 10:11:
Dag 5 deel 1 was stuk lastiger dan de vorige dagen, deel 2 daarentegen was 2min doordat mijn gebouwde oplossing voor part 1 met 1 minimale aanpassing direct voor deel 2 werkte.

Ja, klopt, vooral omdat het wat langer duurde om de input te parsen 😅.

spoiler:

Als het geformateerd was als iets van `1: RGJBTVZ` per regel was het een stuk simpler geweest. Daarna vond ik de rest van de puzzel vond ik ook goed te doen. Ik had alleen over het hoofd gezien dat nummers groter dan 9 konden zijn wat wel zo was in de test data en daarom had ik in mijn eerste run lege stacks

[CMG]

Vandaag was wel leuk; zoals al aangegeven (en eigenlijk meestal bij deze eerste dagen) zit de meeste moeite in het parsen van de input. Gewoon hardcoden kwam niet eens in me op 😅als je voor snelheid gaat (leaderboard) is dat wel veel sneller dan proberen een parser te schrijven waarschijnlijk.

Heb zoals voorgaande dagen het oplossen weer gelivestreamed.

Code & link naar stream zoals altijd in de Mega Solutions Thread

spoiler:

Voor deel 1 heb ik een stack gebruikt; voor deel 2, als aantal > 1, een extra stack gebruikt 😊

[ElkeBxl]

Dag 5 in Rust
Kan waarschijnlijk stuk korter maar zat teveel in de knoop met de borrow checker van Rust. Mss mezelf daar toch eens wat beter in inlezen

[Gropah]

Ik was hier meer tijd kwijt aan het inlezen dan de opdracht zelf.

spoiler:

Vond het dan ook wel slim bedacht dat mensen de input gewoon hardcode in hun code

TrailBlazer schreef op maandag 5 december 2022 @ 08:53:
[...]

spoiler:

Plaatsen van een hekje was genoeg. Apart dat voor het oplossen van deel 2 minder code nodig was

spoiler:

Hangt af van je oplossing. Die van mij in kotlin maakt gebruik van deques voor de enkele verplaatsing. Voor de meerdere verplaatsing kon ik gebruik maken van take. Deques in kotlin kent wel een addAll, maar die zet het achteraan ipv vooraan zoals ik nodig had. Dus moest ik nog wat omgooien

[Remcoder]

Gropah schreef op maandag 5 december 2022 @ 11:05:
Ik was hier meer tijd kwijt aan het inlezen dan de opdracht zelf.

spoiler:

Vond het dan ook wel slim bedacht dat mensen de input gewoon hardcode in hun code

Als je voor het leaderbord gaat wel, maar ik vind het dan weer een uitdaging om code te schrijven die met elke willekeurige input overweg kan.

Meestal begin ik daarom ook met een testcase gebaseerd op het voorbeeld, als ik zowel de testcase als de input kan verwerken heb ik meestal een dynamische oplossing te pakken die alle input kan verwerken.

[TrailBlazer]

Gropah schreef op maandag 5 december 2022 @ 11:05:
Ik was hier meer tijd kwijt aan het inlezen dan de opdracht zelf.

spoiler:

Vond het dan ook wel slim bedacht dat mensen de input gewoon hardcode in hun code

[...]

spoiler:

Hangt af van je oplossing. Die van mij in kotlin maakt gebruik van deques voor de enkele verplaatsing. Voor de meerdere verplaatsing kon ik gebruik maken van take. Deques in kotlin kent wel een addAll, maar die zet het achteraan ipv vooraan zoals ik nodig had. Dus moest ik nog wat omgooien

spoiler:

In python was het gewoon een kwestie van een slice ter grootte van het aantal containers nemen en plaatsen op de nieuwe stack. Voor deel 1 moest ik die slice reversen voor deel 2 niet. Vooral blij dat ik niet gekozen heb voor een simpele for loop bij deel1 om elk krat een voor een te verplaatsen.

[Diderikdm]

Leuke dag vandaag! Wel wat tijd verloren aan een shallow copy van list of lists en hierdoor raar gedrag...

Dag 5 - Python

[ Voor 7% gewijzigd door Diderikdm op 08-12-2022 14:21 ]

[Gropah]

Remcoder schreef op maandag 5 december 2022 @ 11:07:
[...]

Als je voor het leaderbord gaat wel, maar ik vind het dan weer een uitdaging om code te schrijven die met elke willekeurige input overweg kan.

Meestal begin ik daarom ook met een testcase gebaseerd op het voorbeeld, als ik zowel de testcase als de input kan verwerken heb ik meestal een dynamische oplossing te pakken die alle input kan verwerken.

Oh, ik zie het ook als een uitdaging die ik op dit moment graag doe omdat ik kotlin wat meer in de vingers wil krijgen. Maar voor de punten had ik het liever even gehardcode, en later de reader gemaakt.

TrailBlazer schreef op maandag 5 december 2022 @ 11:10:
[...]

spoiler:

In python was het gewoon een kwestie van een slice ter grootte van het aantal containers nemen en plaatsen op de nieuwe stack. Voor deel 1 moest ik die slice reversen voor deel 2 niet. Vooral blij dat ik niet gekozen heb voor een simpele for loop bij deel1 om elk krat een voor een te verplaatsen.

spoiler:

Fair enough. Ik was wel voor de for-loop gegaan

Uiteindelijk zijn deques ook lijsten, maar de aanpak is door API verschillen lichtelijk anders.

[Soultaker]

Extra uitdaging voor dag 5: aoc_2022_day05_large_input.zip (uitgepakt 6 MB).

En een grotere: aoc_2022_day05_large_input-2.zip (88 MB uitgepakt).

En een derde: aoc_2022_day05_large_input-3.zip (201 MB uitgepakt). Deze bevat meer dan 9 kolommen; de regel met de kolomnummers ("1 2 3 4 5 6 7 8 9" in de originele invoer) heb ik vervangen door nullen.

Tip: met een goed algoritme moet dit in een paar seconden op te lossen zijn, ook in een scripttaal.
De oplossing: je weet 't als je 't weet.

[ Voor 43% gewijzigd door Soultaker op 05-12-2022 21:09 ]

[Marcj]

Ja, Dag 5 was vrij simpel, het moeilijkste deel was inderdaad het parsen van de input. Maar uiteindelijk volgens mij wel een mooie oplossing in Kotlin gemaakt: https://github.com/marcde...ejonge/advent2022/Day5.kt

Voor de commando's is regex toch het makkelijkst om te parsen vind ik. Voor het laden van de stacks negeer ik nogal veel delen van de input, zoals de braces en whitespace. Ik heb kijk gewoon naar de positie van de character.

Soultaker schreef op maandag 5 december 2022 @ 11:52:
Extra uitdaging voor dag 5: aoc_2022_day05_large_input.zip (uitgepakt 6 MB).

Tip: met een goed algoritme moet dit in een paar seconden op te lossen zijn, ook in een scripttaal.
De oplossing: je weet 't als je 't weet.

Ok, mijn stomme simpele oplossing werkt hier niet voor, maar wel een leuke uitdaging om te laten werken. Je moet dus grote blokken data kunnen verplaatsen, volgens mij is een LinkedList hier beter voor
Ik ga nog even optimaliseren, thanks voor deze input!

[ Voor 41% gewijzigd door Marcj op 05-12-2022 11:57 ]

[bakkerjangert]

Soultaker schreef op maandag 5 december 2022 @ 11:52:
Extra uitdaging voor dag 5: aoc_2022_day05_large_input.zip (uitgepakt 6 MB).

Tip: met een goed algoritme moet dit in een paar seconden op te lossen zijn, ook in een scripttaal.
De oplossing: je weet 't als je 't weet.

Oplossing gevonden, maar net onder de 5 minuten.

[Jellu]

bakkerjangert schreef op maandag 5 december 2022 @ 12:04:
[...]


Oplossing gevonden, maar net onder de 5 minuten.

Hier ook de oplossing gevonden, met anderhalve minuut per deel

[Soultaker]

bakkerjangert schreef op maandag 5 december 2022 @ 12:04:
Oplossing gevonden, maar net onder de 5 minuten.

Gefeliciteerd! Dat is maar 750x trager dan m'n Python oplossing

Jellu schreef op maandag 5 december 2022 @ 12:15:
Hier ook de oplossing gevonden, met anderhalve minuut per deel

Ok, nog een iets grotere dan: aoc_2022_day05_large_input-2.zip (88 MB uitgepakt).

[Diderikdm]

Soultaker schreef op maandag 5 december 2022 @ 11:52:
Extra uitdaging voor dag 5: aoc_2022_day05_large_input.zip (uitgepakt 6 MB).

En een grotere: aoc_2022_day05_large_input-2.zip (88 MB uitgepakt).

Tip: met een goed algoritme moet dit in een paar seconden op te lossen zijn, ook in een scripttaal.
De oplossing: je weet 't als je 't weet.

Deze moet ik maar niet proberen met mn code in huidig format..

[MueR]

Het parsen kost meer tijd dan het solven https://github.com/MueR/a...fCode2022/Day05/Day05.php

[DataGhost]

Marcj schreef op maandag 5 december 2022 @ 11:53:
Voor de commando's is regex toch het makkelijkst om te parsen vind ik. Voor het laden van de stacks negeer ik nogal veel delen van de input, zoals de braces en whitespace. Ik heb kijk gewoon naar de positie van de character.

Waarom? Regex moet helemaal niet je eerste gedachte zijn IMO. Als je voornamelijk statische strings in je regex hebt staan is dat al een teken dat je vrijwel 0 van de features van de regex-engine gebruikt en dat deze daarom overbodig is.

spoiler:

Ik kijk gewoon of de regel begint met "move", dan split ik hem op spatie en daarna pak ik int() van (0-indexed) delen 1, 3 en 5.

Als je vervolgens je regeltype-checks op de juiste volgorde uitvoert hoef je niet te checken welke regels crates bevatten dus heb je daar ook geen uitgebreide checks voor nodig.

[ Voor 11% gewijzigd door DataGhost op 05-12-2022 13:32 ]

[Janoz]

Soultaker schreef op maandag 5 december 2022 @ 11:52:
Extra uitdaging voor dag 5: aoc_2022_day05_large_input.zip (uitgepakt 6 MB).

En een grotere: aoc_2022_day05_large_input-2.zip (88 MB uitgepakt).

Tip: met een goed algoritme moet dit in een paar seconden op te lossen zijn, ook in een scripttaal.
De oplossing: je weet 't als je 't weet.

Hmm, ik dacht dat ik door mijn naïeve stringconcatenaties te vervangen door linked lists wel wat snelheid zou vinden, maar dan nog blijf ik op een minuut voor deel 2 en 2 minuten voor deel 1 steken. Maar ik vermoed dat de werkelijke slimmigheid hem zit

spoiler:

in het achteruit redeneren.

[Wraldpyk]

Leuke challenge! Het hardcoden snap ik niet, want het is veel leuker om 'm gewoon op te lossen met parsen.

Ik heb 't vrij leesbaar en simpel opgelost met JavaScript! Het grote bestand gaat er niet snel door heen, maar de standaard input doet ie alsnog in 1.5ms

https://github.com/Topene...blob/2022/day5/program.js

[CMG]

Soultaker schreef op maandag 5 december 2022 @ 12:22:
[...]

Gefeliciteerd! Dat is maar 750x trager dan m'n Python oplossing


[...]


Ok, nog een iets grotere dan: aoc_2022_day05_large_input-2.zip (88 MB uitgepakt).

spoiler:

GATHERING
DEVSCHUUR

Lezen van de file: 55ms, parsen: 121ms, daarna werkt mijn code met stacks en duurt het wel ff 😅 (1m46s)

[Cranzai]

Soultaker schreef op maandag 5 december 2022 @ 11:52:
Extra uitdaging voor dag 5: aoc_2022_day05_large_input.zip (uitgepakt 6 MB).

En een grotere: aoc_2022_day05_large_input-2.zip (88 MB uitgepakt).

Tip: met een goed algoritme moet dit in een paar seconden op te lossen zijn, ook in een scripttaal.
De oplossing: je weet 't als je 't weet.

spoiler:

Oei, daar gaat mijn "elegante" oplossing toch ff goed de mist in.
Heb gewerkt met linked lists/deques, wel heel robuust en easy in elkaar te plakken maar nadat ik ff op Soultaker's git hebt gespiekt snap ik ook waarom mijn oplossing zo traag is, veulsteveul operations (eentje voor elke move )

Vanavond ook maar ff de mooie versie opschrijven.

[eheijnen]

In C-Scherp
Die file van 6MB met header inlezen
Part 1: ca. 136 seconden
Part 2: ca. 60 seconden

[Woy]

https://github.com/rverst.../blob/main/Y2022/Day05.cs

Niet heel erg tevreden over mijn code, want zou eigenlijk Aggregate willen gebruiken, maar dan zou ik ook een Immutable stack willen gebruiken ( ja ik weet dat die gewoon bestaat ), en voor part 2 een MultiPop/Push, maar geen zin/tijd om het te verbeteren.

Ik denk dat ik dit jaar maar genoegen ga nemen met de quick and easy implementaties

[ Voor 4% gewijzigd door Woy op 05-12-2022 14:18 ]

[Ghehe]

Janoz schreef op maandag 5 december 2022 @ 13:32:
[...]


Hmm, ik dacht dat ik door mijn naïeve stringconcatenaties te vervangen door linked lists wel wat snelheid zou vinden, maar dan nog blijf ik op een minuut voor deel 2 en 2 minuten voor deel 1 steken. Maar ik vermoed dat de werkelijke slimmigheid hem zit

spoiler:

in het achteruit redeneren.

spoiler:

Linked Lists was ook mijn eerste idee omdat je dan gewoon wat pointers kan aanpassen om een heel deel van stapel te verhuizen. Maar dan komt inderdaad de bedenking hoe je efficient van de top van de stapel naar item 10.000 kan gaan zonder 10.000 linked list items te traversen. En shortcuts implementeren is ook weer zo'n gedoe.

Mijn volgende idee was een stapel te implementeren als een datastructuur (met wat metadata) van meerdere linked lists (initieel 1 maar bij elke move split je). Maar ik was er nog niet uit of dat effectief veel sneller zou zijn na veel permutaties waarbij de linked lists steeds kleiner en kleiner worden... (dan moet je weer een "merger" implementeren om de efficientie te bewaren)

[MaNDaRK]

Okay, ik geef het toe... ik heb eerst de array handmatig ingeklopt en daarna pas de parser geschreven.

Was een leuke uitdaging: Day 5 - Python

[MueR]

Soultaker schreef op maandag 5 december 2022 @ 11:52:
Extra uitdaging voor dag 5: aoc_2022_day05_large_input.zip (uitgepakt 6 MB).

1444.7 ms om de file te lezen en te parsen, 4381.8 ms voor deel 1, 1342.5 ms voor deel 2. Niet slecht voor php

[Soultaker]

Cranzai schreef op maandag 5 december 2022 @ 13:55:
nadat ik ff op Soultaker's git hebt gespiekt snap ik ook waarom mijn oplossing zo traag is

Slim bedacht, maar de meest efficiënte versie van m'n oplossing heb ik expres nog niet geüpload.

MueR schreef op maandag 5 december 2022 @ 14:25:
1444.7 ms om de file te lezen en te parsen, 4381.8 ms voor deel 1, 1342.5 ms voor deel 2. Niet slecht voor php

Maar niet met je eerdere oplossing toch? Want ik kan me niet voorstellen dat die zo snel is; je moet er wat fundamenteels aan verbeterd hebben.

[Janoz]

Soultaker schreef op maandag 5 december 2022 @ 14:46:
Slim bedacht, maar de meest efficiënte versie van m'n oplossing heb ik expres nog niet geüpload.

Oh, gelukkig, ik begon al te twijfelen. Kon me moeilijk voorstelen dat python array operaties zo extreem veel sneller zouden zijn dan mijn linked list implementatie.


Dag 5

[Hydra]

armageddon_2k1 schreef op vrijdag 2 december 2022 @ 12:45:
Altijd leuk om m’n oplossingen in Kotlin met die van @Hydra te vergelijken.

Voel me aangevallen

Ik heb op dit moment geen tijd Misschien op een later moment kijken hoe ver ik kom voordat ik het te lang vind duren.

[Cranzai]

Soultaker schreef op maandag 5 december 2022 @ 14:46:
[...]

Slim bedacht, maar de meest efficiënte versie van m'n oplossing heb ik expres nog niet geüpload.


[...]

Was hem net aan het testen en als ik me niet vergis is die langzamer dan mijn oude

[YoToP]

oke, ik hang ook rond de 5 minuten met deze code bij de 6MB input

Als ik hierboven goed begrijp is de hint is dus

spoiler:

gebruik(in Python) geen arrays, maar bijv. een Linked List.

[Marcj]

Marcj schreef op maandag 5 december 2022 @ 11:53:
[...]

Ok, mijn stomme simpele oplossing werkt hier niet voor, maar wel een leuke uitdaging om te laten werken. Je moet dus grote blokken data kunnen verplaatsen, volgens mij is een LinkedList hier beter voor
Ik ga nog even optimaliseren, thanks voor deze input!

Ok, ik heb een kleine optimalisatie gedaan. Compleet ander idee, maar werkt wel erg goed en schaalt ook echt mooi! Deze 6Mb input wordt nu in 55ms verwerkt:

spoiler:

Day 5:
Part 1: GATHERING
Part 2: DEVSCHUUR
Calculated in 0,055 seconds

De nog grotere is maar iets langzamer, maar niet van die mooie woorden:

spoiler:

Day 5:
Part 1: QERVUBOOM
Part 2: HENBLEIFT
Calculated in 0,264 seconds

Voor het idee:

spoiler:

https://github.com/marcde...ejonge/advent2022/Day5.kt

Ik begin nu bij de eindpositie en ga de commando's in omgekeerde volgorde afspelen. Dan hoef ik alleen maar 1 positie bij te houden en dat is de plek van het character waar ik naar op zoek ben. Als alle commando's terug gespoeld zijn heb ik de positie in de originele input die ik zoek.

[ Voor 7% gewijzigd door Marcj op 05-12-2022 15:14 ]

[Marcj]

DataGhost schreef op maandag 5 december 2022 @ 13:30:
[...]

Waarom? Regex moet helemaal niet je eerste gedachte zijn IMO. Als je voornamelijk statische strings in je regex hebt staan is dat al een teken dat je vrijwel 0 van de features van de regex-engine gebruikt en dat deze daarom overbodig is.

spoiler:

Ik kijk gewoon of de regel begint met "move", dan split ik hem op spatie en daarna pak ik int() van (0-indexed) delen 1, 3 en 5.

Als je vervolgens je regeltype-checks op de juiste volgorde uitvoert hoef je niet te checken welke regels crates bevatten dus heb je daar ook geen uitgebreide checks voor nodig.

Ik vind persoonlijk de code van mij met deze regex erg begrijpelijk. Een stuk code met string split doe beperkte checks met meer complexiteit in mijn idee.

[Soultaker]

Marcj schreef op maandag 5 december 2022 @ 15:03:
De nog grotere is maar iets langzamer, maar niet van die mooie woorden:

Hm, zou wel zo moeten zijn, dus één van ons heeft een bug; ik sluit niet uit dat ik dat ben. Wat het eerste woord zou moeten zijn kun je waarschijnlijk wel raden.

[Marcj]

Soultaker schreef op maandag 5 december 2022 @ 15:19:
[...]

Hm, zou wel zo moeten zijn, dus één van ons heeft een bug; ik sluit niet uit dat ik dat ben. Wat het eerste woord zou moeten zijn kun je waarschijnlijk wel raden.

Damn it... nu moet ik gaan kijken of er edge-cases zijn die ik misschien vergeten ben. Waarom zouden we er bij de 88Mb versie wel tegenaan lopen, maar bij de 6Mb versie niet?

Een idee: heb je toevallig een commando die meer probeert te pakken dan er op een stack zit? Want daar hou ik duidelijk geen rekening mee. Met een iets andere implementatie zou ik dat wel kunnen detecteren, als ik eerst counters bijhoud hoe groot stacks zijn gedurende het proces.

[ Voor 23% gewijzigd door Marcj op 05-12-2022 15:27 ]

[MueR]

Soultaker schreef op maandag 5 december 2022 @ 14:46:
Maar niet met je eerdere oplossing toch? Want ik kan me niet voorstellen dat die zo snel is; je moet er wat fundamenteels aan verbeterd hebben.

Nee, ik heb hem omgecat naar gewoon een string based versie. Voor de 88mb file heeft ie wel wat moeite

[eheijnen]

In C-Scherp - Eens wat anders geprobeerd....
Op een i7 3770.
Die file van 6MB met header inlezen
Part 1: ca. 10 seconden (was 136)
Part 2: ca. 4 seconden (was 60)

[ Voor 5% gewijzigd door eheijnen op 05-12-2022 16:11 ]

[Soultaker]

Marcj schreef op maandag 5 december 2022 @ 15:20:
Damn it... nu moet ik gaan kijken of er edge-cases zijn die ik misschien vergeten ben. Waarom zouden we er bij de 88Mb versie wel tegenaan lopen, maar bij de 6Mb versie niet?

De twee bestanden zouden op dezelfde manier gegenereerd moeten zijn.

Een idee: heb je toevallig een commando die meer probeert te pakken dan er op een stack zit? Want daar hou ik duidelijk geen rekening mee. Met een iets andere implementatie zou ik dat wel kunnen detecteren, als ik eerst counters bijhoud hoe groot stacks zijn gedurende het proces.

Als het goed is komt dat niet voor (ik check daar wel op in mijn oplossing).

Hoe run ik jouw oplossing? Ik heb je git repo geclonet en gradlew build gerunt maar dat geeft een foutmelding tijdens het testen: https://pastebin.com/raw/azJasB21

edit:
Ik heb jouw algoritme (dat trouwens véél eleganter geïmplementeerd was dan de mijne, hoewel het idee erachter hetzelfde is) naar Python geport en dan krijg ik nog steeds de verwachtte uitkomst. Ik heb dus nu twee oplossingen die op de I/O logica na compleet verschillend zijn; ofwel ik heb ergens een bug in de I/O, of ik neig er naar dat jouw oplossing ergens een subtiele bug bevat.

[ Voor 18% gewijzigd door Soultaker op 05-12-2022 16:20 ]

[CMG]

Soultaker schreef op maandag 5 december 2022 @ 12:22:
[...]

Gefeliciteerd! Dat is maar 750x trager dan m'n Python oplossing


[...]


Ok, nog een iets grotere dan: aoc_2022_day05_large_input-2.zip (88 MB uitgepakt).

Op Reddit waren ze blij met je grotere inputs; of je die ook voor andere dagen hebt gemaakt 😊 misschien daar even een draadje maken: https://www.reddit.com/r/...utm_name=iossmf&context=3

[eheijnen]

Marcj schreef op maandag 5 december 2022 @ 15:20:
[...]


Damn it... nu moet ik gaan kijken of er edge-cases zijn die ik misschien vergeten ben. Waarom zouden we er bij de 88Mb versie wel tegenaan lopen, maar bij de 6Mb versie niet?

Een idee: heb je toevallig een commando die meer probeert te pakken dan er op een stack zit? Want daar hou ik duidelijk geen rekening mee. Met een iets andere implementatie zou ik dat wel kunnen detecteren, als ik eerst counters bijhoud hoe groot stacks zijn gedurende het proces.

Met welk type CPU haal jij dit?

[Marcj]

Soultaker schreef op maandag 5 december 2022 @ 15:50:
[...]

De twee bestanden zouden op dezelfde manier gegenereerd moeten zijn.


[...]

Als het goed is komt dat niet voor (ik check daar wel op in mijn oplossing).

Hoe run ik jouw oplossing? Ik heb je git repo geclonet en gradlew build gerunt maar dat geeft een foutmelding tijdens het testen: https://pastebin.com/raw/azJasB21

edit:
Ik heb jouw algoritme (dat trouwens véél eleganter geïmplementeerd was dan de mijne, hoewel het idee erachter hetzelfde is) naar Python geport en dan krijg ik nog steeds de verwachtte uitkomst. Ik heb dus nu twee oplossingen die op de I/O logica na compleet verschillend zijn; ofwel ik heb ergens een bug in de I/O, of ik neig er naar dat jouw oplossing ergens een subtiele bug bevat.

Dank je, ik had dit over het hoofd gezien. Er zat een extra enter in de 88Mb variant, waarvoor ik een trim had toegevoegd, maar deze verwijderde ook wat spaties aan het begin

Nu wel een goed resultaat:

spoiler:

Day 5:
Part 1: KERSTBOOM
Part 2: HENKLEEFT
Calculated in 0,289 seconds

[Marcj]

eheijnen schreef op maandag 5 december 2022 @ 16:20:
[...]

Met welk type CPU haal jij dit?

Op mijn M1 Pro macBook. Maar dit is wel zonder het inlezen van het bestand, alleen het rekenstuk wordt hier in meegenomen.

[eheijnen]

De tijd zit'm in het schuiven met de "kratten" het inlezen is daar maar een fractie van.

[Janoz]

DataGhost schreef op maandag 5 december 2022 @ 13:30:

spoiler:

Ik kijk gewoon of de regel begint met "move", dan split ik hem op spatie en daarna pak ik int() van (0-indexed) delen 1, 3 en 5.

Als je vervolgens je regeltype-checks op de juiste volgorde uitvoert hoef je niet te checken welke regels crates bevatten dus heb je daar ook geen uitgebreide checks voor nodig.

spoiler:

Waarom checken op move? je kunt er toch vanuit gaan dat er, na het inlezen van de stacks, alleen nog maar moves komen?

[DataGhost]

Janoz schreef op maandag 5 december 2022 @ 16:36:
[...]

spoiler:

Waarom checken op move? je kunt er toch vanuit gaan dat er, na het inlezen van de stacks, alleen nog maar moves komen?

spoiler:

Omdat ik het inlezen heb gedaan met een enkele (Python) "for line in lines:" loop en verder geen state bijhoud. Eerst kijk ik of de regel leeg is of begint met " 1", die kunnen overgeslagen, daarna kijk ik of het begint met "move" en als het al die dingen niet is, is het dus een regel met een of meer crates waarvan de inhoud op positie 1+4k staat.

[eheijnen]

Ik heb de stacks eruit gehaald en in een aparte file gezet.

[Jern_97]

Voor de 6MB variant haal ik 2ms per part (exclusief inlezen)
Voor de 88MB variant haal ik 390ms per part (exclusief inlezen)

Zelfde algoritme als @Marcj, geimplementeerd in Rust op M1 Pro

[Soultaker]

OK, nog een uitdaging voor dag 5: aoc_2022_day05_large_input-3.zip (201 MB uitgepakt). Deze bevat meer dan 9 kolommen; de regel met de kolomnummers ("1 2 3 4 5 6 7 8 9" in de originele invoer) heb ik vervangen door nullen.

Deze invoer is ook in enkele seconden op te lossen met een geschikt algoritme, en de invoer is nog niet zo moeilijk als het zou kúnnen zijn.

De uitvoer is ook langer dan 9 karakters. Hierbij alvast de SHA-256 hash van de antwoorden (alleen de letters, geen newline):

334dc3fea65d33eb2475f356fdad3edf39c91f874e87f92eb1189b9603251d81

en

881993c12f35922a8a8a6ef3fd2ffb6ee20069f52b4e077131eb61dbc70b0001

(en zoals gebruikelijk is het correcte antwoord een “leesbare” tekst).

[Reptile209]

Weer in Excel/VBA opgelost .

spoiler:

Eerst alle regels van de stacks tot aan de lege regel inlezen in een array. Die dan in omgekeerde volgorde teruglezen om de stacks van onder naar boven op te bouwen. Als je vanaf de tweede char in stappen van 3 door de string loopt, en daar een letter ziet, weet je bij welke stack die hoort.
Elke stack is een string bij mij (bij opbouwen een kwestie van string aanvullen), dus gewoon de meest rechter char als top (part 1). En een langer stuk van rechts voor part 2. Appeltje-eitje.
Oh, en met een string splitter op de spatie pak je de cijfers voor de moves er op index in een keer uit.

[ Voor 8% gewijzigd door Reptile209 op 05-12-2022 19:03 ]

[Jern_97]

Soultaker schreef op maandag 5 december 2022 @ 17:40:
OK, nog een uitdaging voor dag 5: aoc_2022_day05_large_input-3.zip (201 MB uitgepakt). Deze bevat meer dan 9 kolommen; de regel met de kolomnummers ("1 2 3 4 5 6 7 8 9" in de originele invoer) heb ik vervangen door nullen.

Deze invoer is ook in enkele seconden op te lossen met een geschikt algoritme, en de invoer is nog niet zo moeilijk als het zou kúnnen zijn.

De uitvoer is ook langer dan 9 karakters. Hierbij alvast de SHA-256 hash van de antwoorden (alleen de letters, geen newline):

334dc3fea65d33eb2475f356fdad3edf39c91f874e87f92eb1189b9603251d81

en

881993c12f35922a8a8a6ef3fd2ffb6ee20069f52b4e077131eb61dbc70b0001

(en zoals gebruikelijk is het correcte antwoord een “leesbare” tekst).

Iets meer dan 12 seconden per part nu ongeveer. Heb wel de indruk dat dit nog een stukje trager is dan @Soultaker en @Marcj...

[Cranzai]

Ugh, kan die slimme oplossing van marcj niet helemaal volgen
Voor nu maar de witte vlag gehesen

[Jern_97]

Na enkele optimalisaties kom ik nu aan de volgende rekentijden (beide delen, exclusief parsing):
6MB: 4ms
88MB: 73ms
210MB: 266ms

Rust, Apple M1 Pro

https://github.com/Jeroen...2/blob/main/src/day5_2.rs
(code is niet super clean, maar heb weinig zin om alles op te schonen )

EDIT: AMD 7950X doet er respectievelijk 2ms, 47ms en 186ms over

[ Voor 10% gewijzigd door Jern_97 op 05-12-2022 22:19 ]

[gedonie]

Einde dag toch nog even tijd gehad om dag 5 op te lossen. In java https://github.com/gjong/...e/main/src/main/java/day5.

spoiler:

Was vooral even puzzelen om te achterhalen dat ik een stack moest gebruiken voor het gemak.

[Creepy]

Weer eens langer bezig met input parsen dan met het daadwerkelijk oplossen van het probleem. Affijn.
https://github.com/CodeEn...er/aoc/aoc2022/Day05.java

spoiler:

Gewoon dom stacks aanmaken

[TrailBlazer]

Mijn code nog even
https://gitlab.com/NetTin...-/blob/main/day5/task1.py
mischien geen fantastische oneliners maar volgens mij best wel clean.

[Marcj]

Cranzai schreef op maandag 5 december 2022 @ 19:31:
Ugh, kan die slimme oplossing van marcj niet helemaal volgen
Voor nu maar de witte vlag gehesen

Het is eigenlijk een recursieve oplossing. Wat meer details:

spoiler:

Om te beginnen redeneren we van achteren naar voren. Dus we beginnen met de plek van de character waar hij eindigt, want we willen weten waar deze character vandaag is gekomen. Bijvoorbeeld de hoogste character van de eerste stack (stackIx = 0, charIx = 0). Daarna ga ik voor elk commando in omgekeerde volgorde deze terugdraaien om uit te vinden welke positie deze character in de originele set had.

Voor elk commando zijn er een 4-tal opties:
1) Het commando heeft iets verplaatst van de huidige stack naar een andere stack. Dat betekent dat hiervoor de index van de character een stuk hoger was, namelijk zoveel als de count van het commando. Er stonden voor dit commando namelijk 'count' andere characters bovenop die verplaatst waren.
2) Het commando verplaatst iets naar een andere stack vanaf een andere stack. Dan veranderd er dus helemaal niks.
3) Er werden characters verplaatst naar deze stack toe, dan zijn er 2 sub-opties:
3a) De index van de huidige character is groter of gelijk dan het aantal die verplaatst zijn, dan zijn er 'count' characters dus verwijderd vanaf deze stack. Dus de index van het character moet verlaagd worden met deze 'count'. Doordat deze altijd kleiner of gelijk is, zal de index nooit minder dan 0 worden.
3b) De index van de huidige character is kleiner dan het aantal die verplaatst zijn, dan is de plek van deze character dus van een andere stack gekomen. Dan gaan we dus de plek op de nieuwe stack berekenen. Deze is voor opgave 1 de omgekeerde plek (dus count - index + 1), maar voor opgave 2 nog simpler, namelijk dezelfde plek.

Als je dit blok voor elk commando uitvoert, dan kom je uiteindelijk bij de startplek uit. Deze kun je eenvoudig uit de tabel aflezen!

Mijn code is blijkbaar hier nog niet leesbaar genoeg voor, misschien kan het nog beter...

[Marcj]

Soultaker schreef op maandag 5 december 2022 @ 17:40:
OK, nog een uitdaging voor dag 5: aoc_2022_day05_large_input-3.zip (201 MB uitgepakt). Deze bevat meer dan 9 kolommen; de regel met de kolomnummers ("1 2 3 4 5 6 7 8 9" in de originele invoer) heb ik vervangen door nullen.

Deze invoer is ook in enkele seconden op te lossen met een geschikt algoritme, en de invoer is nog niet zo moeilijk als het zou kúnnen zijn.

De uitvoer is ook langer dan 9 karakters. Hierbij alvast de SHA-256 hash van de antwoorden (alleen de letters, geen newline):

334dc3fea65d33eb2475f356fdad3edf39c91f874e87f92eb1189b9603251d81

en

881993c12f35922a8a8a6ef3fd2ffb6ee20069f52b4e077131eb61dbc70b0001

(en zoals gebruikelijk is het correcte antwoord een “leesbare” tekst).

Mijn huidige versie doet het nu in 122 seconden, dat lijkt me wat traag. Ik ga nog even kijken wat er beter kan...

edit: van een meer functionele stijl met objecten naar domme int arrays scheelt al een factor 3

[ Voor 4% gewijzigd door Marcj op 05-12-2022 22:07 ]

[SPee]

Soultaker schreef op maandag 5 december 2022 @ 11:52:
En een derde: aoc_2022_day05_large_input-3.zip (201 MB uitgepakt). Deze bevat meer dan 9 kolommen; de regel met de kolomnummers ("1 2 3 4 5 6 7 8 9" in de originele invoer) heb ik vervangen door nullen.

Dat zou voor mijn oplossing niet werken. Ik gebruik die nummer namelijk om de juiste stack op te halen.
Hierdoor kan ik ook andere (niet opeenlopende) volgordes aan. Maar dus niet wanneer er meerdere dezelfde kolomnummers zijn.

[Brilsmurfffje]

YoToP schreef op maandag 5 december 2022 @ 15:01:
oke, ik hang ook rond de 5 minuten met deze code bij de 6MB input

Als ik hierboven goed begrijp is de hint is dus

spoiler:

gebruik(in Python) geen arrays, maar bijv. een Linked List.

Hmm ik ben dan wel benieuwd waar je dan de extra snelheid uit zou kunnen halen. Want .pop() en .append() zijn O(1) omdat er geen data verschoven hoeft te worden, wat vergelijkbaar is met linked lists

[eheijnen]

Marcj schreef op maandag 5 december 2022 @ 21:37:
[...]


Het is eigenlijk een recursieve oplossing. Wat meer details:

[spoiler]
Om te beginnen redeneren we van achteren naar voren. Dus we beginnen met de plek van de character waar hij eindigt, want we willen weten waar deze character vandaag is gekomen. Bijvoorbeeld de hoogste character van de eerste stack (stackIx = 0, charIx = 0). Daarna ga ik voor elk commando in omgekeerde volgorde deze terugdraaien om uit te vinden welke positie deze character in de originele set had.
.....

Maar als ik die code van jouw lees dan worden die objecten per opdracht ook van de ene naar de andere stack verplaatst.

Wat ik met .Net heb gevonden:
Ik heb een array van negen list<char> (de stacks)

C#:

//where to start in the stack
nStackStartIndex = stacks[ nFromStack ].Count - nNumToMove;

//copy to the "To Stack"
stacks[ nToStack ].AddRange( stacks[ nFromStack ].GetRange( nStackStartIndex, nNumToMove ) );

De opdracht hierboven waar de elementen aan de "To Stack" worden toegevoegd is de actie die bijna alle tijd opslurpt, ca. 90/95%.

Misschien heeft iemand een idee of daar een ander List<T> achtig ding voor bestaat wat beter uit de was komt?

[Marcj]

eheijnen schreef op maandag 5 december 2022 @ 22:29:
[...]

Maar als ik die code van jouw lees dan worden die objecten per opdracht ook van de ene naar de andere stack verplaatst.

Wat ik met .Net heb gevonden:
Ik heb een array van negen list<char> (de stacks)

C#:

//where to start in the stack
nStackStartIndex = stacks[ nFromStack ].Count - nNumToMove;

//copy to the "To Stack"
stacks[ nToStack ].AddRange( stacks[ nFromStack ].GetRange( nStackStartIndex, nNumToMove ) );

De opdracht hierboven waar de elementen aan de "To Stack" worden toegevoegd is de actie die bijna alle tijd opslurpt, ca. 90/95%.

Misschien heeft iemand een idee of daar een ander List<T> achtig ding voor bestaat wat beter uit de was komt?

Dan zit je waarschijnlijk naar m'n oude code te kijken, de nieuwe versie doet dit wat slimmers.

[Visitor.q]

Vandaag Day 05 gedaan, het parsen was eigenlijk met name het probleem. Toen dat eenmaal gebeurd was moest ik me nog wel even vastbijten in het index systeem van lists.

Members only: Python day 5

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

YoToP schreef op maandag 5 december 2022 @ 08:49:
Mijn Python code

spoiler:

kan totaal niet omgaan met andere hoogtes of ander aantal stacks. Vanavond maar even afkijkenleren hoe dat gemakkelijk dynamisch kan.

Dan kijk ik effe af hoe jij de line met moves stript en split. Veel mooier dan ik het had, ik deed een regular expression, daarna list comprehension, unpacken, en dan nog moest ik de indices voor 'van' en 'naar' met 1 verminderen omdat mijn tellertje bij 0 begon... Nee, dit was niet mijn elegantste werk...

[BeefHazard]

Visitor.q schreef op maandag 5 december 2022 @ 22:49:
Vandaag Day 05 gedaan, het parsen was eigenlijk met name het probleem. Toen dat eenmaal gebeurd was moest ik me nog wel even vastbijten in het index systeem van lists.


***members only***

Ik wilde je een paar puntjes feedback geven die mij opvielen aan je code, maar toen zag ik je GitHub profiel. Shit, als ik een andere master aan het doen was had je mijn docent kunnen zijn, dat voelt niet goed

Edit: ook nog even iets toevoegen aan het topic. Ik heb ze vandaag allemaal in Python ingehaald, toch mijn go-to taal als ik gewoon even snel dingen voor elkaar moet krijgen. Het is voor het eerst dat ik meedoe en dat ik tot aan dag 5 alles met gemak in elkaar zet. Ik herinner me eerdere jaren met een intcode-computer die me helemaal vloerde. Ben benieuwd wat de komende weken gaan brengen

[ Voor 27% gewijzigd door BeefHazard op 05-12-2022 22:56 ]

[MatHack]

BeefHazard schreef op maandag 5 december 2022 @ 22:53:
[...]


Ik wilde je een paar puntjes feedback geven die mij opvielen aan je code, maar toen zag ik je GitHub profiel. Shit, als ik een andere master aan het doen was had je mijn docent kunnen zijn, dat voelt niet goed

In mijn ogen gewoon de feedback geven, niemand is te oud/geleerd om te leren

[Visitor.q]

BeefHazard schreef op maandag 5 december 2022 @ 22:53:
[...]


Ik wilde je een paar puntjes feedback geven die mij opvielen aan je code, maar toen zag ik je GitHub profiel. Shit, als ik een andere master aan het doen was had je mijn docent kunnen zijn, dat voelt niet goed

Ga gerust je gang, ik doe dit juist in Python om er wat vloeiender in te worden en er wat routine in te krijgen Mijn go-to talen zijn Matlab en C/C++, maar dan vooral grootschalig number crunchen en niet zozeer kratjes stapelen

Ik had al bij iemand gezien hoe de input parsing beter kan (zonder loop of if-statements), en dat met deque/collections veel te doen is.

[sunib]

Soultaker schreef op maandag 5 december 2022 @ 17:40:
OK, nog een uitdaging voor dag 5: aoc_2022_day05_large_input-3.zip (201 MB uitgepakt). Deze bevat meer dan 9 kolommen; de regel met de kolomnummers ("1 2 3 4 5 6 7 8 9" in de originele invoer) heb ik vervangen door nullen.

Deze invoer is ook in enkele seconden op te lossen met een geschikt algoritme, en de invoer is nog niet zo moeilijk als het zou kúnnen zijn.

De uitvoer is ook langer dan 9 karakters. Hierbij alvast de SHA-256 hash van de antwoorden (alleen de letters, geen newline):

334dc3fea65d33eb2475f356fdad3edf39c91f874e87f92eb1189b9603251d81

en

881993c12f35922a8a8a6ef3fd2ffb6ee20069f52b4e077131eb61dbc70b0001

(en zoals gebruikelijk is het correcte antwoord een “leesbare” tekst).

Heel gaaf die input : parsen is voor C# en dotnet 7 een eitje kwa tijd (een paar tellen). Maar het doorlopen van die regels is voor mijn oplossing nogal traag. 8,2 minuten. Hmmmm.

[Trasos]

@sunib , hier hetzelfde met C#.
Zit je dan met je i7 12700K, waarvan maar één thread gebruikt wordt.

Eerste keer dat ik meedoe, ben ik ook eigenlijk maar een C# noob, dus leer er sowieso al erg veel van.
Alleen al advanced (voor mij dan) Linq constructies zijn interessant om eens gezien te hebben.

[BeefHazard]

Visitor.q schreef op maandag 5 december 2022 @ 23:20:
[...]

Ga gerust je gang, ik doe dit juist in Python om er wat vloeiender in te worden en er wat routine in te krijgen Mijn go-to talen zijn Matlab en C/C++, maar dan vooral grootschalig number crunchen en niet zozeer kratjes stapelen

Ik had al bij iemand gezien hoe de input parsing beter kan (zonder loop of if-statements), en dat met deque/collections veel te doen is.

Oké, paar dingen die ik zie dan.

- Let op pep8 (vscode kan hier enorm bij helpen), dingen zoals consequent spaties na komma's en witregels op de juiste plaatsen helpen jezelf enorm. Python is ontworpen vanuit de gedachte je ook tijdens het programmeren meer je eigen code aan het lezen bent dan aan het schrijven.
- Pep8 geldt ook voor hoofdletters en snake_case, al vind ik het voor een chemicus wel passend om variabelen als Nc, Fr, To te maken Maar als ik 't snel doorlees denk ik dat dat classes zijn, zo kleurt GitHub ze ook in.
- Super cool dat je regex gebruikt, heb ik zelf niet gedaan
- je kunt

code:

for line,n in zip(lines,range(len(lines))):

Iets meer Pythonic en leesbaarder schrijven als::

code:

for (n, line) in enumerate(lines):

- de hele moveList-routine tussen lines 10 en 16 kun je uit de grote loop halen als functie en alleen aanroepen als hasInit. Dat soort 'separation of concerns' maakt alles gelijk leesbaarder en maakt het tijdens het ontwikkelen makkelijker om te ontdekken welke dingen wel goed gaan en welke niet. Des te meer je gaat zoeken naar manieren om subroutines die je kan hergebruiken in een aparte function te zetten, des te minder je voor elke dag weer een nieuwe grote loop zit te schrijven. Op een gegeven moment merk je dat je regelmatig (enigszins aangepaste) onderdelen van vorige dagen kan hergebruiken zonder dat ze afhankelijk zijn van alles dat je in de loop van die dag had lopen

[The Fox NL]

Swedish Clown schreef op donderdag 1 december 2022 @ 09:39:
Bonus challenge for those that accept


***members only***


@P_Tingen ^

Ongeveer 955 milliseconden in C# op een i5 3570k.

@.oisyn Nice, mijn oplossing is een simpele FileStream met een buffer van 1 MB en byte for byte door de buffer heen. Een buffer van 5MB of meer maakte het bij mij weer iets langzamer (30 milliseconden ofzo).

[ Voor 29% gewijzigd door The Fox NL op 06-12-2022 01:00 ]

[.oisyn]

The Fox NL schreef op dinsdag 6 december 2022 @ 00:04:
[...]

Ongeveer 955 milliseconden in C# op een i5 3570k.

Mijn 37ms was trouwens op een 5800X.

@The Fox NL Memory mapped files zijn je vriend

Soultaker schreef op maandag 5 december 2022 @ 17:40:
OK, nog een uitdaging voor dag 5: aoc_2022_day05_large_input-3.zip (201 MB uitgepakt).

2,5s volledige running time

Wat is een "geschikt algoritme"? Ik volg hier gewoon dom alle moves .

[ Voor 53% gewijzigd door .oisyn op 06-12-2022 01:13 ]

[Soultaker]

.oisyn schreef op dinsdag 6 december 2022 @ 00:24:
Wat is een "geschikt algoritme"? Ik volg hier gewoon dom alle moves .

Heb je deel 2 (zie hier) geprobeerd?

Als je in C++ code, moet je eigenlijk alledrie de test cases in (veel) minder dan 1 seconde kunnen oplossen.

[.oisyn]

Soultaker schreef op dinsdag 6 december 2022 @ 01:23:
[...]


Heb je deel 2 (zie hier) geprobeerd?

Nee ik ben gewoon begonnen met de laatste.

Ik weet wel hoe ik het algo moet verbeteren hoor, maar ik zit met een hele domme implementatie dus al aan de onderkant van de tijden die ik hier lees

.edit: ah ja set 2 heeft ie idd wat meer moeite mee
.edit2: zo'n 200s.

[ Voor 7% gewijzigd door .oisyn op 06-12-2022 01:31 ]

[.oisyn]

@Soultaker
Ok dit is beter

Set1: 6ms
Set2: 95ms 66ms
Set3: 232ms 122ms

(Dit is dus inclusief alle parsing. Maar wel met de files in m'n cache)

[ Voor 43% gewijzigd door .oisyn op 06-12-2022 03:32 ]

[jmerle]

Dag 6 in Python

Vandaag was weer een makkelijke dag, en gelukkig was ik weer een keer snel genoeg om punten voor de algemene ranglijst te verdienen (26e/23e).

[MatHack]

Dag 6 was weer beter te doen.

spoiler: (C#) aannames zijn dodelijk

Had sneller gekund als ik de C# reference voor HashSet ook daadwerkelijk had gelezen ipv er vanuit gaan dat duplicates daarin een Exception throwen (wat ie dus niet doet), dan had mijn oplossing waarschijnlijk meer geleken op die van @jmerle.

EDIT: Toch maar een refactor gedaan van mijn oplossing, kortste code tot nu toe...

[ Voor 14% gewijzigd door MatHack op 06-12-2022 07:59 ]

[Diderikdm]

Vond deze een van de makkelijkere tot nu toe

Dag 6 - Python

[ Voor 9% gewijzigd door Diderikdm op 08-12-2022 14:21 ]

[TrailBlazer]

Ik wilde niet het hele bestand in het geheugen laden en ik wilde deque een keer gebruiken.
Dag6 - Python

[Osxy]

Vandaag was by far de simpelste van dit jaar. Had oplossing echt zo in elkaar.

Dag 6 - C#

[TrailBlazer]

nogal een verschil met day 6 vorig jaar Lanternfish

[Mawlana]

De verwijzing naar de Intcode computer van een paar jaar geleden baart me zorgen. Ik had m'n code niet vanaf dag 1 op orde destijds waardoor ik het wiel telkens opnieuw moest uitvinden.

[dcm360]

Dus, iemand nog zin in een iets grotere invoer?
Ideale puzzel om decompressie-bommen mee te bouwen, dus let er even op dat het laatste bestand na uitpakken iets meer dan 800MB is.

[MaNDaRK]

Wat een hoop tekst, moest wel even twee keer kijken wat ze bedoelde zo op de vroege ochtend.

Maar hij was makkelijk. Is dit een voorbode voor morgen?

Dag 6 - Python

[Woy]

https://github.com/rverst.../blob/main/Y2022/Day06.cs

Weer vrij eenvoudig, maar had toch nog een foutje

spoiler:

Ik gaf de startpositie van de range terug, niet het einde, een + markerLength fixte het eenvoudig

[ Voor 9% gewijzigd door Woy op 06-12-2022 09:33 ]

[Marcj]

Nou inderdaad, deze was erg simpel toen ik eenmaal door de tekst heen was. Ik weet dat mijn oplossing efficiënter kan, maar voor die paar ms, laat maar zitten...

https://github.com/marcde...ejonge/advent2022/Day6.kt

[Janoz]

dcm360 schreef op dinsdag 6 december 2022 @ 09:15:
Dus, iemand nog zin in een iets grotere invoer?
Ideale puzzel om decompressie-bommen mee te bouwen, dus let er even op dat het laatste bestand na uitpakken iets meer dan 800MB is.

Als je echt je algoritme wilt flexen, zul je ook een grotere buffer moeten nemen. Met een size van 14 ga je denk ik niet echt verschil zien tussen een naïve O(N²) en een efficiënte O(1) matcher.

[breew]

Deze was echt appeltje eitje zeg... stilte voor de storm?
dag 6 in R

spoiler:

Ik had bij part 1 al een functie geschreven met variabele n voor groeplengte, dus part 2 was ook direct opgelost. Is nog wel een brute-force solution, waarbij eerst alle groepen van lengte n worden gemaakt, en pas daarna de eerste occurence met n unieke characters wordt gezocht.
Voor nu snel zat.

spoiler:

ok.. ook nog maar even een while-loopje erbij gemaakt; rekentijd gaat nu ongeveer naar een factor 1/3 (wel een beetje afhankelijk hoe ver naar het einde de eerste groep zit uiteraard.)

[ Voor 18% gewijzigd door breew op 06-12-2022 09:54 ]

[Dricus]

Dag 6 - Kotlin

Deze was inderdaad wel heel eenvoudig op te lossen.

[Marcj]

.oisyn schreef op dinsdag 6 december 2022 @ 02:14:
@Soultaker
Ok dit is beter

Set1: 6ms
Set2: 95ms 66ms
Set3: 232ms 122ms

(Dit is dus inclusief alle parsing. Maar wel met de files in m'n cache)

Heel netjes! Ik heb het gevoel dat ik met Set3 de grenzen van de JVM aan het raken ben. Soms doet hij er 40 seconden over, soms 400 seconden. En ik ben er nog niet helemaal achter waarom. Terwijl volgens mij het algoritme heel erg simpel is...

Misschien toch eens een excuus om Rust of Go to gaan proberen?

[ Voor 6% gewijzigd door Marcj op 06-12-2022 09:38 ]

[FrankMennink]

Dag 6 in Python

spoiler:

Deel 2 was tot nu toe de makkelijkste swap, 4 -> 14 en klaar

[ Voor 6% gewijzigd door FrankMennink op 06-12-2022 10:45 . Reden: spoiler tags ]

[Jern_97]

dcm360 schreef op dinsdag 6 december 2022 @ 09:15:
Dus, iemand nog zin in een iets grotere invoer?
Ideale puzzel om decompressie-bommen mee te bouwen, dus let er even op dat het laatste bestand na uitpakken iets meer dan 800MB is.

Voor de 800MB instantie:

Part 1: 85803316
Part 2: 457617684
Time: 1332ms

Ik heb het gevoel dat het waarschijnlijk nog een pak sneller kan...
https://github.com/JeroenGar/advent_of_code_2022/blob/main/src/day6.rs

[ Voor 11% gewijzigd door Jern_97 op 06-12-2022 11:03 ]

[Brilsmurfffje]

Uitleg van dag 6 was een beetje omslachtig, maar toen dit duidelijk was een simpele opdracht, het uitvoeren van part 2 was ook bijzonder simpele substitutie. Stilte voor de storm van morgen?

[Wraldpyk]

Ok dit was vreemd. Ik was helemaal voorbereid om een bericht te decoden voor stap 2, niet de code te hergebruiken voor deel 1.

https://github.com/Topene...blob/2022/day6/program.js

[Remcoder]

spoiler:

Voor deel 1 was ik inderdaad op de naieve toer gegaan, en gewoon de 4 chars eruit gepikt en vergeleken met een if statement.

Voor deel 2 moest ik die implementatie dus heroverwegen, 14 chars met elkaar vergelijken in een if statement wordt nogal een berg spaghetti...

Dus, we bouwen een CountingCollector

Gebruik ervan leidt dan tot deze oplossing