Advent of Code 2024 Vorige deel Overzicht

Pagina: 1 ... 5 ... 10 Laatste
Acties:

Acties:
  • 0 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

Ghehe schreef op zondag 8 december 2024 @ 10:20:
[...]


Ik was de opdracht al 15 minuten aan het bekijken en herlezen. Het zal wel aan mijn niveau van de Engelse taal liggen 8)7
Nee hoor, ik vond het ook onduidelijk geformuleerd. Pas na 3x lezen en vooral veel naar de voorbeelden staren had ik het door.

Verandert z'n sig te weinig.


Acties:
  • +1 Henk 'm!

  • Mugwump
  • Registratie: Mei 2017
  • Laatst online: 21:20
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.
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.

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra


Acties:
  • +1 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
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.
Volgens mij checkt 'ie daar correct op (maar ik kan me vergissen).
Devilfish schreef op zondag 8 december 2024 @ 10:51:
Dus als je een voorbeeld kan vinden dat fout gaat, dan kan ik verder checken :).
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:

####
...#
^###

Acties:
  • 0 Henk 'm!

  • ZpAz
  • Registratie: September 2005
  • Laatst online: 13-09 14:38
Najaaa..

Afbeeldingslocatie: https://tweakers.net/i/t55rbHwBvReOBBKoRiNEz6TSO1g=/800x/filters:strip_exif()/f/image/V9XZe4WHOG6LL3asWz40Axaq.png?f=fotoalbum_large

spoiler:
Wie van jullie had 1933

[ Voor 33% gewijzigd door ZpAz op 08-12-2024 11:49 ]

Tweakers Time Machine Browser Extension | Chrome : Firefox


Acties:
  • 0 Henk 'm!

  • Mugwump
  • Registratie: Mei 2017
  • Laatst online: 21:20
Ik snap ergens wel dat het geen pure trial-and-error moet worden of zelfs domweg een brute-force van alle mogelijke antwoorden (werkt natuurlijk niet voor alle puzzels). :P

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


Acties:
  • +1 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

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 :)

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.


Acties:
  • +1 Henk 'm!

  • MatHack
  • Registratie: Oktober 2001
  • Niet online

MatHack

Dev by day, Gamer by night

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: Stappenplan
Loop 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 :).
spoiler:
Volgens mij is de fout dat je in je visited HashSet geen rekening houdt met de richting waarop de guard loopt, maar alleen de positie. Je zou een pad ook moeten kunnen kruisen.

There's no place like 127.0.0.1


Acties:
  • 0 Henk 'm!

  • Satom
  • Registratie: Mei 2011
  • Laatst online: 13-09 18:19

Satom

Verzamel ervaringen

Dag 7 gisteravond op de valreep nog weten op te lossen. Het lange verhaal kort was:
spoiler:
een long in een int is uiteraard een overflow..


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 O-) Die is nu nog wel langzaam (geloof iets van 20 seconden), op een later moment maar eens opzoek naar een fatsoenlijk oplossing voor het samenvoegen van getallen, long.Parse() is wat langzaam, lijkt het.

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!
.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 :)
Dat is dus heel verschillend per dag, heb ik het idee. Dag 7 gaaf bij mij aan dat mijn antwoord te laag was!

[ Voor 14% gewijzigd door Satom op 08-12-2024 12:50 ]


Acties:
  • 0 Henk 'm!

  • Devilfish
  • Registratie: Augustus 2001
  • Laatst online: 19:22
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:

####
...#
^###
Daar zou 0 moeten uitkomen toch? Hoe zou je anders een loop moeten maken?

Acties:
  • 0 Henk 'm!

  • MueR
  • Registratie: Januari 2004
  • Laatst online: 00:33

MueR

Admin Tweakers Discord

is niet lief

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.

Anyone who gets in between me and my morning coffee should be insecure.


Acties:
  • 0 Henk 'm!

  • Bolukan
  • Registratie: Oktober 2002
  • Laatst online: 23-08 23:43
