Verandert z'n sig te weinig.
ik merk bij dit soort gridpuzzels toch ook wel dat een simpele visualisatie waarbij elke cell dezelfde breedte als hoogte heeft enorm zou helpen. Diagonalen vind ik persoonlijk in ASCII art toch lastig te zien.FCA schreef op zondag 8 december 2024 @ 11:17:
[...]
Nee hoor, ik vond het ook onduidelijk geformuleerd. Pas na 3x lezen en vooral veel naar de voorbeelden staren had ik het door.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Volgens mij checkt 'ie daar correct op (maar ik kan me vergissen).mbe81 schreef op zondag 8 december 2024 @ 11:16:
Op basis van je beschrijving is je fout denk ik al een paar keer langsgekomen in dit topic:
spoiler:Op de richting waar je uitkomt kan all een blokkade staan en dan moet je nog een keer draaien.
Ik weet niet hoe ik C# code moet uitvoeren onder Linux, dus ik kan het niet checken, maar ik vermoed dat de fout in deze regel zit:Devilfish schreef op zondag 8 december 2024 @ 10:51:
Dus als je een voorbeeld kan vinden dat fout gaat, dan kan ik verder checken.
En een voorbeeld waar je vermoedelijk de mist in gaat:
#### ...# ^###
Claude: "Domain patterns emerge from iteration, not generation." - Tweakers Time Machine Extension | Chrome : FF
Vond die insinuatie over andermans antwoord jatten wel een beetje onsympathiek. Die had ik ook al een keer. Tja, als het aantal mogelijke antwoorden de 1000 niet overstijgt en je hebt heel wat variaties, dan is het vrij waarschijnlijk dat een foutje leidt tot een antwoord dat voor een ander goed was.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Devilfish schreef op zondag 8 december 2024 @ 10:51:
Ik kan wat hulp gebruiken bij dag 6, deel 2... Het voorbeeld gaat goed en kleine voorbeelden die ik kan bedenken ook, toch gaat de input fout...
spoiler: StappenplanLoop door de locaties uit deel 1
Als de volgende locatie vrij is (en niet al bezocht) zet daar dan een tijdelijk obstakel neer
Draai de guard naar rechts
Start de check op een loop
Code:
https://github.com/antonr.../tree/main/puzzles/2024/6
Dus als je een voorbeeld kan vinden dat fout gaat, dan kan ik verder checken.
There's no place like 127.0.0.1
Het lange verhaal: gisterochtend had ik al vrij snel een oplossing dat werkte op het voorbeeld, maar niet op mijn input. In de middag andere verplichtingen en pas in de avond er verder aangewerkt. Besloten om het deels opnieuw te schrijven en puur per toeval zag ik ineens negatieve getallen in mijn debug console regels voorbij flitsen. Daarna het probleem heel snel gevonden, opgelost en deel 2 gemaakt
Dag 8 zojuist ook opgelost. Uiteindelijk niet een hele moeilijk puzzel, al had ik wel wat moeite met Engels-begrijpend lezen. Gelukkig spraken de voorbeelden redelijk voor zich. Nu de code nog een beetje opruimen!
Dat is dus heel verschillend per dag, heb ik het idee. Dag 7 gaaf bij mij aan dat mijn antwoord te laag was!.oisyn schreef op zondag 8 december 2024 @ 12:09:
Het is ook wel irritant dat ze dan dus niet zeggen of het hoger of lager is. Dat vond ik altijd wel een handige hint
[ Voor 14% gewijzigd door Satom op 08-12-2024 12:50 ]
Daar zou 0 moeten uitkomen toch? Hoe zou je anders een loop moeten maken?Soultaker schreef op zondag 8 december 2024 @ 11:33:
[...]
Volgens mij checkt 'ie daar correct op (maar ik kan me vergissen).
[...]
Ik weet niet hoe ik C# code moet uitvoeren onder Linux, dus ik kan het niet checken, maar ik vermoed dat de fout in deze regel zit:
spoiler:foreach (var (coord, direction) in locations.GroupBy(t => t.coord).Select(t => (t.Key, t.Last().direction)))
En een voorbeeld waar je vermoedelijk de mist in gaat:
#### ...# ^###
Anyone who gets in between me and my morning coffee should be insecure.
Ik had hetzelfde gevoel. Ik had me al ingelezen in intcode voor het geval dat dat zou komen.Friits schreef op zondag 8 december 2024 @ 07:27:
[...]
Leuk puzzeltje, maar ik had inmiddels wel wat ingewikkelders verwacht!
When life gives you lemons, start a battery factory
Ah! Dom. Ik nam mijn beginpositie niet mee.ZpAz schreef op zondag 8 december 2024 @ 11:46:
Najaaa..
[Afbeelding]
spoiler:Wie van jullie had 1933
Claude: "Domain patterns emerge from iteration, not generation." - Tweakers Time Machine Extension | Chrome : FF
Nee, 2019 was een memorabel jaar. Ik had een hele mooie pure functionele implementatie in Haskell. Toen kwam dag 5 en kon ik ongeveer opnieuw beginnen
Dat klopt, en bij nader inzien krijg jij dat er waarschijnlijk ook uit want je had nog een extra check die ik over het hoofd had gezien. Het is lastig testcases te bedenken als ik je code in m'n hoofd moet uitvoeren.Devilfish schreef op zondag 8 december 2024 @ 14:31:
Daar zou 0 moeten uitkomen toch? Hoe zou je anders een loop moeten maken?
Wat krijg je op deze?
####### ##...## ##.#.## #...... ##^####
Correcte antwoord is 12 voor deel 1 en 7 voor deel 2 maar mijn gok is dat jij hier 6 vindt.
Dat is op zich wel knap.MueR schreef op zondag 8 december 2024 @ 14:40:
Grom, ik heb het juiste antwoord voor deel 2, maar mn tests op de sample falen met een off-by-one. Kan dit niet uitstaan.
Ik had een off-by-one in de sample van deel 1, maar dat was omdat mijn flatmap van sets een list op leverde en dan heb je geen ontdubbeling natuurlijk.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Pas vanavond kan ik de tijd pakken voor dag 8. Misschien daarna 6.2 eens een rewrite geven. De oplossing heb ik qua idee, nu alleen de uitwerking nog.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Ik heb het niet door mijn implementatie gehaald maar als ik dit zo eyeball dan kom ik op 5?Soultaker schreef op zondag 8 december 2024 @ 15:29:
[...]
Dat klopt, en bij nader inzien krijg jij dat er waarschijnlijk ook uit want je had nog een extra check die ik over het hoofd had gezien. Het is lastig testcases te bedenken als ik je code in m'n hoofd moet uitvoeren.
Wat krijg je op deze?
####### ##...## ##.#.## #...... ##^####
Correcte antwoord is 12 voor deel 1 en 7 voor deel 2 maar mijn gok is dat jij hier 6 vindt.
.edit: oh nee 7 idd, ik vergat de twee op het eind.
####### ##..1## ##.#2## #5.4367 ##^####
[ Voor 13% gewijzigd door .oisyn op 08-12-2024 15:51 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
[ Voor 97% gewijzigd door Bolukan op 08-12-2024 15:54 ]
Had iemand anders daar ook moeite mee?
Had ik ook, en bleek dat ik deze vergeten was:MueR schreef op zondag 8 december 2024 @ 14:40:
Grom, ik heb het juiste antwoord voor deel 2, maar mn tests op de sample falen met een off-by-one. Kan dit niet uitstaan.
The original example now has 34 antinodes, including the antinodes that appear on every antenna:
Dat zette me op het goede antwoordSoultaker schreef op zondag 8 december 2024 @ 15:29:
[...]
Dat klopt, en bij nader inzien krijg jij dat er waarschijnlijk ook uit want je had nog een extra check die ik over het hoofd had gezien. Het is lastig testcases te bedenken als ik je code in m'n hoofd moet uitvoeren.
Wat krijg je op deze?
####### ##...## ##.#.## #...... ##^####
Correcte antwoord is 12 voor deel 1 en 7 voor deel 2 maar mijn gok is dat jij hier 6 vindt.
Hiermee zag ik een off by one error die mijn oplossing fixte.Soultaker schreef op zondag 8 december 2024 @ 15:29:
[...]
Dat klopt, en bij nader inzien krijg jij dat er waarschijnlijk ook uit want je had nog een extra check die ik over het hoofd had gezien. Het is lastig testcases te bedenken als ik je code in m'n hoofd moet uitvoeren.
Wat krijg je op deze?
####### ##...## ##.#.## #...... ##^####
Correcte antwoord is 12 voor deel 1 en 7 voor deel 2 maar mijn gok is dat jij hier 6 vindt.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Klinkt als een andere bug dan Devilfish had, maar fijn om te horen dat het voorbeeld twee mensen geholpen heeftCreepy schreef op zondag 8 december 2024 @ 18:09:
[...]
Hiermee zag ik een off by one error die mijn oplossing fixte.spoiler:Ik knalde al een loop uit omdat de volgende stap invalid zou zijn maar maarmee vergat ik de laatste stap in de lijst op te nemen die ik moest afgaan voor het plaatsen van een obstacle.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
[dag 3] Mijn naïeve oplossing (met regexes) had ~3 minuten nodig voor @Soultaker's challenge 2, omdat de standaard regexp Go-library alleen werkt op data in geheugen, dus moest ik eerst de hele file inlezen. Nu herschreven met een 'bufio.Scanner', die de file splitst op ')': https://github.com/gerard...b/main/cmd/day03b/main.go, wat resulteert in:Soultaker schreef op dinsdag 3 december 2024 @ 17:21:
Okee, ik was van plan geen grote invoer te posten vandaag, aangezien alle algoritmen waarschijnlijk O(n) zijn, maar aangezien diverse mensen aan het benchmarken zijn doe ik het toch maar: aoc-2024-day-03-challenge-1-and-2.zip
Referentie-oplossingen in Python:
$ time pypy3 ../03.py < aoc-2024-day-03-challenge-1.txt ...57200 ...81743 real 0m0.456s user 0m0.408s sys 0m0.046s $ time pypy3 ../03.py < aoc-2024-day-03-challenge-2.txt ...33600 ...57973 real 0m15.961s user 0m15.042s sys 0m0.872s
(Antwoorden passen in 48-bits integers.)
Verder vraag ik me ook af hoe andere mensen parsen. @Mugwump had al opgemerkt dat je je eigenlijk moet beperken tot vermenigvuldigingen met getallen van 3 cijfers, maar dat is nog wel voor meerdere interpretaties vatbaar. Wat is jullie antwoord bijvoorbeeld voor de volgende invoer:
mul(010,010)mul(-1,2)mul(+2,3)mul(-123,4)mul(1234,5678)mul(१२३,४५६)
Ik kom op 100 maar ik denk dat sommigen iets anders berekenen, of ronduit crashen.
$ time go run cmd/day03b/main.go -i cmd/day03b/aoc-2024-day-03-challenge-2.txt ...33600 ...57973 real 0m7,171s user 0m6,950s sys 0m0,409s
Het kan met een state machine wellicht nog sneller, maar ik ben hier blij mee; geleerd hoe zo'n Scanner werkt.
@Soultaker ik waardeer je challenges overigens zeer, optimaliseren tegen die challenges is leuk werk, en ik haal ook nog wel eens bugs uit mijn code, zelfs als mijn antwoord al is goedgekeurd
Morgen of overmorgen maar weer eens met een helder hoofd kijken
[ Voor 20% gewijzigd door Woy op 08-12-2024 20:57 ]
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Weer niet de mooiste code, maar wel functioneel
https://github.com/rverst.../blob/main/Y2024/Day08.cs
[ Voor 26% gewijzigd door Woy op 08-12-2024 21:18 ]
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Bij 7/2 deed ik eerst alle || operators, daarna "de rest". Maar dat hoefde niet, dus hoefde enkel 1 case aan mijn switch statement toe te voegen ipv iets te verzinnen dat bepaalde operators prioriteit kregen. Wat het extra dom maakt is dat ik van te voren al dacht, oh, deel twee wordt vast een extra operator. Dus hier had ik al rekening mee gehouden.
[ Voor 23% gewijzigd door ZpAz op 08-12-2024 23:43 ]
Claude: "Domain patterns emerge from iteration, not generation." - Tweakers Time Machine Extension | Chrome : FF
Het komt voor part2 nooit voor dat gcd(delta.x, delta.y) > 1 tussen twee antennes.
Gemiste kansen imho.
[ Voor 9% gewijzigd door .oisyn op 09-12-2024 00:42 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
.oisyn schreef op maandag 9 december 2024 @ 00:28:
Ik vind dag 8 maar stom
spoiler:Volgens mij worden die expliciet uitgesloten:
This means that for any pair of antennas with the same frequency, there are two antinodes, one on either side of them.
Gemiste kansen imho.
Verandert z'n sig te weinig.
Robbinb1993 schreef op maandag 9 december 2024 @ 07:04:
spoiler: day9Met een segment tree is part 2 in O(N log N) tijd op te lossen. We kunnen dan het meest linker blok met genoeg vrije ruimte opvragen in log(N) tijd. En updaten is ook log(N) tijd voor de vrije ruimte die overblijft nadat het (deels) gevuld is.
Maar misschien wel interessant om te gaan testen
FCA schreef op maandag 9 december 2024 @ 07:41:
Deel 2 van dag 9 was een mooie. Heb er best even over gedaan voor een lelijke oplossing, nu eens kijken naar een mooie
spoiler:Houd een lijst bij met files en freespace, zoek de eerste ruim genoege freespace (nu nog lineaire search), en verplaats de file_start en file_end daarnaar. Daarna de freespace updaten: eerst weghalen waar geschreven is (ofwel kleiner, ofwel helemaal weg), daar bijvoegen waar de file eerst stond, en op die plek dan mergen. Oplossing is O(n^2) (n het aantal bestanden), maar draait in ong 12ms, dus niet eens al te slecht)
https://github.com/Robbinb1993/AoC24/blob/main/day9/day9.cc
[ Voor 43% gewijzigd door Robbinb1993 op 09-12-2024 09:08 ]
Marcj schreef op maandag 9 december 2024 @ 07:47:
spoiler: day9Wel interessant dat ik uiteindelijk 2 compleet losstaande implementatie heb gedaan. Ik zie ook niet zo snel hoe het eenvoudig anders kan.
En dan is hier nog mijn oplossing voor vandaag.
[ Voor 37% gewijzigd door Friits op 09-12-2024 10:20 ]
Op zich een goed idee, maar ik heb het net geprobeerd en dan wordt mijn code ongeveer 1000x langzamer voor deel 1. Ok, 225ms is nog steeds best vlot, maar toch voelt dat niet goed. Een gewoon echt geheugenblok werkt echt veel sneller (~250µs).Friits schreef op maandag 9 december 2024 @ 08:45:
[...]
spoiler:Als je in deel 2 oplost door te schuiven met geheugenblokken in een vorm als (data, size), kan je die die voor deel 1 vervangen door size blokken van (data, 1).
En dan is hier nog mijn oplossing voor vandaag.
En naar jouw code kijkend hebben we een echt heel verschillende filosofie over de code. Het is wel awesome om te zien hoe compact je code kan krijgen die de vraag representeert.
[ Voor 7% gewijzigd door Marcj op 09-12-2024 09:07 ]
Antwoorden en tijden:
$ time ./solve < aoc-2024-day-09-challenge-1.txt ...367295 ...407901 real 0m0.027s user 0m0.020s sys 0m0.007s $ time ./solve < aoc-2024-day-09-challenge-2.txt ...788479 ...018061 real 0m0.232s user 0m0.207s sys 0m0.024s $ time ./solve < aoc-2024-day-09-challenge-3.txt ...353327 ...224418 real 0m2.274s user 0m1.952s sys 0m0.316s
Overigens denk ik dat het nog sneller kan, maar ik moet dat idee nog even uitwerken. (Ik wilde alvast de data delen zodat anderen ermee kunnen testen.)
[ Voor 1% gewijzigd door Soultaker op 09-12-2024 10:04 . Reden: Antwoorden challenge 3 gefixed ]
https://github.com/Janoz-.../aoc/y2024/day9/Day9.java
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Het voorbeeld lukt en de echte input niet natuurlijk, zucht, en het is nogal moeilijk om te zoeken waar het nu net misgaat.
Net zoals zovelen was ik er op mezelf achtergekomen dat ipv + en *, je ook - en / kan gebruiken, recursie, en van rechts naar links alles afgaan.
Ik gebruik JS dus een BigInt (nodig vanaf ~2^53) gaat het probleem niet oplossen. Ook dat "1: 2 1" ding is het volgens mij niet.
Hierbij mijn tijden:Soultaker schreef op maandag 9 december 2024 @ 09:11:
Extra grote invoer voor dag 9: aoc-2024-day-09-challenge-1-to-3.zip
Antwoorden en tijden:
$ time ./solve < aoc-2024-day-09-challenge-1.txt ...367295 ...407901 real 0m0.027s user 0m0.020s sys 0m0.007s $ time ./solve < aoc-2024-day-09-challenge-2.txt ...788479 ...018061 real 0m0.232s user 0m0.207s sys 0m0.024s $ time ./solve < aoc-2024-day-09-challenge-3.txt ...633839 ...504930 real 0m2.274s user 0m1.952s sys 0m0.316s
Overigens denk ik dat het nog sneller kan, maar ik moet dat idee nog even uitwerken. (Ik wilde alvast de data delen zodat anderen ermee kunnen testen.)
aoc-2024-day-09-challenge-1.txt: 8 ms, antwoorden: (....367295, ...407901).
aoc-2024-day-09-challenge-2.txt: 82ms, antwoorden: (....788479, ...018061).
aoc-2024-day-09-challenge-3.txt: 848 ms, antwoorden: (....353327, ...224418).
Hierbij heb ik mijn bovenstaande antwoord nog iets verder geoptimaliseerd door in plaats van een recursieve segment tree een iteratieve segment tree te gebruiken.
Part 1 doe ik in O(N) met two-pointer technique.
[ Voor 21% gewijzigd door Robbinb1993 op 09-12-2024 11:36 ]
Wanneer je die oplossingsrichting gebruikt moet je even goed opletten hoe je de situaties voor x/0 en 0/0 afhandeltRangedNeedles schreef op maandag 9 december 2024 @ 09:37:
I know I'm late to the party, maar heeft iemand nog een simpel voorbeeldje voor dag 7, waarbij je + en * tussen getallen moet gooien om het geheel te laten kloppen?
Het voorbeeld lukt en de echte input niet natuurlijk, zucht, en het is nogal moeilijk om te zoeken waar het nu net misgaat.
Net zoals zovelen was ik er op mezelf achtergekomen dat ipv + en *, je ook - en / kan gebruiken, recursie, en van rechts naar links alles afgaan.
Ik gebruik JS dus een BigInt (nodig vanaf ~2^53) gaat het probleem niet oplossen. Ook dat "1: 2 1" ding is het volgens mij niet.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Als je (een deel van) je input kunt delen dan kan ik wel aangeven welke regels wel en welke niet kunnenRangedNeedles schreef op maandag 9 december 2024 @ 09:37:
I know I'm late to the party, maar heeft iemand nog een simpel voorbeeldje voor dag 7, waarbij je + en * tussen getallen moet gooien om het geheel te laten kloppen?
Het voorbeeld lukt en de echte input niet natuurlijk, zucht, en het is nogal moeilijk om te zoeken waar het nu net misgaat.
Net zoals zovelen was ik er op mezelf achtergekomen dat ipv + en *, je ook - en / kan gebruiken, recursie, en van rechts naar links alles afgaan.
Ik gebruik JS dus een BigInt (nodig vanaf ~2^53) gaat het probleem niet oplossen. Ook dat "1: 2 1" ding is het volgens mij niet.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Damn, mijn aanname dat mijn oplossing misschien wel O(n^2) is, maar wel redelijk zou performen is bij deze wel ontkracht. De tweede input doet er al 30 seconden overSoultaker schreef op maandag 9 december 2024 @ 09:11:
Extra grote invoer voor dag 9: aoc-2024-day-09-challenge-1-to-3.zip
Antwoorden en tijden:
$ time ./solve < aoc-2024-day-09-challenge-1.txt ...367295 ...407901 real 0m0.027s user 0m0.020s sys 0m0.007s $ time ./solve < aoc-2024-day-09-challenge-2.txt ...788479 ...018061 real 0m0.232s user 0m0.207s sys 0m0.024s $ time ./solve < aoc-2024-day-09-challenge-3.txt ...633839 ...504930 real 0m2.274s user 0m1.952s sys 0m0.316s
Overigens denk ik dat het nog sneller kan, maar ik moet dat idee nog even uitwerken. (Ik wilde alvast de data delen zodat anderen ermee kunnen testen.)
Nou ja, een goed excuus om toch eens in de segment trees te duiken!
Cool, thanks! Dan kan ik inderdaad één lijn eruit halen en specifiek kijken hoe of wat..oisyn schreef op maandag 9 december 2024 @ 09:43:
[...]
Als je (een deel van) je input kunt delen dan kan ik wel aangeven welke regels wel en welke niet kunnen
Hier is m'n input (via Pastebin):
Die check had ik er nog niet in staan (Janoz schreef op maandag 9 december 2024 @ 09:43:
[...]
Wanneer je die oplossingsrichting gebruikt moet je even goed opletten hoe je de situaties voor x/0 en 0/0 afhandelt
Draait nog binnen 200ms, dus meer dan tevreden.
[ Voor 6% gewijzigd door Gropah op 09-12-2024 10:08 ]
Oh crap, je hebt gelijk. Ik heb de referentie-antwoorden daarop aangepast.Robbinb1993 schreef op maandag 9 december 2024 @ 09:39:
En de antwoorden passen niet in 64 bit, dus ik gebruik nu 128 bit voor de antwoorden.
Heel netjes! (Ik neem aan dat je antwoorden bij deel 3 nog met 64 bits waren.)Robbinb1993 schreef op maandag 9 december 2024 @ 09:39:
Hierbij mijn tijden:
aoc-2024-day-09-challenge-1.txt: 8 ms, antwoorden: (....367295, ...407901).
aoc-2024-day-09-challenge-2.txt: 82ms, antwoorden: (....788479, ...018061).
aoc-2024-day-09-challenge-3.txt: 848 ms, antwoorden: (....633839, ...504930).
Dat heb ik ook zo gedaan. Part 2 doe ik momenteel iets anders dan jij:Part 1 doe ik in O(N) met two-pointer technique.
[ Voor 6% gewijzigd door Soultaker op 09-12-2024 10:15 ]
Soultaker schreef op maandag 9 december 2024 @ 10:11:
[...]
Oh crap, je hebt gelijk. Ik heb de referentie-antwoorden daarop aangepast.
[...]
Heel netjes! (Ik neem aan dat je antwoorden bij deel 3 nog met 64 bits waren.)
Hierbij heb ik mijn bovenstaande antwoord nog iets verder geoptimaliseerd door in plaats van een recursieve segment tree een iteratieve segment tree te gebruiken.
[...]
Dat heb ik ook zo gedaan. Part 2 doe ik momenteel iets anders dan jij:
spoiler:Ik maak gebruik van het feit dat groottes maximaal 9 zijn. Dus sla ik de lege ruimtes op in 10 sorted sets, 1 per grootte. Dan kan ik voor een bestand met grootte s de meest linker ruimte vinden door de sets voor grootte s t/m 9 te checken. De overgebleven ruimte gooi ik dan in de overgebleven set. Dat is technisch ook O(log n).
Hierbij mijn code op basis van jouw O(N log N) oplossing: https://github.com/Robbin.../blob/main/day9/day9_2.cc. Daarmee haal ik 1639ms op test case 3.
[ Voor 8% gewijzigd door Robbinb1993 op 09-12-2024 10:36 ]
Ja dit was ook mijn oplossing, alleen was ik nog wat tijd kwijt met een lullig bugje dat niet in de testoutput opviel.Gropah schreef op maandag 9 december 2024 @ 10:07:
Ik ben oprecht lui geweest vandaag, maar is ook omdat ik wat opstart problemen had. Schijnbaar vind intellij het niet zo leuk als een project maven er later ingefietsts krijgt via git. Code werd niet goed geupdate, oude code draaide, de linter/aanvul ging helemaal de mist in. Heeft mij te veel tijd gekost, en omdat ik het allemaal voor werk af probeer te hebben daarom echt heel lui gedaan
spoiler:Achteraan beginnen met zoeken naar een groep, de grootte bepalen, en dan van voor af aan beginnen te zoeken naar een plek. Nog iets te veel tijd kwijt geweest aan welke idx nou welke kant op loopt, maar meh.
Draait nog binnen 200ms, dus meer dan tevreden.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
https://gist.github.com/o...14049501c315552fde4184521RangedNeedles schreef op maandag 9 december 2024 @ 10:00:
[...]
Cool, thanks! Dan kan ik inderdaad één lijn eruit halen en specifiek kijken hoe of wat.
Hier is m'n input (via Pastebin):
***members only***
[...]
Die check had ik er nog niet in staan () maar verandert eig niets aan het eindresultaat.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik kan het nog verder optimaliseren metRobbinb1993 schreef op maandag 9 december 2024 @ 10:15:
spoiler:Dat is inderdaad een goede observatie, er zijn maar maximaal 9 groottes, dus je hoeft maar maximaal 9x te binary searchen per file block, en 1 removal en update van een free block size (ook O(log N)). Dit komt ook op O(11 * log N) = O(log N) per file block. De segment tree komt pas echt van pas als de lege ruimtes variabel kunnen zijn (> 9). Hij heeft wellicht een iets lagere constante factor nu.
Dat is voor dit probleem ook sneller: (C++ code)
$ time ./solve < aoc-2024-day-09-challenge-3.txt Reading input took 11ms Solving part 1 took 256ms ...353327 Solving part 2 took 335ms ...224418 real 0m0.608s user 0m0.456s sys 0m0.150s
Als er grotere gaten tussen bestanden mogelijk waren wordt jouw aanpak op een gegeven moment wel sneller natuurlijk.
[ Voor 4% gewijzigd door Soultaker op 09-12-2024 10:49 . Reden: Link naar code toegevoegd; timing nog wat aangescherpt. ]
Soultaker schreef op maandag 9 december 2024 @ 10:36:
[...]
Ik kan het nog verder optimaliseren met
spoiler:een std::priority_queue<> in plaats van een std::set<>. Dan is het per file 9× een O(1) operatie, en max. 1x een O(log n) operatie.
Dat is voor dit probleem ook sneller:
% time ./solve < aoc-2024-day-09-challenge-3.txt Reading input took 11ms Solving part 1 took 240ms ...353327 Solving part 2 took 537ms ...224418 real 0m0.795s user 0m0.579s sys 0m0.213s
Als er grotere gaten tussen bestanden mogelijk waren wordt jouw aanpak op een gegeven moment wel sneller natuurlijk.
Edit: met een priority_queue is de tijd op mijn PC voor test case 3 nog maar 668 ms, sneller dan de segment tree.
Nog terugkomend op mijn stelling dat 64 bit niet genoeg zou zijn, er zat nog een foutje in mijn code. Het is wel genoeg, ik miste de conversie naar (long long) hier: ans += (long long)i * fileSystem[i], waardoor ik een overflow probleem had. Nu kom ik voor test case 3 wel op de antwoorden uit die je initieel had.
[ Voor 19% gewijzigd door Robbinb1993 op 09-12-2024 10:56 ]
Mugwump schreef op maandag 9 december 2024 @ 10:16:
[...]
Ja dit was ook mijn oplossing, alleen was ik nog wat tijd kwijt met een lullig bugje dat niet in de testoutput opviel.
spoiler:Je moet natuurlijk wel even checken of de eerste free space links van de huidige file ligt
[ Voor 14% gewijzigd door Gropah op 09-12-2024 10:57 ]
Nee, je had eerst gelijk, het is niet genoeg, en mijn oorspronkelijke antwoorden waren verkeerd (vandaar ook dat m'n 128-bit oplossing andere antwoorden vindt op de derde challenge, maar niet op de andere).Robbinb1993 schreef op maandag 9 december 2024 @ 10:38:
Nog terugkomend op mijn stelling dat 64 bit niet genoeg zou zijn, er zat nog een foutje in mijn code. Het is wel genoeg, ik miste de conversie naar (long long) hier: ans += (long long)i * fileSystem[i], waardoor ik een overflow probleem had. Nu kom ik voor test case 3 wel op de antwoorden uit die je initieel had.
De individuele producten passen wel in een 64-bit integer maar de som van de producten niet.
Je kunt het ook berekenen. Als je aanneemt dat alle bestanden minstens grootte 1 hebben (wat zo is in de officiële invoer en in mijn testinvoer) dan is het minimumantwoord voor een invoer van n karakters exact de som van i2 voor i van 1 t/m n/2, oftewel n×(n + 1)×(n + 2)/24 > n3 / 24. Dus de maximuminvoer die nog in een 64-bit signed integer past is ongeveer 6 MB.
edit:
Voor mensen die het willen oplossen zonder 64 of 128 bit integers: je kunt het probleem oplossen modulo 1000000 ofzo, dan vind je als je het goed gedaan hebt wel de laatste 6 cijfers die ik ook in de referentie-antwoorden gegeven heb.
[ Voor 11% gewijzigd door Soultaker op 09-12-2024 11:26 ]
Je hebt inderdaad gelijk. Reverted naar 128 bit en nu kom ik ook weer op deze antwoorden uit. Nu zou de code volledig correct moeten zijn. Normaal gesproken is een negatief getal in een van de antwoorden genoeg indicatie, maar dat was in dit geval niet zo. Misschien volgende keer tijdelijk een assert tijdens het opsommen toepassen.Soultaker schreef op maandag 9 december 2024 @ 11:19:
[...]
Nee, je had eerst gelijk, het is niet genoeg, en mijn oorspronkelijke antwoorden waren verkeerd (vandaar ook dat m'n 128-bit oplossing andere antwoorden vindt op de derde challenge, maar niet op de andere).
De individuele producten passen wel in een 64-bit integer maar de som van de producten niet.
Je kunt het ook berekenen. Als je aanneemt dat alle bestanden minstens grootte 1 hebben (wat zo is in de officiële invoer en in mijn testinvoer) dan is het minimumantwoord voor een invoer van n karakters exact de som van i2 voor i van 1 t/m n/2, oftewel n×(n + 1)×(n + 2)/24 > n3 / 24. Dus de maximuminvoer die nog in een 64-bit signed integer past is ongeveer 6 MB.
edit:
Voor mensen die het willen oplossen zonder 64 of 128 bit integers: je kunt het probleem oplossen modulo 1000000 ofzo, dan vind je als je het goed gedaan hebt wel de laatste 6 cijfers die ik ook in de referentie-antwoorden gegeven heb.
[ Voor 7% gewijzigd door Robbinb1993 op 09-12-2024 11:36 ]
Met de ideeen van hierbovenSoultaker schreef op maandag 9 december 2024 @ 09:11:
Extra grote invoer voor dag 9: aoc-2024-day-09-challenge-1-to-3.zip
Antwoorden en tijden:
$ time ./solve < aoc-2024-day-09-challenge-1.txt ...367295 ...407901 real 0m0.027s user 0m0.020s sys 0m0.007s $ time ./solve < aoc-2024-day-09-challenge-2.txt ...788479 ...018061 real 0m0.232s user 0m0.207s sys 0m0.024s $ time ./solve < aoc-2024-day-09-challenge-3.txt ...353327 ...224418 real 0m2.274s user 0m1.952s sys 0m0.316s
Overigens denk ik dat het nog sneller kan, maar ik moet dat idee nog even uitwerken. (Ik wilde alvast de data delen zodat anderen ermee kunnen testen.)
Challenge 1:
Parsing: 312.4µs
Day 9 - Part 1 : ...367295
generator: 3.5µs,
runner: 4.254ms
Parsing: 117.5µs
Day 9 - Part 2 : ...407901
generator: 400ns,
runner: 4.5748ms
Challenge 2:
Parsing: 2.0118ms
Day 9 - Part 1 : ...788479
generator: 3.9µs,
runner: 47.4666ms
Parsing: 1.8632ms
Day 9 - Part 2 : ...018061
generator: 500ns,
runner: 65.2383ms
Challenge 3:
Parsing: 18.6652ms
Day 9 - Part 1 : ...353327
generator: 4.6µs,
runner: 436.6069ms
Parsing: 18.7253ms
Day 9 - Part 2 : ...224418
generator: 400ns,
runner: 790.7901ms
Hiermee win ik het dus niet van de geoptimaliseerde C++ oplossingen, maar goed genoeg zou ik zeggen. Sowieso is er misschien meer tijdswinst te behalen in deel 1.
Verandert z'n sig te weinig.
Voor deel 2 had ik initieel teveel geïmplementeerd...(zie spoiler), maar uiteindelijk heb ik nu een oplossing die in ongeveer 200 ms de oplossing vindt. Ik kon overigens ook niets van mijn oplossing van deel 1 hergebruiken voor deel 2.
https://github.com/realma...de.Y2024/Solvers/Day09.cs
There's no place like 127.0.0.1
Ha, dat had ik eerst ook gedaan voor deel 2. Gelukkig niet al teveel tijd aan besteed, maar kost zo weer 5 minuten (als het al niet meer was).MatHack schreef op maandag 9 december 2024 @ 13:29:
Voor deel 2 had ik initieel teveel geïmplementeerd...(zie spoiler), maar uiteindelijk heb ik nu een oplossing die in ongeveer 200 ms de oplossing vindt. Ik kon overigens ook niets van mijn oplossing van deel 1 hergebruiken voor deel 2.![]()
spoiler: dag 9, deel 2Ik had ook gebouwd dat de vrije ruimte die beschikbaar kwam vanaf de bron van de verplaatsing keurig berekend (evt. samengevoegd met andere vrije ruimte daar), maar dat is natuurlijk niet nodig, want je volgende check is altijd links daarvan
https://github.com/realma...de.Y2024/Solvers/Day09.cs
Verandert z'n sig te weinig.
Volgens mij heb ik een simpelere en hele effectieve manier gevonden om de boel te versnellen. En aan de cijfers te zien is deze ook echt wel linear in complexiteit.Marcj schreef op maandag 9 december 2024 @ 09:46:
[...]
Damn, mijn aanname dat mijn oplossing misschien wel O(n^2) is, maar wel redelijk zou performen is bij deze wel ontkracht. De tweede input doet er al 30 seconden over
Nou ja, een goed excuus om toch eens in de segment trees te duiken!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| $ day9 < big_inputs/aoc-2024-day-09-challenge-1.txt Executing ├── Input parsed in 92µs ├── Part 1 calculated in 2,718µs: ...67295 ├── Part 2 calculated in 1,443µs: ...07901 └── Total time: 4,282µs $ day9 < big_inputs/aoc-2024-day-09-challenge-2.txt Executing ├── Input parsed in 934µs ├── Part 1 calculated in 30,395µs: ...88479 ├── Part 2 calculated in 12,961µs: ...18061 └── Total time: 44,338µs $ day9 < big_inputs/aoc-2024-day-09-challenge-3.txt Executing ├── Input parsed in 7,657µs ├── Part 1 calculated in 218,958µs: ...53327 ├── Part 2 calculated in 114,934µs: ...24418 └── Total time: 341,610µs |
edit: Nog een paar kleine aanpassing, minder geheugengebruik betekent ook meer snelheid!
[ Voor 7% gewijzigd door Marcj op 09-12-2024 15:36 ]
Marcj schreef op maandag 9 december 2024 @ 15:14:
[...]
Volgens mij heb ik een simpelere en hele effectieve manier gevonden om de boel te versnellen:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 $ day9 < big_inputs/aoc-2024-day-09-challenge-1.txt Executing ├── Input parsed in 1,190µs ├── Part 1 calculated in 2,159µs: ...67295 ├── Part 2 calculated in 2,234µs: ...07901 └── Total time: 5,595µs $ day9 < big_inputs/aoc-2024-day-09-challenge-2.txt Executing ├── Input parsed in 2,628µs ├── Part 1 calculated in 33,916µs: ...88479 ├── Part 2 calculated in 13,827µs: ...18061 └── Total time: 50,438µs $ day9 < big_inputs/aoc-2024-day-09-challenge-3.txt Executing ├── Input parsed in 9,647µs ├── Part 1 calculated in 222,829µs: ...53327 ├── Part 2 calculated in 134,890µs: ...24418 └── Total time: 367,445µs
spoiler:Ik houd nu een lijst bij waar de vorige keer we een plek vonden van tenminste deze grootte. De volgende keer begin ik daar met zoeken. Dit is heel simpel bij te houden, bij te werken en blijkbaar erg effectief!
Robbinb1993 schreef op maandag 9 december 2024 @ 15:38:
[...]
spoiler:Mooie tijd. Ik neem aan dat de index ook weer lager kan worden worden, als er een restant is van een deels opgevuld leeg block met een lagere index dan opgeslagen?
Marcj schreef op maandag 9 december 2024 @ 15:40:
[...]
spoiler:Nee, de index wordt nooit lager. De lege ruimte wordt namelijk alleen maar kleiner en ik verwijder lege blokken helemaal niet. Ik laat lege ruimte met size 0 gewoon staan. Dat maakt het verwerken veel simpeler ten koste van een beetje extra geheugen.
Robbinb1993 schreef op maandag 9 december 2024 @ 15:43:
[...]
spoiler:Oja inderdaad! Want je slaat een 'ten minste' van deze grootte op en niet exact die grootte, waardoor de index die opgeslagen is niet groter kan zijn dan de positie van het restant. Als ik het goed heb, is de complexiteit dan O(N)?
Nice! Ik moet even kijken wat je precies doet.Marcj schreef op maandag 9 december 2024 @ 15:14:
Volgens mij heb ik een simpelere en hele effectieve manier gevonden om de boel te versnellen. En aan de cijfers te zien is deze ook echt wel linear in complexiteit.
Ik heb ondertussen mijn C++ oplossing ook geoptimaliseerd tot O(n) voor deel 1 en O(nm) voor deel 2 (waarbij m de maximale lengte van een bestand/gat is; m=9 voor dit probleem, dus theoretisch is dat ook O(n) is). Het lijkt zelfs iets sneller te zijn dan jouw oplossing:
$ time ./solve2 < aoc-2024-day-09-challenge-3.txt Reading input took 11ms Preprocessing took 25ms Solving part 1 took 35ms ...353327 Solving part 2 took 120ms ...224418 real 0m0.198s user 0m0.141s sys 0m0.056s
Het idee hierachter is om m'n vorige aanpak om te keren:
C++ code (overigens bevat dit ook een voorbeeld van hoe je het antwoord correct kunt berekenen zonder 128-bits integer datatype te gebruiken).
Ik vond dit een erg leuk probleem, aangezien er een heleboel niet-triviale manieren zijn om het te optimaliseren! Ik denk dat dat we nu al een stuk of zes hebben gezien: brute force simuleren (wat ik vanochtend gedaan had), de segment tree van @Robbinb1993, ik had eerst sorted sets en daarna binary heaps, jij hebt nu iets linears blijkbaar, en ik heb weer een andere (bijna) lineaire aanpak.
Leuk. Bedankt voor de extra uitdaging! Ik moest inderdaad met BigIntegers aan de slag voor de juiste antwoorden, heb ik niet meegecommit:Soultaker schreef op maandag 9 december 2024 @ 09:11:
Extra grote invoer voor dag 9: aoc-2024-day-09-challenge-1-to-3.zip
A1: 0.099s
A2: 0.140s
B1: 0.550s
B2: 0.698s
C1: 3.896s
C2: 6.591s
Alle tijden met JUnit gemeten, inclusief parsen etc.
Day 9 in Java.
Siditamentis astuentis pactum.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Mijn antwoord is iig te hoog.
Heeft iemand anders een set voor me inclusief de uiteindelijke offsets van de files? (deel 2 dus)
.edit: oooh ik zie het al. Een file moet niet naar de kleinste span waar hij past (met offset als tiebreaker), hij moet naar de laagste span waar hij past
[ Voor 24% gewijzigd door .oisyn op 09-12-2024 21:27 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat probleem had ik ook eerst..oisyn schreef op maandag 9 december 2024 @ 21:20:
Hmz, 9.2, goede antwoord voor het voorbeeld, maar niet voor mijn daadwerkelijke input. En die is teringgroot dus ga het dan maar even zoeken
Mijn antwoord is iig te hoog.
Heeft iemand anders een set voor me inclusief de uiteindelijke offsets van de uiteindelijke files? (deel 2 dus)
Trouwens nog mijn implementatie wat geupdate, draait nu ook lineair (volgens aanpak van Soultaker).
Wat me trouwens opviel is voor Rust dat het flink uitmaakt als je je vectoren met een goede capaciteit initialiseert. kan zomaar 50% schelen.
Deel 1 ook wat geoptimaliseerd, bereken nu de checksum direct, maak geen nieuwe vector meer aan met de "gefragmenteerde" bestanden.
Challenge 3:
Parsing: 18.4477ms
Day 9 - Part 1 : ...21353327
generator: 1.4µs,
runner: 243.2311ms
Parsing: 18.656ms
Day 9 - Part 2 - faster :...4224418
generator: 700ns,
runner: 157.2422ms
Verandert z'n sig te weinig.
ps. Ik heb wel wat pre-calculatie in de parser nu zitten, omdat de data tussen de deel 1 en deel 2 wordt gedeeld.
1
2
3
4
5
| Executing ├── Input parsed in 34,011µs ├── Part 1 calculated in 115,150µs: ...53327 ├── Part 2 calculated in 105,329µs: ...24418 └── Total time: 254,589µs |
Nu heb ik nog meer ideeen door wat iedereen hier deelt, maar misschien is op tjid naar bed een beter idee
Godver.oisyn schreef op maandag 9 december 2024 @ 21:20:
.edit: oooh ik zie het al. Een file moet niet naar de kleinste span waar hij past (met offset als tiebreaker), hij moet naar de laagste span waar hij past
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Jouw omschrijving klinkt wel goed, dus er zal nog ergens een bug in zitten. Steeds de laatste file in de eerste ruimte zetten waar hij past. Let je op dat er daarna nog ruimte over kan zijn?.oisyn schreef op maandag 9 december 2024 @ 22:02:
[...]
Godver. Code omgeschreven, nog steeds het goede antwoord voor het voorbeeld, nog steeds het verkeerde voor mijn input.
Ja, en ook dat hij niet naar een grotere offset moet verplaatsen zoals @FCA ook al opmerkte.Marcj schreef op maandag 9 december 2024 @ 22:03:
[...]
Jouw omschrijving klinkt wel goed, dus er zal nog ergens een bug in zitten. Steeds de laatste file in de eerste ruimte zetten waar hij past. Let je op dat er daarna nog ruimte over kan zijn?
.edit: oh ik zie het al. Denkfout in mijn datastructuur.
.edi2: ok maar even dom gebruteforced voor het juiste antwoord. Morgen maar iets beters bedenken
[ Voor 15% gewijzigd door .oisyn op 09-12-2024 22:31 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik was in de veronderstelling dat je voor deel 2
Uiteindelijk heb ik het opgelost door gewoon links te beginnen en op elke gat kijken of er eentje van zover mogelijk rechts past.(2)
Gevoelsmatig zou de eerste oplossing, (1), de juiste moeten zijn en heb ik met oplossing (2) geluk dat het op mijn input werkt. Maar hoogstwaarschijnlijk heb ik het geheel niet goed gelezen
Ik vermoed dat je bij (1) een van de twee volgende dingen hebt gemist:Satom schreef op maandag 9 december 2024 @ 22:50:
Dag 9, deel 2 op de valreep voor het slapen gaan toch opgelost. Mijn eerste oplossing was fout, de rewrite was wel goed.
Ik was in de veronderstelling dat je voor deel 2spoiler:helemaal rechts moest beginnen en dan kijken waar die zover mogelijk links zou passen.(1)
Uiteindelijk heb ik het opgelost door gewoon links te beginnen en op elke gat kijken of er eentje van zover mogelijk rechts past.(2)
Gevoelsmatig zou de eerste oplossing, (1), de juiste moeten zijn en heb ik met oplossing (2) geluk dat het op mijn input werkt. Maar hoogstwaarschijnlijk heb ik het geheel niet goed gelezen
2. Er kan ruimte overblijven als je een kleiner block in een grotere ruimte stopt, deze overgebleven ruimte kan ook weer gevuld worden.
There's no place like 127.0.0.1
Tijden voor @Soultaker's set zijn resp. 1551.5µs, 17615.3µs en 169262.8µs. Ik krijg alleen wel andere antwoorden voor 1-part1, 3-part1 en 3-part2
En hoewel ik nog u64's gebruik, het is wel Rust, dus hij zou moeten panicken bij een overflow, en dat doet ie niet.
.edit: maar het gebruik van u128 maakt wel dat challenge 3 part 2 klopt. Ik heb dus alleen een fout in mijn part1 voor challenge 1 en 3.
.edit2: gevonden
Challenge 1:
Time spent: 1550.1µs
...367295 - ...407901
Challenge 2:
Time spent: 16976.5µs
...788479 - ...018061
Challenge 3:
Time spent: 172455.1µs
...353327 - ...224418
En nu naar bed
[ Voor 25% gewijzigd door .oisyn op 10-12-2024 00:45 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
in Rust kun je ook vec's in een HashSet gooien, terwijl je in Python er geen list's in kunt stoppen. Was super simpel voor deel 2 dus (ook vanwege de super beperkte grootte). Had wel verwacht dat ik voor deel 2 een iets geavanceerder routeplanner algoritme moest gebruiken dan een simpele DFS, maar nee dus.
Verandert z'n sig te weinig.
Een standaardprobleem inderdaad. Simpel voor degenen die het kennen, waarschijnlijk lastiger als je geen informatica-opleiding hebt gedaan. Dit is het onderscheid wat Trasos ook noemde.FCA schreef op dinsdag 10 december 2024 @ 06:35:
Vandaag voelde te simpel voor een dag 10 (of ik ben inmiddels te geoefend in dit soort puzzeltje?)
(Dit deel lijkt me niet echt een spoiler.) In Python kun je tuples gebruiken, dat zijn in essentie immutable lists.in Rust kun je ook vec's in een HashSet gooien, terwijl je in Python er geen list's in kunt stoppen.
Je oplossing voor deel 2 veel te ingewikkeld trouwens.
Het is letterlijk 1 regel in Python (als je deel 1 al geïmplementeerd hebt).
Precies hetzelfde hier. En gelukkig had ik mijn foute deel 1 gecommend en gekopieerd om op te lossen, dus deel 2 was alleen wat comments weghalen (en een beetje make-up).bakkerjangert schreef op dinsdag 10 december 2024 @ 06:41:
Lol, ik had deel 1 niet heel goed gelezen en het antwoord op deel 2 berekend. Leuke puzzel, maar niet steeds niet al te pittig.
Ik had EXACT hetzelfdebakkerjangert schreef op dinsdag 10 december 2024 @ 06:41:
Lol, ik had deel 1 niet heel goed gelezen en het antwoord op deel 2 berekend. Leuke puzzel, maar niet steeds niet al te pittig.
Toen ik door had dat ik het fout gedaan had, had ik al wel een vermoeden dat het deel 2 zou worden dus heb mijn deel 1 implementatie er naast gemaakt.
https://github.com/Janoz-...oc/y2024/day10/Day10.java
[ Voor 56% gewijzigd door Janoz op 10-12-2024 07:27 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
En ik heb niet eens informatica gestudeerdSoultaker schreef op dinsdag 10 december 2024 @ 07:00:
[...]
Een standaardprobleem inderdaad. Simpel voor degenen die het kennen, waarschijnlijk lastiger als je geen informatica-opleiding hebt gedaan. Dit is het onderscheid wat Trasos ook noemde.
Haha, ja, je hebt gelijk. Merk dat ik onbewust nogal defensief programmeer bij AoC, om niet tegen onvoorziene edge cases aan te lopen, maar met de aanpak die ik hier had gekozen was dat allemaal niet nodig geweest.(Dit deel lijkt me niet echt een spoiler.) In Python kun je tuples gebruiken, dat zijn in essentie immutable lists.
Je oplossing voor deel 2 veel te ingewikkeld trouwens.
spoiler:Je hoeft helemaal geen trails bij te houden, ze zijn automatisch verschillend. Je kunt die hele `trails` variabele deleten en in plaats van trails.insert(new_trail); direct output++ doen, en je hoeft de trail ook niet in `todo` op te slaan, alleen je laatste positie.
Het is letterlijk 1 regel in Python (als je deel 1 al geïmplementeerd hebt).
Ik zat trouwens nog te denken, het had allemaal veel interessanter gekund voor deel 2: (bijna-)distincte round-trips bijvoorbeeld, of paden waar je beperkt naar beneden kunt, of... veel mogelijkheden die een iets slimmere aanpak vereisen. Ik moest erg denken aan dag 23 van vorig jaar , maar dat was natuurlijk een goede voor dag 23, niet iets voor dag 10.
Verandert z'n sig te weinig.
Janoz schreef op dinsdag 10 december 2024 @ 07:10:
[...]
Ik had EXACT hetzelfde
Toen ik door had dat ik het fout gedaan had, had ik al wel een vermoeden dat het deel 2 zou worden dus heb mijn deel 1 implementatie er naast gemaakt.
spoiler:Zelf gewoon weer een mooie recursieve functie gebouwd. Gegeven een startpunt, dan is de raiting de som van de rating van alle buren die 1 stap hoger zijn. En als het startpunt 9 is, dan is de rating 1. Voor deel 1 hoefde ik dat alleen maar om te bouwen naar het teruggeven van de top en wat set magic. Aangezien een pad niet langer dan 10 kan zijn was ik niet heel bang voor een ontploffende callstack.
https://github.com/Janoz-...oc/y2024/day10/Day10.java
$ time pypy3 solve.py < aoc-2024-day-10-challenge-1.txt ...036 ...780 real 0m5.309s user 0m5.177s sys 0m0.084s
En eens dat het allemaal wel erg makkelijk was. Ik had ergens zo langzamerhand nog wel iets ingewikkelders verwacht met b.v. een optie om in een route 1 keer een stapje omlaag te mogen zetten ofzo.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
https://github.com/realma...de.Y2024/Solvers/Day10.cs
There's no place like 127.0.0.1
300ms voor de deel 2 in Kotlin op m'n macbook met M1 in een niet al te representatieve benchmark (lees: draaien vanuit een IDE).Soultaker schreef op dinsdag 10 december 2024 @ 08:18:
Qua extra data is er niet veel interessants te bedenken vandaag, maar voor wie toch wil testen, hier een iets groter invoerbestand: aoc-2024-day-10-challenge-1.zip
$ time pypy3 solve.py < aoc-2024-day-10-challenge-1.txt ...036 ...780 real 0m5.309s user 0m5.177s sys 0m0.084s
Valt me niet tegen.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ach, zolang je een stopconditie hebt, en zeker weet dat elke call een stapje dichter bij die conditie komt is er weinig moeilijks aanGropah schreef op dinsdag 10 december 2024 @ 07:56:
Hij voelde inderdaad wat simpel, maar dat komt inderdaad ook wel omdat ik dit soort dingen vaker heb opgelost (oa in AoC). Maar gezien mijn dag vandaag vind ik dat helemaal niet erg
[...]
spoiler:Had er zelf helemaal niet bij stil gestaan dat recursie hier een optie was. Vind het vaak wel elegant, maar merk toch dat ik vaak naar queues grijp omdat ik die wat flexibeler vind en je sowieso niet bang hoeft te zijn voor een recursiefoutje.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
When life gives you lemons, start a battery factory
Het enige probleem is altijd dat ik na een jaar altijd een beetje vergeten ben welke functies ik er ook alweer in had zitten en hoe ik die zou moeten gebruiken
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Hij was vandaag inderdaad vrij triviaal als je al eerder soortgelijke problemen hebt opgelost. Mijn oplossing lost de aoc-2024-day-10-challenge-1 test case op in 12ms: https://github.com/Robbin.../blob/main/day10/day10.cc. Voor part 2 gebruik ik dynamisch programmeren, met een complexiteit van O(N * M).Soultaker schreef op dinsdag 10 december 2024 @ 08:18:
Qua extra data is er niet veel interessants te bedenken vandaag, maar voor wie toch wil testen, hier een iets groter invoerbestand: aoc-2024-day-10-challenge-1.zip
$ time pypy3 solve.py < aoc-2024-day-10-challenge-1.txt ...036 ...780 real 0m5.309s user 0m5.177s sys 0m0.084s
@Janoz Ik heb alle sterren tot nog toe, maar behalve voor jaar 2019 geen framework. Het enige wat ik heb is 1 scriptje dat automatisch de input ophaalt, opslaat in de goeie map, en een "Day10.py"-script maakt in diezelfde map. In dat script staan 2/3 regels die ik vaak gebruik om de input te lezen, maar meer niet.
Ik schrijf iedere keer "alles" opnieuw. Vind het leuk als iedere oplossing gewoon een zelfstandig werkend stukje code is, vooral ook zodat anderen (zowel hier als op Reddit) het zonder gedoe kunnen lezen en uitvoeren. Python is ook redelijk compact, dus heel tijd of ruimte win ik er niet mee.Janoz schreef op dinsdag 10 december 2024 @ 08:57:
Heb je nog geen uitgebreide support library dan? Ik dacht dat iedereen die al iets vaker dan 1x meegedaan had wel 1 of ander frameworkje voor zichzelf in elkaar geknutseld had.
Vandaag paste alles weer in 10 regels
[ Voor 4% gewijzigd door Friits op 10-12-2024 09:02 ]
Dit is mijn tweede jaar AoC, vorig jaar tot iets over de helft volgehouden dacht ik.Janoz schreef op dinsdag 10 december 2024 @ 08:57:
Heb je nog geen uitgebreide support library dan? Ik dacht dat iedereen die al iets vaker dan 1x meegedaan had wel 1 of ander frameworkje voor zichzelf in elkaar geknutseld had.
Het enige probleem is altijd dat ik na een jaar altijd een beetje vergeten ben welke functies ik er ook alweer in had zitten en hoe ik die zou moeten gebruiken
Had nog geen echte support lib, anders dan een hele basale helperfunctie voor het inlezen van input files.
Aangezien vandaag zo simpel was heb ik maar even een begin gemaakt met een gridlib met functies voor navigeren in grids, checken of iets in bounds is en dat soort zaken. Scheelt toch weer het in je hoofd omflippen van x en y coordinaten de hele tijd als je werkt met een list van string.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Verandert z'n sig te weinig.
Gropah schreef op dinsdag 10 december 2024 @ 07:56:
Hij voelde inderdaad wat simpel, maar dat komt inderdaad ook wel omdat ik dit soort dingen vaker heb opgelost (oa in AoC). Maar gezien mijn dag vandaag vind ik dat helemaal niet erg
[...]
spoiler:Had er zelf helemaal niet bij stil gestaan dat recursie hier een optie was. Vind het vaak wel elegant, maar merk toch dat ik vaak naar queues grijp omdat ik die wat flexibeler vind en je sowieso niet bang hoeft te zijn voor een recursiefoutje.
Alleen om de tekstfile in te lezen, dijkstra, timings en om pypy aan te slingeren vanuit python. Voor grids heb ik nog nooit iets gebouwd.Janoz schreef op dinsdag 10 december 2024 @ 08:57:
Heb je nog geen uitgebreide support library dan? Ik dacht dat iedereen die al iets vaker dan 1x meegedaan had wel 1 of ander frameworkje voor zichzelf in elkaar geknutseld had.
Ik was niet 100% serieus, maar ook vandaag heeft Friits weer complexe getallen gebruikt (buren zijn 1,1j,-1,-1j)... Ik gebruik wel eens sin en cos om buren te genereren. Dat voorkomt weer domme foutjes.Hagdos schreef op dinsdag 10 december 2024 @ 09:01:
@KabouterSuper Voor buren bepalen vind ik complexe getallen niet zo interessant. Dat is vooral handig als je rotaties moet doen.
When life gives you lemons, start a battery factory
Even snel een paste voor je gemaakt: *klik voor Kotlin code*. Let wel; het is verre van mooi of geoptimaliseerd.Satom schreef op dinsdag 10 december 2024 @ 09:58:
Dag 10 opgelost, ik had deel 2 al opgelost in deel 1:9 Toch wel fijn als je na een dag vol struggelen een dag krijgt die "makkelijk" is. Denk dat het langzamerhand wel tijd wordt om eens een grid-helper te maken!
[...]
spoiler:Staat je queue implementatie ergens online? Ik doe het nu met recursie, met soms een foutje hier en daar, dus ben wel erg nieuwsgierig naar jou implementatie met queues!
/f/image/V9XZe4WHOG6LL3asWz40Axaq.png?f=fotoalbum_large)