Weer helemaal bij. En day 6 part 2 revisited (blocking the guard): 5,8 seconde. Alleen de turns bewaren: 3,5 seconde. Goede hint.

Acties:
  • 0 Henk 'm!

  • KabouterSuper
  • Registratie: September 2005
  • Niet online
Friits schreef op zondag 8 december 2024 @ 07:27:
[...]
Leuk puzzeltje, maar ik had inmiddels wel wat ingewikkelders verwacht!
Ik had hetzelfde gevoel. Ik had me al ingelezen in intcode voor het geval dat dat zou komen.

When life gives you lemons, start a battery factory


Acties:
  • 0 Henk 'm!

  • ZpAz
  • Registratie: September 2005
  • Laatst online: 13-09 14:38
ZpAz schreef op zondag 8 december 2024 @ 11:46:
Najaaa..

[Afbeelding]

spoiler:
Wie van jullie had 1933
Ah! Dom. Ik nam mijn beginpositie niet mee.
spoiler:
1911

Tweakers Time Machine Browser Extension | Chrome : Firefox


Acties:
  • +1 Henk 'm!

  • Friits
  • Registratie: December 2023
  • Laatst online: 24-06 08:21
Wat is IntCode? ;)

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 :o

Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
Devilfish schreef op zondag 8 december 2024 @ 14:31:
Daar zou 0 moeten uitkomen toch? Hoe zou je anders een loop moeten maken?
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. :P

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.

Acties:
  • 0 Henk 'm!

  • Mugwump
  • Registratie: Mei 2017
  • Laatst online: 21:20
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.
Dat is op zich wel knap. :P

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


Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 20:12

Creepy

Tactical Espionage Splatterer

Ik heb ook nog steeds een soortgelijk probleem met 6.2 . En al twee keer tegen een antwoord aangelopen van een andere input :D

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


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

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. :P

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.
Ik heb het niet door mijn implementatie gehaald maar als ik dit zo eyeball dan kom ik op 5?

.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.


Acties:
  • 0 Henk 'm!

  • Bolukan
  • Registratie: Oktober 2002
  • Laatst online: 23-08 23:43
laat maar :)

[ Voor 97% gewijzigd door Bolukan op 08-12-2024 15:54 ]


Acties:
  • 0 Henk 'm!

  • DutchFakeTuber
  • Registratie: Februari 2016
  • Laatst online: 11-09 10:48
Dag 8 was voor deel 2 aardig verwarrend. Na eens beter te lezen heb ik het wel op kunnen lossen.
Had iemand anders daar ook moeite mee?

spoiler:
De losse antennes tellen blijkbaar ook mee. Daar had ik eerst geen rekening mee gehouden.

Acties:
  • 0 Henk 'm!

  • Mschamp
  • Registratie: April 2014
  • Laatst online: 21:48
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.
Had ik ook, en bleek dat ik deze vergeten was:
The original example now has 34 antinodes, including the antinodes that appear on every antenna:

Acties:
  • 0 Henk 'm!

  • hiekikowan
  • Registratie: Februari 2011
  • Laatst online: 07-09 17:37
Ook hier op 6.2 de sample die goed gaat, de echte input zit 2 te hoog for some reason... doorrekenen is ook echt traag (minuten) dus testen is nasty (ik gebruik qua algo het zelfde als de meesten, maar plpgsql helpt waarschijnlijk niet mee in dit soort cases)

Acties:
  • +1 Henk 'm!

  • Devilfish
  • Registratie: Augustus 2001
  • Laatst online: 19:22
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. :P

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 zette me op het goede antwoord :) Thx! En ik had blijkbaar een foutje gemaakt met lezen, ik had het goede antwoord al gehad, maar was toen tegen de niet te snel weer antwoorden muur gelopen... En dus ga je het rabbit hole wel in...

Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 20:12

Creepy

Tactical Espionage Splatterer

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. :P

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.
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


Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
Creepy 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.
Klinkt als een andere bug dan Devilfish had, maar fijn om te horen dat het voorbeeld twee mensen geholpen heeft :Y)

Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 20:12

Creepy

Tactical Espionage Splatterer

Juh, dit was een bug die ik zelf ook had moeten zien met de test input ondanks dat dat antwoord wel goed was.

"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


Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 20:12

Creepy

Tactical Espionage Splatterer

"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


Acties:
  • +1 Henk 'm!

  • gpk481
  • Registratie: Januari 2016
  • Laatst online: 12-09 13:58
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.
[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:
$ 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 :)

Acties:
  • 0 Henk 'm!

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Pfoe, net even Dag 7 gedaan, en probeer dag 8, maar ik denk dat ik niet meer nuchter genoeg ben, want ik snap echte even niet wat er bij dag 8 part 2 verwacht worden.

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.”


Acties:
  • 0 Henk 'm!

  • Woy
  • Registratie: April 2000
  • Niet online

Woy

Moderator Devschuur®
Na nog een paar keer goed kijken toch ook deel 2 opgelost, ik dacht dat er extra antennes bij kwamen, maar puur dat signalen wat verder dragen. Was dus ook nog snel te doen.

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.”


Acties:
  • 0 Henk 'm!

  • ZpAz
  • Registratie: September 2005
  • Laatst online: 13-09 14:38
Ik moet beter lezen.

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 ]

Tweakers Time Machine Browser Extension | Chrome : Firefox


Acties:
  • +1 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ik vind dag 8 maar stom

spoiler:
Het komt voor part1 nooit voor dat er antinodes op 1/3 en 2/3 tussen de antennes in zitten omdat dat nooit integer-coordinaten zijn, terwijl die posities volgens de omschrijving ook aan de criteria voldoen.

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.


Acties:
  • +1 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
spoiler: day9
Met 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.

Acties:
  • 0 Henk 'm!

  • mbe81
  • Registratie: Juni 2008
  • Laatst online: 13-09 15:00
.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.

Acties:
  • 0 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

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)

Verandert z'n sig te weinig.


Acties:
  • 0 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
Day 9 vrij recht toe recht aan opgelost.

spoiler: day9
Wel interessant dat ik uiteindelijk 2 compleet losstaande implementatie heb gedaan. Ik zie ook niet zo snel hoe het eenvoudig anders kan.
Robbinb1993 schreef op maandag 9 december 2024 @ 07:04:
spoiler: day9
Met 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.
spoiler: day9
Misschien wel, maar in praktijk zijn de getallen qua ruimte zo klein dat ik vermoed dat een simpele oplossing misschien wel net zo snel is. Ook al is die technisch gezien O(n^2), in praktijk kun je vroeg genoeg stoppen dat het alsnog heel snel is.
Maar misschien wel interessant om te gaan testen :)

Acties:
  • 0 Henk 'm!

  • mbe81
  • Registratie: Juni 2008
  • Laatst online: 13-09 15:00
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)
spoiler:
Ik doe iets soortgelijks maar heb alle blokken apart in mijn lijst staan. Dan inderdaad kijken wat de lengte van de file is, een geldige free space opzoeken en de blokken omwisselen. Daarna de positie verplaatsen op basis van de lengte van de file en naar de volgende. Valt vast nog wat aan te optimaliseren maar gaat snel genoeg.

Acties:
  • 0 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
Mijn uiteindelijke geoptimaliseerde code met complexiteit O(N log N) draait test case 2 nu in 1 ms. Ben benieuwd naar grotere test cases:

https://github.com/Robbinb1993/AoC24/blob/main/day9/day9.cc

[ Voor 43% gewijzigd door Robbinb1993 op 09-12-2024 09:08 ]


Acties:
  • +2 Henk 'm!

  • Friits
  • Registratie: December 2023
  • Laatst online: 24-06 08:21
Marcj schreef op maandag 9 december 2024 @ 07:47:
spoiler: day9
Wel interessant dat ik uiteindelijk 2 compleet losstaande implementatie heb gedaan. Ik zie ook niet zo snel hoe het eenvoudig anders kan.
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.

[ Voor 37% gewijzigd door Friits op 09-12-2024 10:20 ]


Acties:
  • 0 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
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.
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).

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 ]


Acties:
  • +3 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
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.)

[ Voor 1% gewijzigd door Soultaker op 09-12-2024 10:04 . Reden: Antwoorden challenge 3 gefixed ]


Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-09 09:39

Janoz

Moderator Devschuur®

!litemod

Ik vond het vandaag vooral een 'spot de off by 1 bug' exercitie ipv een echte optimalisatie opdracht. Het was dan ook voor het eerst dit jaar dat ik daadwerkelijk meerdere unittests gemaakt en gebruikt heb. Maar aangezien deel 1 en 2 samen binnen een halve seconde runnen hier vind ik het snel genoeg en zie ik later wel of er eventueel nog wat te optimaliseren valt.


spoiler:
Ik heb nu gewoon alle bestanden in een lijst staan waarin ik alles loop op te knippen en verplaatsen, maar ik kan me voorstellen dat een linked list implementatie een stuk sneller is dan het opschuiven van alle nodes.



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'


Acties:
  • 0 Henk 'm!

  • RangedNeedles
  • Registratie: Juli 2009
  • Niet online
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.

Acties:
  • 0 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
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.)
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: (....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 ]


Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-09 09:39

Janoz

Moderator Devschuur®

!litemod

RangedNeedles 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.
Wanneer je die oplossingsrichting gebruikt moet je even goed opletten hoe je de situaties voor x/0 en 0/0 afhandelt ;)

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

RangedNeedles 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.
Als je (een deel van) je input kunt delen dan kan ik wel aangeven welke regels wel en welke niet kunnen

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.


Acties:
  • +1 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
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.)
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!

Acties:
  • 0 Henk 'm!

  • RangedNeedles
  • Registratie: Juli 2009
  • Niet online
.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
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:
Alleen zichtbaar voor ingelogde gebruikers. Inloggen
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 ;)
Die check had ik er nog niet in staan ( 8)7) maar verandert eig niets aan het eindresultaat.

Acties:
  • 0 Henk 'm!

  • Gropah
  • Registratie: December 2007
  • Niet online

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

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.

[ Voor 6% gewijzigd door Gropah op 09-12-2024 10:08 ]


Acties:
  • +1 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
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.
Oh crap, je hebt gelijk. Ik heb de referentie-antwoorden daarop aangepast.
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).
Heel netjes! (Ik neem aan dat je antwoorden bij deel 3 nog met 64 bits waren.)
Part 1 doe ik in O(N) met two-pointer technique.
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).

[ Voor 6% gewijzigd door Soultaker op 09-12-2024 10:15 ]


Acties:
  • +1 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
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).
spoiler:
Dat is inderdaad een goede observatie, er zijn maar maximaal 9 groottes, dus je hoeft maar maximaal 9 sets bij te houden, en 1 removal en insert van een free block size als deze (deels) gevuld is (ook O(log N)). Dit komt ook op O(2 * 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.


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 ]


Acties:
  • 0 Henk 'm!

  • Mugwump
  • Registratie: Mei 2017
  • Laatst online: 21:20
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.
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 :')

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra


Acties:
  • +1 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

RangedNeedles 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 ( 8)7) maar verandert eig niets aan het eindresultaat.
https://gist.github.com/o...14049501c315552fde4184521

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.


Acties:
  • +2 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
Robbinb1993 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.
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: (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. ]


Acties:
  • +1 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
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.
spoiler:
priority_queue is inderdaad wel netter. Ik had het ook verkeerd eerst dat het 9 * log(N) zou zijn om voor elke set de laagste index op te vragen, want bij een set het eerste element opvragen is ook O(1). Ik heb in mijn bovenstaande comment mijn bijbehorende code toegevoegd.

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 ]


Acties:
  • 0 Henk 'm!

  • Gropah
  • Registratie: December 2007
  • Niet online

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

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 :')
spoiler:
Die viel mij wel redelijk hard op, omdat de 9's eerst naar het begin werden gezet, en daarna weer naar het eind gingen :P toen de gaten zoekfunctie aangepast dat ie niet voorbij de backmarker gaat en voila. Denk dat ik eerst meer stumped was dat het niet in een int paste (dus maar meteen naar bigdecimal gegaan) en dat mijn checksum niet werkt (want die liep tot eerste null value :+ vanwege deel 1)

[ Voor 14% gewijzigd door Gropah op 09-12-2024 10:57 ]


Acties:
  • 0 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
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.
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 11% gewijzigd door Soultaker op 09-12-2024 11:26 ]


Acties:
  • 0 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
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.
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.

[ Voor 7% gewijzigd door Robbinb1993 op 09-12-2024 11:36 ]


Acties:
  • +1 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

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 
...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.)
Met de ideeen van hierboven
spoiler:
vector van priority queues voor de lege ruimtes
kom ik nu met mijn oplossing uit op:

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.


Acties:
  • +1 Henk 'm!

  • MatHack
  • Registratie: Oktober 2001
  • Niet online

MatHack

Dev by day, Gamer by night

Deel 1 van vandaag was zo gepiept en is ook lekker snel (max paar ms, inclusief input verwerken):
spoiler: dag 9, deel 1
Gewoon een grote array met alle blocks en dan met twee indexes (vrije blocks vanaf links, gevulde blocks vanaf rechts) erdoor heen om de blocks te verplaatsen tot de indexes elkaar kruisen.

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 2
Ik 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

There's no place like 127.0.0.1


Acties:
  • +1 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

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 2
Ik 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
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).

Verandert z'n sig te weinig.


Acties:
  • +2 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
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!
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.

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 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


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!


edit: Nog een paar kleine aanpassing, minder geheugengebruik betekent ook meer snelheid!

[ Voor 7% gewijzigd door Marcj op 09-12-2024 15:36 ]


Acties:
  • 0 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
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!
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?

Acties:
  • 0 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
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?
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.

Acties:
  • 0 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
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.
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)?

Acties:
  • 0 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
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)?
spoiler:
Effectief O(N) ja. Worst-case denk ik nog wel O(N log(N)) technisch gezien, maar de benchmark liegt er niet om.

Acties:
  • +3 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
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.
Nice! Ik moet even kijken wat je precies doet.

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:
spoiler:
In plaats van de gaten te groeperen per grootte, groepeer ik de bestanden per grootte. Vervolgens loop ik van links naar rechts door de schijf heen, en om een gat te vullen pak ik greedily het meest rechter bestand dat in het gat past; dat kan ik in O(9) vinden.


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.

Acties:
  • +1 Henk 'm!

  • Varienaja
  • Registratie: Februari 2001
  • Laatst online: 14-06 16:43

Varienaja

Wie dit leest is gek.

Leuk. Bedankt voor de extra uitdaging! Ik moest inderdaad met BigIntegers aan de slag voor de juiste antwoorden, heb ik niet meegecommit:
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.


Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 20:12

Creepy

Tactical Espionage Splatterer

Ik merk dat het geneuzel me een beetje tegen begint te staan. De test input voor 9.1 werkt prima, maar de echte input niet. Longs enzo al in gebruik dus dat is het niet. Misschien aan het einde van de avond nog even verder of morgen weer.

"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


Acties:
  • +1 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

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 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 8)7

[ 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.


Acties:
  • +1 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

.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)
Dat probleem had ik ook eerst.

spoiler:
Checken of je niet files niet per ongeluk naar rechts verplaatst. Gaat altijd goed in het voorbeeld


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.


Acties:
  • +2 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
Ik heb net nog een manier gevonden om deel 1 wel efficienter te doen met hergebruik van de code van deel 2. Ik moest gewoon wat anders nadenken over dit probleem. Samen met nog wat kleine verbeteringen bereiken we denk ik zo langzamerhand het limiet.

ps. Ik heb wel wat pre-calculatie in de parser nu zitten, omdat de data tussen de deel 1 en deel 2 wordt gedeeld.

code:
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 :P

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

.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 8)7
Godver :(. Code omgeschreven, nog steeds het goede antwoord voor het voorbeeld, nog steeds het verkeerde voor mijn input.

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.


Acties:
  • 0 Henk 'm!

  • Marcj
  • Registratie: November 2000
  • Laatst online: 12-09 19:26
.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.
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?

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

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?
Ja, en ook dat hij niet naar een grotere offset moet verplaatsen zoals @FCA ook al opmerkte.
.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 :Y)

[ 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.


Acties:
  • 0 Henk 'm!

  • Satom
  • Registratie: Mei 2011
  • Laatst online: 13-09 18:19

Satom

Verzamel ervaringen

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 2
spoiler:
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 :X

Acties:
  • +1 Henk 'm!

  • MatHack
  • Registratie: Oktober 2001
  • Niet online

MatHack

Dev by day, Gamer by night

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 2
spoiler:
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 :X
Ik vermoed dat je bij (1) een van de twee volgende dingen hebt gemist:
spoiler:
1. Per block mag je maar maximaal 1 keer proberen om deze te verplaatsen, als het niet lukt, laat je het block staan. Eenmaal verplaatst is definitieve positie.
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


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12-09 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ik heb inmiddels ook een efficientere implementatie

spoiler:
O(n) door 9 linked lists bij te houden. Elke list loopt over de gapnodes op volgorde van offset waarin hij past. Bij het verkleinen van de gap haal je de node weg uit de lists in de range [nieuw + 1, oud]


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 8)7

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 :D

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 :z

[ 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.


Acties:
  • 0 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

Vandaag voelde te simpel voor een dag 10 (of ik ben inmiddels te geoefend in dit soort puzzeltje?)
spoiler:
Voor het eerst ook dat ik direct een oplossing in Rust zag die ik niet zo 123 in Python had kunnen doen:
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.


Acties:
  • 0 Henk 'm!

  • bakkerjangert
  • Registratie: Februari 2012
  • Laatst online: 19:44
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.

Acties:
  • +1 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
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?)
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.
in Rust kun je ook vec's in een HashSet gooien, terwijl je in Python er geen list's in kunt stoppen.
(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).

Acties:
  • 0 Henk 'm!

  • Hagdos
  • Registratie: April 2022
  • Laatst online: 06:04
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.
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).

Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-09 09:39

Janoz

Moderator Devschuur®

!litemod

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 hetzelfde :D

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

[ 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'


Acties:
  • +1 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

Soultaker 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.
En ik heb niet eens informatica gestudeerd :+ . Maar wel veel programmeerwedstrijden gedaan vroeger, en dit is mijn 5e Advent of Code, dus ja, point taken.
(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).
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.

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.


Acties:
  • 0 Henk 'm!

  • Gropah
  • Registratie: December 2007
  • Niet online

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

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 :P
Janoz schreef op dinsdag 10 december 2024 @ 07:10:
[...]

Ik had EXACT hetzelfde :D

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
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.

Acties:
  • +2 Henk 'm!

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:44
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

Acties:
  • +1 Henk 'm!

  • Mugwump
  • Registratie: Mei 2017
  • Laatst online: 21:20
Blij dat ik niet de enige sukkel ben die in een eerste poging om deel 1 op te lossen per ongeluk deel 2 had opgelost. Gelukkig was ik wel zo slim om onraad te ruiken en de oorspronkelijke implementatie te behouden omdat ik het vermoeden had dat dit wel eens deel 2 kon worden. :P

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


Acties:
  • 0 Henk 'm!

  • MatHack
  • Registratie: Oktober 2001
  • Niet online

MatHack

Dev by day, Gamer by night

Haha, hier nog iemand die het antwoord voor deel 2 al een paar keer voorbij zag komen tijdens het oplossen van deel 1. Gelukkig had ik ook vrij snel door waar mijn probleem zat bij deel 1. Misschien later nog even de moeite nemen om iets meer DRY toe te passen, maar voor nu tevreden (en tijd om bezig te gaan met de eigenlijke taken van de dag).

https://github.com/realma...de.Y2024/Solvers/Day10.cs

There's no place like 127.0.0.1


Acties:
  • +1 Henk 'm!

  • Mugwump
  • Registratie: Mei 2017
  • Laatst online: 21:20
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
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). :P
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


Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-09 09:39

Janoz

Moderator Devschuur®

!litemod

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 :P


[...]


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.
Ach, zolang je een stopconditie hebt, en zeker weet dat elke call een stapje dichter bij die conditie komt is er weinig moeilijks aan ;).

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • +1 Henk 'm!

  • KabouterSuper
  • Registratie: September 2005
  • Niet online
Vandaag was inderdaad te gemakkelijk voor de AoC veteranen. Ik heb geen letter geprogrammeerd die ik niet eerder geprogrammeerd heb. Maar dat geeft misschien tijd om wat dingen te automatiseren die ik al meerdere keren heb ingetypt: grid inlezen, evt omzetten naar int, startpunt(en) bepalen, (valide) buren bepalen, etc. Voor de laatste overweeg ik (natuurlijk) @Friits's favoriete methode: complexe getallen .

When life gives you lemons, start a battery factory


Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-09 09:39

Janoz

Moderator Devschuur®

!litemod

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 :D

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • +1 Henk 'm!

  • Robbinb1993
  • Registratie: September 2020
  • Laatst online: 02-08 07:54
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
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).

Acties:
  • 0 Henk 'm!

  • Hagdos
  • Registratie: April 2022
  • Laatst online: 06:04
@KabouterSuper Voor buren bepalen vind ik complexe getallen niet zo interessant. Dat is vooral handig als je rotaties moet doen.

@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.

Acties:
  • +1 Henk 'm!

  • Friits
  • Registratie: December 2023
  • Laatst online: 24-06 08:21
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 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.

Vandaag paste alles weer in 10 regels :)

[ Voor 4% gewijzigd door Friits op 10-12-2024 09:02 ]


Acties:
  • 0 Henk 'm!

  • Mugwump
  • Registratie: Mei 2017
  • Laatst online: 21:20
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 :D
Dit is mijn tweede jaar AoC, vorig jaar tot iets over de helft volgehouden dacht ik.
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. :P

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra


Acties:
  • 0 Henk 'm!

  • FCA
  • Registratie: April 2000
  • Laatst online: 13-09 11:27

FCA

Ik besefte me net trouwens dat ik mijn input parse functie die ik gisteren had "klaargezet" voor vandaag, gewoon direct heb kunnen gebruiken, zonder enige aanpassing :)

Verandert z'n sig te weinig.


Acties:
  • 0 Henk 'm!

  • Satom
  • Registratie: Mei 2011
  • Laatst online: 13-09 18:19

Satom

Verzamel ervaringen

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!


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 :P


[...]


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.
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! _/-\o_

Acties:
  • 0 Henk 'm!

  • KabouterSuper
  • Registratie: September 2005
  • Niet online
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.
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.
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.
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.

When life gives you lemons, start a battery factory


Acties:
  • +1 Henk 'm!

  • Gropah
  • Registratie: December 2007
  • Niet online

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

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! _/-\o_
Even snel een paste voor je gemaakt: *klik voor Kotlin code*. Let wel; het is verre van mooi of geoptimaliseerd.

spoiler:
InputReader bevat allerlei methods om data in te lezen. In dit geval een grid van chars en daar een map van een zelf gemaakt Point class naar een char. Die Point kent ook een fourNeighbors functie voor horizontale en verticale buren. Deque is een Double Edge que, gezien kotlin geen normale queue heeft. Denk dat de rest wel redelijk vanzelf sprekend is :) Mocht dat toch niet zo zijn, laat het weten (y)
Pagina: 1 ... 5 ... 10 Laatste