Advent of Code 2024

[heuveltje]

Ik doe eigenlijk niks met programeren, afgezien van het zeer zeldzame vba of powershell scriptje op het werk,
Maar rond deze tijd kriebelt het weer, en gaan we toch even kijken hoever we komen

Dag 1 ging makkelijk
Dag 2 duurde al ruim een uur

ik heb het 2e probleem "gebruteforced. door gewoon in elke regel elke waarde 1 keer weg te halen, en kijken of het dan wel goedgekeurd was.
ik had niet (goed) door dat in python list.remove(waarde) altijd de eerste waarde weghaalde.
En laat ik nu 1 input regel hebben, waar dat als edgecase niet goed ging
" 19 16 15 13 16 "

vervang .remove door .pop en alles werkt vloeiend. maar voor je dat door had.........

[ Voor 7% gewijzigd door heuveltje op 02-12-2024 17:56 ]

[ElkeBxl]

Dag 2 in TypeScript
Gewoon bruteforce voor part 2, nu het nog kan

[P_Tingen]

Voor de mensen die de opgaven oplossen met Excel; hoe doe je dat, met VBA of met formules?
Kan iemand eens een oplossing posten van dag 1 of 2 in Excel?

[Satom]

Corniel schreef op zondag 1 december 2024 @ 22:07:
[...]


Ik ben benieuwd of je er iets aan hebt.

Ik laat het weten als ik iets heb, voor nu heb het ik het even geparkeerd, eerst maar eens deze maand doorkomen

---

Tot dusver is ben ik nog helemaal bij, zojuist day 2 afgerond. Ik heb wel even moeten ploeteren op deel 2.

spoiler:

Ergens las ik iets over brute-forcen en dat heeft geholpen!

[MueR]

Soultaker schreef op zondag 1 december 2024 @ 15:33:
[...]

Nette oplossing, maar de timings erken ik niet, want je hebt zowel het sorteren (voor deel 1) als het populeren van de occurrences map (voor deel 2) in je input-functie weggemoffeld, terwijl dat natuurlijk onderdeel van het oplossen is.

Yeah ik was hier een klein beetje aan het cheaten. Had vandaag toevallig een discussie met een collega, die vond dat timings altijd vanaf laden van input tot einde moeten zijn. Ik heb een net ander standpunt.. Ik vind het standaard splitten op newline en evt vast casten naar ints niet perse deel er van. Zodra je iets gaat doen met die dingen begint het te tellen. Hoe staan anderen hier in?

[ProAce]

Ik houd daar dezelfde strategie in aan, maar dat komt ook deels door dat ik alle inputs van alle oplossingen alvast in laad bij opstarten en dan de dagen uitvoer waar ik geïnteresseerd in ben. Stukje over engineering maar maakt het wel makkelijk uitbreidbaar.

https://github.com/ysmilda/Advent-of-code

[Reptile209]

P_Tingen schreef op maandag 2 december 2024 @ 21:52:
Voor de mensen die de opgaven oplossen met Excel; hoe doe je dat, met VBA of met formules?
Kan iemand eens een oplossing posten van dag 1 of 2 in Excel?

spoiler:

DAG 1 - puur Excel
Part 1: Beide kolommen sorteren, abs(A1-B1) om de verschillen te berekenen en op te tellen
Part 2: =Countif($B:$B, A1) in kolom C, en dan Cx * Ax voor de score.

DAG 2 - VBA

Het werkt, ik ga niet voor de schoonheidsprijs . Gebruik in het werkblad =IsSafe(A1:I1, -1) op elke regel voor Part 1. Voor Part 2 zit er nog een kleine hulpfunctie bij die via parameter skip een voor een de opties weglaat, net zo lang tot er een werkende oplossing is of tot alle opties geprobeerd zijn.

[code=VBA]Function IsSafe(R As Range, skip As Integer)
Dim List(8 )

ListCount = 1
For n = 1 To R.Columns.Count
If n <> skip And R.Cells(1, n) <> "" Then
List(ListCount) = R.Cells(1, n)
ListCount = ListCount + 1
End If
Next n
ListCount = ListCount - 1

For n = 2 To ListCount 'skip first one
a = List(n)
b = List(n - 1)

If n = 2 Then
If (b - a) < 0 Then
IsRise = False
Else
IsRise = True
End If
End If

If Not IsSafe2(a, b, IsRise) Then
IsSafe = n
Exit Function
End If
Next n
'Debug.Print "Safe!"
IsSafe = 0
End Function

Function IsSafe2(a, b, IsRise)
If (b - a) < 0 And IsRise = True Then
IsSafe2 = False
ElseIf (b - a) > 0 And IsRise = False Then
IsSafe2 = False
ElseIf Abs(b - a) > 3 Or Abs(b - a) < 1 Then
IsSafe2 = False
Else
IsSafe2 = True
End If
End Function
[/code]

[heuveltje]

Reptile209 schreef op maandag 2 december 2024 @ 22:37:
[...]

spoiler:

DAG 1 - puur Excel
Part 1: Beide kolommen sorteren, abs(A1-B1) om de verschillen te berekenen en op te tellen
Part 2: =Countif($B:$B, A1) in kolom C, en dan Cx * Ax voor de score.

DAG 2 - VBA

Het werkt, ik ga niet voor de schoonheidsprijs . Gebruik in het werkblad =IsSafe(A1:I1, -1) op elke regel voor Part 1. Voor Part 2 zit er nog een kleine hulpfunctie bij die via parameter skip een voor een de opties weglaat, net zo lang tot er een werkende oplossing is of tot alle opties geprobeerd zijn.

[code=VBA]Function IsSafe(R As Range, skip As Integer)
Dim List(8 )

ListCount = 1
For n = 1 To R.Columns.Count
If n <> skip And R.Cells(1, n) <> "" Then
List(ListCount) = R.Cells(1, n)
ListCount = ListCount + 1
End If
Next n
ListCount = ListCount - 1

For n = 2 To ListCount 'skip first one
a = List(n)
b = List(n - 1)

If n = 2 Then
If (b - a) < 0 Then
IsRise = False
Else
IsRise = True
End If
End If

If Not IsSafe2(a, b, IsRise) Then
IsSafe = n
Exit Function
End If
Next n
'Debug.Print "Safe!"
IsSafe = 0
End Function

Function IsSafe2(a, b, IsRise)
If (b - a) < 0 And IsRise = True Then
IsSafe2 = False
ElseIf (b - a) > 0 And IsRise = False Then
IsSafe2 = False
ElseIf Abs(b - a) > 3 Or Abs(b - a) < 1 Then
IsSafe2 = False
Else
IsSafe2 = True
End If
End Function
[/code]

maar op dat punt ben je het niet meer in excel bezig.
das net zoiets als claimen dat je het in notepad aan het doen bent omdat je daar je python in hebt getyped.

[Reptile209]

heuveltje schreef op maandag 2 december 2024 @ 22:51:
[...]


maar op dat punt ben je het niet meer in excel bezig.
das net zoiets als claimen dat je het in notepad aan het doen bent omdat je daar je python in hebt getyped.

Klopt hoor. Kan vast ook wel echt in native-Excel denk ik, maar dan krijg je een heleboel hulpkokommen en onleesbare formules .

Voordeel is voor mij vooral dat ik op mijn werk laptop geen developer-tools heb (want mijn werk is heel erg niet IT). Via Excel VBA kan je dan toch nog een beetje programmeren

Edit:
Vooruit, de testcase van Part 1 in native Excel gedaan. De formules onderaan is wat er linksboven in dat blokje staat. Voor de echte input moet je ook nog een beetje rommelen met het wisselende aantal elementen per regel, maar dat is met een Count() snel op te lossen in plaats van de hardcoded 4 die er nu bijvoorbeeld in zit. Deel 2 is echt wel een uitdaging om zo te doen trouwens, daar begin ik even niet aan .

spoiler:

[ Voor 55% gewijzigd door Reptile209 op 02-12-2024 23:29 ]

[Creepy]

MueR schreef op maandag 2 december 2024 @ 22:19:
[...]

Yeah ik was hier een klein beetje aan het cheaten. Had vandaag toevallig een discussie met een collega, die vond dat timings altijd vanaf laden van input tot einde moeten zijn. Ik heb een net ander standpunt.. Ik vind het standaard splitten op newline en evt vast casten naar ints niet perse deel er van. Zodra je iets gaat doen met die dingen begint het te tellen. Hoe staan anderen hier in?

Ik time alles per dagdeel inclusief inlezen. Iets anders is cheaten zoals je al zegt Input verwerking is ook onderdeel van het geheel.

Vandaag dag 1 en dag 2 gedaan.

spoiler:

Dag 2 deel 2 uiteindelijk moeten bruteforcen ipv slim weghalen. Ik had iets dat bij een fout maximaal 2 keer een item uit de array verwijderde maar ergens leverde dat een subtiele bug op. Ik kwam uiteindelijk 4 goede oplossingen te kort t.o.v. de bruteforce. Ik had geen zin meer om dat nog te fixen.

Ben alsnog in Java begonnen en niet in Rust want ik ben te gaar de afgelopen dagen om er ook nog eens een nieuwe taal bij te pakken.

Morgen nog eens kijken of ik de boel nog op Github zet.

[ Voor 4% gewijzigd door Creepy op 02-12-2024 23:29 ]

[MueR]

Creepy schreef op maandag 2 december 2024 @ 23:23:
[...]

Ik time alles per dagdeel inclusief inlezen. Iets anders is cheaten zoals je al zegt Input verwerking is ook onderdeel van het geheel.

Yeah but no. Imo heb je met typesafe talen dan altijd een hogere runtime omdat sommige talen gewoon geen fuck geven om string "1" of een int 1. En andere talen geven je de mogelijkheid om je input gewoon te embedden zodat je FS overhead skipped. Die parsing stap, mits het simpel casten is, niet timen vind ik prima. En ja, ik time die stap ook, maar mijn solution time is vanaf "hier is een array van je input, succes".

[ZpAz]

Zal ook een aantal proberen, golang is de taal van keuze voor dit jaar. Weet niet hoe ver ik kom, op den duur kosten ze gewoon veel tijd, wat ik op het moment niet echt heb.

edit:

Day1 done. Slapen.

[ Voor 9% gewijzigd door ZpAz op 03-12-2024 00:29 ]

[Creepy]

O, input embedden is ook cheaten wat mij betreft. Of c++ templates gebruiken om compile time een oplossing te genereren, etc etc

En als het casten in een type safe taal je overhead is, dan heb je een hele goede oplossing. Het is geen pissing contest he Zo wel: flash je fucking disk cache van je OS voordat je gaat timen en iedereen moet verplicht dezelfde cpu, ssd, mem speed etc gebruiken;)

[ Voor 50% gewijzigd door Creepy op 02-12-2024 23:49 ]

[mbe81]

Ik heb vandaag best wel lang zitten aanklooien met deel 2 omdat ik even niet scherp had dat je in Go niet zomaar een waarde uit een slice kan verwijderen zonder de originele slice aan te passen. Wanneer je dit doet met append om zo een nieuw slice te maken bestaande uit het eerste deel en het tweede deel van de originele slice, dan wordt ook de originele slice aangepast.

Voorbeeld van wat ik bedoel: https://go.dev/play/p/lyRZzSyEXn-

"In Go, when you use append to combine slices, it doesn't modify the original slice's data because append allocates a new backing array if necessary. However, if the original slice's capacity is large enough to accommodate the new data, the append function might reuse the same backing array. This can lead to unintended modifications if the new slice is altered later."

[MueR]

Creepy schreef op maandag 2 december 2024 @ 23:45:
O, input embedden is ook cheaten wat mij betreft. Of c++ templates gebruiken om compile time een oplossing te genereren, etc etc

Mjah, dan zou stdin gebruiken, zeker in talen die weinig geven om string of int, ook cheaten zijn.

En als het casten in een type safe taal je overhead is, dan heb je een hele goede oplossing. Het is geen pissing contest he Zo wel: flash je fucking disk cache van je OS voordat je gaat timen en iedereen moet verplicht dezelfde cpu, ssd, mem speed etc gebruiken;)

I just like to see small numbers

[mbe81]

Ook vandaag was nog behoorlijk eenvoudig. Een oplossing in Go: https://github.com/mbe81/.../main/days/day03/day03.go

[Soultaker]

MueR schreef op maandag 2 december 2024 @ 22:19:
Ik vind het standaard splitten op newline en evt vast casten naar ints niet perse deel er van. Zodra je iets gaat doen met die dingen begint het te tellen. Hoe staan anderen hier in?

Ik ben het met jou eens dat “input inlezen” vaak het minst interessante deel van de oplossing is, en ik focus ook liever op de efficiëntie van het oplossingsalgoritme. Maar als je wil vergelijken met anderen, dan ben ik het met @Creepy eens dat totaaltijd uiteindelijk de meest objectieve maatstaf is, anders wordt het een sport om zoveel mogelijk processing te verplaatsen naar je invoerroutine omdat het dan niet meetelt.

In m'n Zig oplossingen van vorig jaar (die meer gefocused zijn op performance dan m'n Python oplossingen; ik wilde onder de 1 seconde in totaal uitkomen) probeerde ik parse en solve tijd zoveel mogelijk te splitsen, maar dat is niet voor elk probleem mogelijk, dus gebruik ik uiteindelijk totaaltijd als maatstaf, want dat is voor elk probleem te berekenen. Dat lijkt me uiteindelijk het eerlijkste.

Tenslotte denk ik dat we ons niet te veel moeten focussen op benchmarkscores, vooral niet bij de makkelijkere problemen van Advent of Code. Het is vaak zo dat zeker in de eerste paar dagen de nadruk nogal op parsen ligt, terwijl performance optimalisaties pas interessant worden als het oplossingsalgoritme minder triviaal is.

Mjah, dan zou stdin gebruiken, zeker in talen die weinig geven om string of int, ook cheaten zijn.

Lezen uit stdin of uit een bestand maakt geen significant verschil in performance.

[FCA]

Het was weer Advent of Inputparsing vandaag. Deel 1 ging redelijk snel,

spoiler:

nadat ik alle quirks van de Regex library in Rust weer door had

deel 2 duurde wat langer omdat ik ook nog ontbijt moest klaarzetten

[Friits]

Voor het simpele regex-achtige werk heeft Python de parse library. Een soort inverse van format(). Daarmee werd vandaag wel erg simpel:

spoiler:

from parse import findall
d = "do()" + open("data.txt").read() + "don't()"
for _ in 1, 2:
print(sum(x*y for x,y in findall("mul({:d},{:d})", d)))
d = ''.join(r[0] for r in findall("do(){}don't()", d))

[Mugwump]

FCA schreef op dinsdag 3 december 2024 @ 07:39:
Het was weer Advent of Inputparsing vandaag. Deel 1 ging redelijk snel,

spoiler:

nadat ik alle quirks van de Regex library in Rust weer door had

deel 2 duurde wat langer omdat ik ook nog ontbijt moest klaarzetten

Ik had inderdaad hetzelfde hier met Kotlin. Toch weer even klooien met hoe de Regex uit de stdlib nou precies werkt.

En om 6 uur in de ochtend regexes kloppen is ook niet het best moment (curly braces voor quantifiers, geen square brackets natuurlijk )

Het uiteindelijke resultaat:
https://codefile.io/f/Bu4pISZuTE

[Remcoder]

Well, that's a first...

spoiler:

Ik liep net tegen een probleem aan dat ontstaat doordat mijn standaard oplossingsmanier is om elke line op zichzelf te bestuderen.

Deze keer was de state global over alle lines heen...

[Mugwump]

Remcoder schreef op dinsdag 3 december 2024 @ 08:50:
Well, that's a first...

spoiler:

Ik liep net tegen een probleem aan dat ontstaat doordat mijn standaard oplossingsmanier is om elke line op zichzelf te bestuderen.

Deze keer was de state global over alle lines heen...

spoiler:

Ja dit programma werkte met global variables.
Ik vroeg me nog even af of de instructies ook van het eind van een regel over konden lopen in het begin van de volgende, maar dat was niet het geval. Strikt genomen is een line break ook een karakter wat ongeldig is volgens de specificatie natuurlijk.

[Remcoder]

Mugwump schreef op dinsdag 3 december 2024 @ 08:14:
[...]


Ik had inderdaad hetzelfde hier met Kotlin. Toch weer even klooien met hoe de Regex uit de stdlib nou precies werkt.

En om 6 uur in de ochtend regexes kloppen is ook niet het best moment (curly braces voor quantifiers, geen square brackets natuurlijk )

Het uiteindelijke resultaat:
https://codefile.io/f/Bu4pISZuTE

Oeh, jij durft, \d{1-3}, als er ergens een getal groter dan 999 had gestaan was het stuk gegaan.

[Mugwump]

Remcoder schreef op dinsdag 3 december 2024 @ 08:59:
[...]

Oeh, jij durft, \d{1-3}, als er ergens een getal groter dan 999 had gestaan was het stuk gegaan.

Nou, als ik de oplossingen zo zie ben ik volgens mij de enige die wel netjes de instructies heeft gelezen.

It seems like the goal of the program is just to multiply some numbers. It does that with instructions like mul(X,Y), where X and Y are each 1-3 digit numbers.

[Remcoder]

Mugwump schreef op dinsdag 3 december 2024 @ 09:01:
[...]


Nou, als ik de oplossingen zo zie ben ik volgens mij de enige die wel netjes de instructies heeft gelezen.


[...]

Oh, dan was het bij mij dus stuk gegaan als er een getal groter dan 999 was geweest

[Woy]

Haha, ik had ook de max van 3 digits niet gelezen, maar dat gaf gelukkig geen issues.

https://github.com/rverst.../blob/main/Y2024/Day03.cs

[Eupeodes]

Remcoder schreef op dinsdag 3 december 2024 @ 08:50:
Well, that's a first...

spoiler:

Ik liep net tegen een probleem aan dat ontstaat doordat mijn standaard oplossingsmanier is om elke line op zichzelf te bestuderen.

Deze keer was de state global over alle lines heen...

same...

[KabouterSuper]

Vandaag kansloos verslagen door mijn dochter. Door een dom denkfoutje in deel 1 (ervan uit gaan dat het één lange string was) én deel 2 (state te vaak resetten) ben ik veel langer bezig geweest dan noodzakelijk. Maar zoals een goede ouder betaamt, heb ik ridderlijk mijn verlies toegegeven.

Geef mij maar een opgave a la 2023/dag 24, dan kan ik mijn achterstand weer inhalen.

[MaNDaRK]

Thanks @KabouterSuper daar ging ik dus ook faliekant de mist in.

Tot ik dus de regelnummers zag in mijn input bestand...

[Woy]

KabouterSuper schreef op dinsdag 3 december 2024 @ 09:44:
Vandaag kansloos verslagen door mijn dochter. Door een dom denkfoutje in deel 1 (ervan uit gaan dat het één lange string was)

Is dat het niet? Ik heb het ook gewoon als 1 string behandeld.

[Corniel]

Soultaker schreef op dinsdag 3 december 2024 @ 07:38:
[...]

Ik ben het met jou eens dat “input inlezen” vaak het minst interessante deel van de oplossing is, en ik focus ook liever op de efficiëntie van het oplossingsalgoritme. Maar als je wil vergelijken met anderen, dan ben ik het met @Creepy eens dat totaaltijd uiteindelijk de meest objectieve maatstaf is, anders wordt het een sport om zoveel mogelijk processing te verplaatsen naar je invoerroutine omdat het dan niet meetelt.

Ik ben het er mee eens dat input parsing onderdeel is van het oplossen, en je het zou moeten meenemen in de meting. Ik doe dat zelf echter niet. Uit praktische overwegingen overigens. Het bleek gedoe om het mee te nemen in de calculaties (heeft te doen met hoe ik e.a. heb opzet).

Sowieso kan de input nogal bepalend zijn voor hoe lang het duurt. Ik kan me een opgave uit 2022 herinneren waar mijn algoritme onder de 10 ms zat, en van een vriend in de 30 seconde. Toen hij mijn input probeerde duurde het voor hem nog maar 5 seconde, en toen ik de zijne probeerde kwam mijn code niet met het goede antwoord...

[TrailBlazer]

langer geduurd dan nodig door stomme aannames

spoiler:

ik ging er van uit dat de do en don´t elkaar omwisselden. Uiteindelijk eenn greedy findall gebruikt om alle waardes tussen do en don´t er uit te vissen.

[.oisyn]

Ik heb het nog te druk met Sinterklaas (er moeten hier in huis 6 surprises gemaakt worden ). Ik zal eens kijken of ik in het weekend een inhaalslag kan maken .

Ik zal al dat de leaderboards werden verpest door AI oplossingen

[ Voor 17% gewijzigd door .oisyn op 03-12-2024 10:25 ]

[breew]

Dag 3 in R vrij rechtoe rechtaan. Dag 2 deel 2 nog niet aan toegekomen...

spoiler:

Dag 3 deel 2 alles (non greedy) weggemikt wat tussen een don't en een do staat, en dan de oplossing van part 1 hergebruiken. regex daarvoor: "(?<=don't).*?(?=do)"

[ Voor 8% gewijzigd door breew op 03-12-2024 10:34 ]

[DutchFakeTuber]

Dag 3 was prima te doen, echter is mijn oplossing minder elegant dan de oplossingen die hier staan. Wel blij dat ik zonder enige hints of Google inspiratie de puzzel van vandaag op heb kunnen lossen.

[P_Tingen]

Deel 1 duurde door een domme fout van mij veel te lang.

spoiler:

Om de twee getallen te scheiden gebruik ik een INT functie in combinatie met NO-ERROR, waarna ik uitvraag óf er een fout is opgetreden. In dat geval was het kennelijk geen geldig getal. Dat doe ik twee keer, want twee getallen. Mijn fout was dat ik niet tussendoor de error-status checkte maar alleen na het tweede getal. Doh!

Deel 2 ging dan weer verrassend vlot, wel wat onnodige tijd verprutst omdat ik zo nodig zelf een functie in elkaar gezet bleek te hebben die al standaard in mijn programmeeromgeving zit (Progress 4GL)

spoiler:

Ik had een functie gemaakt om de laatste positie van "do()" of "don't()" terug te geven, op basis van een INDEX in een loopje (net zo lang door blijven zoeken tot je hem niet meer vindt en dan de laatst bekende positie teruggeven). Leuk, maar er is al een R-INDEX in Progress die precies dat doet. Zucht

https://github.com/patric...ter/2024/Day-03/day-03a.p
https://github.com/patric...ter/2024/Day-03/day-03b.p

[ Voor 8% gewijzigd door P_Tingen op 03-12-2024 10:46 ]

[heuveltje]

Wel ruim 2 uur mee bezig geweest maar dag 3 is ook weer gedaan

Deel 2 was 4 minuten om een status switch in te bouwen. en dan 10 min bezig geweest om te zoeken waarom het de dont in het voorbeeld oversloeg, om dan te realiseren dat de voorbeeldregel van deel 2 niet dezelfde is als die van deel 1

Wel betrap ik me er weer op dat mijn oplossingen bijna altijd een combinatie van for loops en if statements is.
het werkt, maar toch eens kijken hoe andere dat doen.

Mugwump schreef op dinsdag 3 december 2024 @ 09:01:
[...]


Nou, als ik de oplossingen zo zie ben ik volgens mij de enige die wel netjes de instructies heeft gelezen.


[...]

Dat had ik dan weer wel meteen goed
valt me tegen dat ze in de input generator niet automatisch wat van dit soort valkuilen laten zetten

[ Voor 35% gewijzigd door heuveltje op 03-12-2024 10:53 ]

[Soultaker]

Corniel schreef op dinsdag 3 december 2024 @ 09:53:
Sowieso kan de input nogal bepalend zijn voor hoe lang het duurt. Ik kan me een opgave uit 2022 herinneren waar mijn algoritme onder de 10 ms zat, en van een vriend in de 30 seconde. Toen hij mijn input probeerde duurde het voor hem nog maar 5 seconde, en toen ik de zijne probeerde kwam mijn code niet met het goede antwoord...

Da's ook waar inderdaad. Nog een goede reden om mijn grote inputs te gebruiken om te benchmarken, die zijn voor iedereen hetzelfde.

[Marcj]

Ik was eerst met een Regex aan de slag, maar heb uiteindelijk wat lopen spelen met nom. Dit is een parsing framework voor Rust en je kunt daar best leuke dingen mee doen. Het is uiteraard niet zo compact als een regex, maar wat mij betreft wel beter leesbaar. Uiteindelijk is dit een opdracht om te leren parsen, want de echte berekening stelt natuurlijk niks voor.

code:

❯ cat input/day3.txt | day3
Executing
 ├── Input parsed in 87µs
 ├── Part 1 calculated in 0µs: 171183089
 ├── Part 2 calculated in 1µs: 63866497
 └── Total time: 97µs

[Woy]

Marcj schreef op dinsdag 3 december 2024 @ 11:16:
Ik was eerst met een Regex aan de slag, maar heb uiteindelijk wat lopen spelen met nom. Dit is een parsing framework voor Rust en je kunt daar best leuke dingen mee doen. Het is uiteraard niet zo compact als een regex, maar wat mij betreft wel beter leesbaar. Uiteindelijk is dit een opdracht om te leren parsen, want de echte berekening stelt natuurlijk niks voor.

code:

❯ cat input/day3.txt | day3
Executing
 ├── Input parsed in 87µs
 ├── Part 1 calculated in 0µs: 171183089
 ├── Part 2 calculated in 1µs: 63866497
 └── Total time: 97µs

Toen ik de opgave las dacht ik er eerst ook over om meteen een parser generator te gebruiken, want natuurlijk het vermoeden dat dit dit jaar vaker in deze vorm terug gaat komen. Maar toch maar voor de nog net wat makkelijker Regex gegaan.

[Marcj]

Woy schreef op dinsdag 3 december 2024 @ 11:22:
[...]

Toen ik de opgave las dacht ik er eerst ook over om meteen een parser generator te gebruiken, want natuurlijk het vermoeden dat dit dit jaar vaker in deze vorm terug gaat komen. Maar toch maar voor de nog net wat makkelijker Regex gegaan.

Snap ik, maar juist deze makkelijke opdracht gebruik ik om wat gevoel te krijgen bij tools die ik later goed kan gebruiken. Ik weet van vorig jaar nog dat de latere dagen genoeg andere uitdagingen hebben.

[MueR]

heuveltje schreef op dinsdag 3 december 2024 @ 10:49:
om te zoeken waarom het de dont in het voorbeeld oversloeg, om dan te realiseren dat de voorbeeldregel van deel 2 niet dezelfde is als die van deel 1

Yeah, ik had datzelfde probleem. Duurde even voor ik die doorhad

[gedonie]

Voor vandaag bij deel 1 een regex gebruikt om alle vermenigvuldigingen eruit te trekken. Bij deel 2 toch maar overgestapt op een taal scanner en parser.

https://github.com/gjong/...nt/years/y2024/Day03.java

[Janoz]

Ik snap dat mensen graag naar regexpen grijpen bij dit soort vragen, maar op 1 of andere manier vind ik het fijner om gewoon lekker door de string te wandelen. Is ook efficienter en zeker als Soultaker met strings van gigabytes aan gaat komen is het ook fijn dat het streaming kan gebeuren

[Creepy]

Zo, dag 3 ook af en de boel eens online gezet https://github.com/CodeEngineerNL/AdventOfCode2024
Dag 3: https://github.com/CodeEn...er/aoc/aoc2024/Day03.java

En eens met Janoz. Door de string heen wandelen en posities blijven zoeken. Geen regexp of parser generator gebruikt.

spoiler:

En doordat je met posities werkt kan je na een don't() direct de do() opzoeken en daartussen alles vrolijk negeren of zelfs direct stoppen als je geen do() of na de do() geen mul() meer tegenkomt.

[ Voor 12% gewijzigd door Creepy op 03-12-2024 13:55 ]

[gedonie]

Janoz schreef op dinsdag 3 december 2024 @ 13:41:
Ik snap dat mensen graag naar regexpen grijpen bij dit soort vragen, maar op 1 of andere manier vind ik het fijner om gewoon lekker door de string te wandelen. Is ook efficienter en zeker als Soultaker met strings van gigabytes aan gaat komen is het ook fijn dat het streaming kan gebeuren

Gewoon om te kijken naar performance heb ik deel 2 ook nog eens herschreven naar een oplossing met een regex. Als ik de resultaten qua tijden bekijk is het verschil in Java in ieder geval nihil, als in beide draaien gemiddeld in 1ms.

[Woy]

Mwah, ik ben niet altijd fan van regexp, en ik geloog zeker dat het mogelijk nog iets efficienter kan, maar zeker met de source generated Regexp parsers en geen gekke fratsen om het werkend te krijgen vind ik dit wel een fijnere oplossing, en handmatig parsen gaat geen grote winst opleveren.

Natuurlijk is he wel een nadeel dat het niet streaming kan, en optimalisaties zoals @Creepy aanhaalt zijn niet mogelijk.

[CMG]

Soultaker schreef op zaterdag 30 november 2024 @ 13:12:
[...]

Mooi staaltje overengineering Ik denk dat ik in plaats daarvan een Chrome extension geschreven zou hebben, dan kun je ofwel de session cookie uit de request headers halen (tenzij secure cookies ook voor extensions verborgen worden?) of anders gewoon de invoer direct downloaden. Dat vereist nog wel dat je de opgave in de browser opent, maar dat doe ik normalerwijze toch wel.


[...]

Thanks 😊 Altijd leuk, zo'n uitdaging 😊

[Corniel]

Soultaker schreef op dinsdag 3 december 2024 @ 10:55:

Da's ook waar inderdaad. Nog een goede reden om mijn grote inputs te gebruiken om te benchmarken, die zijn voor iedereen hetzelfde.

Dat zeker. Maar je hebt de (onhebbelijke ) gewoonte data te generen die voor een aantal mensen zorgt dat hun oplossing niet meer werkt.

Maar goed, voorlopig zijn de opgaven een stuk eenvoudiger dan een jaar geleden. Ben benieuwd hoelang dat zo blijft.

[Corniel]

Janoz schreef op dinsdag 3 december 2024 @ 13:41:
Ik snap dat mensen graag naar regexpen grijpen bij dit soort vragen (..)

Het is de tweede keer dat ik met een Regex op de proppen kwam. (De andere keer was 2020 dag 19). En het is hier denk ik (zolang je idd niet extreem grote streams in een keer moet processen) snel. Mijn oplossing voor deel 2 doet het in 73.34 µs. En met veel minder regels code dan dat je zelf een parser moet gaan zitten knutselen. Dag 3.

[Janoz]

Corniel schreef op dinsdag 3 december 2024 @ 14:27:
[...]


Het is de tweede keer dat ik met een Regex op de proppen kwam. (De andere keer was 2020 dag 19). En het is hier denk ik (zolang je idd niet extreem grote streams in een keer moet processen) snel. Mijn oplossing voor deel 2 doet het in 73.34 µs. En met veel minder regels code dan dat je zelf een parser moet gaan zitten knutselen. Dag 3.

Regexp zal niet langzaam zijn, maar kan volgens mij onmogelijk sneller zijn dan een simpele indexOf en/of een charAt. En een parser schrijven is met deze beperkte syntax ook niet heel veel werk IMHO. Enige tricky aan deze opdracht is dat je hele stukken moet negeren (en dan bedoel ik niet deel 2, maar dat de garbage tussen de daadwerkelijk te parsen onderdelen zit)

Misschien moet ik toch maar eens een generieke parser aan mijn AoC library toe gaan voegen.

[Woy]

Janoz schreef op dinsdag 3 december 2024 @ 14:47:
[...]


Regexp zal niet langzaam zijn, maar kan volgens mij onmogelijk sneller zijn dan een simpele indexOf en/of een charAt. En een parser schrijven is met deze beperkte syntax ook niet heel veel werk IMHO. Enige tricky aan deze opdracht is dat je hele stukken moet negeren (en dan bedoel ik niet deel 2, maar dat de garbage tussen de daadwerkelijk te parsen onderdelen zit)

Op zich kan het in de basis zeker niet sneller zijn dan een zelf geschreven goede parser, maar in .NET is de generatie wel enorm optimized, o.a. dingen als vectorization d.m.v. van bijvoorbeeld SIMD zal je zelf niet zo snel toepassen. Zeker nu de generatie al compile time gebeurt krijg je gewoon heel veel kado, een beetje hetzelfde als het gebruik van assembly v.s. een meer high level taal en alle slimigheid van een compiler.

[Corniel]

Woy schreef op dinsdag 3 december 2024 @ 15:11:
[...]

Op zich kan het in de basis zeker niet sneller zijn dan een zelf geschreven goede parser, maar in .NET is de generatie wel enorm optimized (..)

Idd. Toen ik van een runtime regex omschreef naar een compile time generated regex halveerde de tijd die mijn oplossing nodig had. Maar het schrijven van een goede parser die sneller is, is wel wat werk denk ik.

[Coocoocachoo]

P_Tingen schreef op maandag 2 december 2024 @ 21:52:
Voor de mensen die de opgaven oplossen met Excel; hoe doe je dat, met VBA of met formules?
Kan iemand eens een oplossing posten van dag 1 of 2 in Excel?

https://docs.google.com/s...KjmeYnBg/edit?usp=sharing (kopie op mijn spam account, deze wordt dus niet verder geupdate)

Vorig jaar in Excel 14 sterren gehaald, dit jaar Google Sheets aan het proberen. Maar waar Day 2 Deel 2 in mijn hoofd een heel makkelijke programmeer oplossing heeft kom ik echt niet in de buurt van een zinvolle gedachte hoe ik het in Excel/sheets op kan lossen.
Mijn Excel van vorig jaar is een moloch met voor de grootste oplossing een tabel van 210x212 cellen.

Dit jaar ben ik overigens ook lelijk zonder code comments (titels boven kolommen) aan het werken, dus weet niet hoe leesbaar het voor anderen is.

[Woy]

Corniel schreef op dinsdag 3 december 2024 @ 15:15:
[...]


Idd. Toen ik van een runtime regex omschreef naar een compile time generated regex halveerde de tijd die mijn oplossing nodig had. Maar het schrijven van een goede parser die sneller is, is wel wat werk denk ik.

To be fair, ik heb even getest met de code van Creepy die ik naar .net geport heb en een beetje aangepast heb om hem allocatie vrij te maken, en dat is nu 14 us, versus 140 us met mijn regex implementatie.

Overigens zonder die allocatie changes is het 75 vs 140 us, dus dan is het verschil al een stuk kleiner.

spoiler:

[Benchmark]
public long ParseCreepyOptimized()
{
long total = 0;

var i = 0;
int pos = input.IndexOf("mul(", i, StringComparison.Ordinal);

var dontPos = input.IndexOf("don't()", StringComparison.Ordinal);
if (dontPos == -1) {
dontPos = Int32.MaxValue;
}

while (pos > 0) {
if (pos > dontPos) {
i = input.IndexOf("do()", dontPos+ 7, StringComparison.Ordinal);
if (i == -1) {
break;
}

pos = input.IndexOf("mul(", i, StringComparison.Ordinal);
if (pos == -1) {
break;
}


dontPos = input.IndexOf("don't()", pos, StringComparison.Ordinal);
if (dontPos == -1) {
dontPos = Int32.MaxValue;
}

continue;
}

var kommaPos = input.IndexOf(',', pos);
var closingPos = input.IndexOf(')', kommaPos);

if(Int32.TryParse(input.AsSpan((pos + 4) .. kommaPos), out var a)
&& Int32.TryParse(input.AsSpan((kommaPos + 1) .. closingPos), out var b))
{
total += a * b;

i = closingPos;
}
else
{
i = pos + 4;
}

pos = input.IndexOf("mul(", i, StringComparison.Ordinal);
}

return total;
}

[heuveltje]

Coocoocachoo schreef op dinsdag 3 december 2024 @ 15:43:
[...]

https://docs.google.com/s...KjmeYnBg/edit?usp=sharing (kopie op mijn spam account, deze wordt dus niet verder geupdate)

Vorig jaar in Excel 14 sterren gehaald, dit jaar Google Sheets aan het proberen. Maar waar Day 2 Deel 2 in mijn hoofd een heel makkelijke programmeer oplossing heeft kom ik echt niet in de buurt van een zinvolle gedachte hoe ik het in Excel/sheets op kan lossen.
Mijn Excel van vorig jaar is een moloch met voor de grootste oplossing een tabel van 210x212 cellen.

Dit jaar ben ik overigens ook lelijk zonder code comments (titels boven kolommen) aan het werken, dus weet niet hoe leesbaar het voor anderen is.

Ligt er ook aan, hoe je "in excel" oppakt. Ik heb ooit een collega gehad op het werk, die handig was met excel draaitabellen, marcro's opnemen etc, maar niks van VBA ofzo wist. Die zag toevallig waar ik in de pauze mee bezig was, en wou eht ook eens proberen

Die heeft toch meerdere dagen een antwoord kunenn generen, en sneller dan mij kunnen zijn door handmatig het sheet te bewerken tot hij het antwoord had.

iets als ctrl f op don't begin daar een nieuwe regel
ctrl f op Do() en delete alles er tussen in

[ Voor 6% gewijzigd door heuveltje op 03-12-2024 16:27 ]

[Coocoocachoo]

heuveltje schreef op dinsdag 3 december 2024 @ 16:26:
[...]


Ligt er ook aan, hoe je "in excel" oppakt. Ik heb ooit een collega gehad op het werk, die handig was met excel draaitabellen, marcro's opnemen etc, maar niks van VBA ofzo wist. Die zag toevallig waar ik in de pauze mee bezig was, en wou eht ook eens proberen

Die heeft toch meerdere dagen een antwoord kunenn generen, en sneller dan mij kunnen zijn door handmatig het sheet te bewerken tot hij het antwoord had.

iets als ctrl f op don't begin daar een nieuwe regel
ctrl f op Do() en delete alles er tussen in

Klopt, ik vind het wat dat betreft ook juist wel leuk om over oplossingen na te denken en dan te kijken welke problemen makkelijk zijn met Excel en welke toch echt wel meer geschikt voor een "echte" programmeertaal. Maar vorig jaar was er ook eentje die ik ook gewoon met de hand op een rekenmachine kon doen, omdat er stiekem gewoon een simpele formule achter de bewerkingen zat. (Ik dacht https://adventofcode.com/2023/day/6)

En als je van handwerk verliest moet je gewoon @Soultaker aankijken om een megainput te genereren zoals ik me (hopelijk goed) herinner dat hij dat vroeger nog wel heeft gedaan. Er is altijd een kantelpunt wanneer de automatisering wint

[Soultaker]

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.

[Soultaker]

Janoz schreef op dinsdag 3 december 2024 @ 13:41:
Ik snap dat mensen graag naar regexpen grijpen bij dit soort vragen, maar op 1 of andere manier vind ik het fijner om gewoon lekker door de string te wandelen. Is ook efficienter en zeker als Soultaker met strings van gigabytes aan gaat komen is het ook fijn dat het streaming kan gebeuren

Dit zeg je wel maar als ik je code bekijk dan lees je alsnog de hele string in het geheugen, dus dat voordeel is puur theoretisch op dit moment

[Corniel]

Woy schreef op dinsdag 3 december 2024 @ 15:50:
[...]

To be fair, ik heb even getest met de code van Creepy die ik naar .net geport heb en een beetje aangepast heb om hem allocatie vrij te maken, en dat is nu 14 us, versus 140 us met mijn regex implementatie.

Ik had ook iets gedaan, met ReadOnly spans. Bij was het verschil minder groot: 72us vs 28us. Ik weet niet of ik die regex beter inzet, of regex-loos minder handig was dan Creepy. Maar goed, mijn Regex oplossing is 10 regels triviale code, mijn regex-loze code veroorzaakt een beetje hoofdpijn.

[SPee]

Woy schreef op dinsdag 3 december 2024 @ 13:59:
Mwah, ik ben niet altijd fan van regexp, en ik geloog zeker dat het mogelijk nog iets efficienter kan, maar zeker met de source generated Regexp parsers en geen gekke fratsen om het werkend te krijgen vind ik dit wel een fijnere oplossing, en handmatig parsen gaat geen grote winst opleveren.

Marcj schreef op dinsdag 3 december 2024 @ 11:16:
Ik was eerst met een Regex aan de slag, maar heb uiteindelijk wat lopen spelen met nom. Dit is een parsing framework voor Rust en je kunt daar best leuke dingen mee doen. Het is uiteraard niet zo compact als een regex, maar wat mij betreft wel beter leesbaar. Uiteindelijk is dit een opdracht om te leren parsen, want de echte berekening stelt natuurlijk niks voor.

code:

❯ cat input/day3.txt | day3
Executing
 ├── Input parsed in 87µs
 ├── Part 1 calculated in 0µs: 171183089
 ├── Part 2 calculated in 1µs: 63866497
 └── Total time: 97µs

Ik heb beide via een Regex opgelost. Maar merkte dat het parsen ervan in Rust toch wel wat tijd kostte.
Mogelijk dat ik in de toekomst nom probeer, maar daar moet ik eerst tijd voor maken om dat te leren. Mijn Rust is nog wat roestig, dus dat kost al genoeg tijd.

[Soultaker]

SPee schreef op dinsdag 3 december 2024 @ 17:55:
Mijn Rust is nog wat roestig

Dat is toch juist goed?

[Marcj]

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.

Ik kom op dezelfde antwoorden lijkt het, dus mijn interpretatie is waarschijnlijk hetzelfde. Moest wel even naar i64 switchen, want voor de normale opdracht gebruikte ik nog i32

code:

❯ cat big_inputs/aoc-2024-day-03-challenge-1.txt | day3
Executing
 ├── Input parsed in 116,332µs
 ├── Part 1 calculated in 1,666µs: ...57200
 ├── Part 2 calculated in 1,103µs: ...81743
 └── Total time: 119,138µs

❯ cat big_inputs/aoc-2024-day-03-challenge-2.txt | day3
Executing
 ├── Input parsed in 5,429,124µs
 ├── Part 1 calculated in 223,648µs: ...33600
 ├── Part 2 calculated in 59,367µs: ...57973
 └── Total time: 5,712,217µs

[Marcj]

SPee schreef op dinsdag 3 december 2024 @ 17:55:
[...]

Ik heb beide via een Regex opgelost. Maar merkte dat het parsen ervan in Rust toch wel wat tijd kostte.
Mogelijk dat ik in de toekomst nom probeer, maar daar moet ik eerst tijd voor maken om dat te leren. Mijn Rust is nog wat roestig, dus dat kost al genoeg tijd.

Ik vind je code anders best netjes hoor! Je doet meer met regex dan wat ik zo snel voor elkaar kreeg.

[SideSplitter]

De oplossingen hier voor 3b zijn toch iets eleganter dan wat ik zelf in elkaar heb geflanst.

spoiler:

Een tweede regex die alles tussen don’t() en do() weghaalt

[Soultaker]

@Janoz inspireerde me met z'n suggestie van een oplossing die voor willekeurig grote invoer werkt zonder eerst alles in het geheugen te lezen.

Maar eerst, een pop quiz: wat is het beste statement in een programmeertaal? Fout! Het is goto. Hier is een oplossing met maar liefst 81 goto statements!

Het resulterende programma gebruikt een constante hoeveelheid geheugen (ongeveer 1,5 MiB op mijn systeem) ongeacht hoe groot de invoer is. Maar is het ook snel? Ja, best wel!

$ time ./solve2 < aoc-2024-day-03-challenge-2.txt
...33600
...57973

real    0m4.797s
user    0m4.592s
sys     0m0.198s

[Soultaker]

SideSplitter schreef op dinsdag 3 december 2024 @ 18:30:
De oplossingen hier voor 3b zijn toch iets eleganter dan wat ik zelf in elkaar heb geflanst.

spoiler:

Een tweede regex die alles tussen don’t() en do() weghaalt

@Friits deed hier iets soortgelijks dus je bent in goed gezelschap.

[Friits]

Het is maar wat je goed noemt hè. Ik zou niet echt blij worden van collega's die mijn soort code schrijven

Maar voor dit soort puzzeltjes is het prima: meestal snel klaar (rond positie 1000 op het global leaderboard, nu 3e op GoT), en aardig wat lof op Reddit.

[ Voor 8% gewijzigd door Friits op 03-12-2024 20:21 ]

[Litpho]

Vandaag aardig lopen prutsen met veel afleiding. Uiteindelijk maar de char voor char uitwerking uitgeschreven om een paar off-by-1 fouten uit mijn code te halen.

Daarna voor de vorm en voor de oefening nog weer even teruggezet naar nom. Om even bij bovenstaande discussie over timing te blijven, de nom implementatie is veel simpeler als je de do/don't filtering niet tijdens het parsen doet.

[ElkeBxl]

Dag 3 in TypeScript

Dit jaar doe ik de puzzels vooral 's avonds, hopelijk gaat dat niet te lastig worden eens de opdrachten moeilijker worden

[Soultaker]

Potverdorie, vandaag rank 101 op het leaderboard, i.e., de hoogste positie waarmee je net niet op het leaderboard komt

[FCA]

Soultaker schreef op woensdag 4 december 2024 @ 06:06:
Potverdorie, vandaag rank 101 op het leaderboard, i.e., de hoogste positie waarmee je net niet op het leaderboard komt

Ouch...
Ik deed er wat langer over vandaag, omdat ik

spoiler:

mijn richtingen vector niet goed had, waardoor ik bepaalde richtingen dubbel checkte, en andere niet. Door "geluk" kwam dit wel door de test invoer heen. Deel 2 was wel goed te doen daarna

[Soultaker]

FCA schreef op woensdag 4 december 2024 @ 06:32:
Ik deed er wat langer over vandaag, omdat ik

spoiler:

mijn richtingen vector niet goed had, waardoor ik bepaalde richtingen dubbel checkte, en andere niet. Door "geluk" kwam dit wel door de test invoer heen. Deel 2 was wel goed te doen daarna

Dat is leuk om te debuggen ja. Eigenlijk was deel 2 ook makkelijker dan deel 1, omdat je geen rekening hoeft te houden met de rand van het grid.

[mbe81]

Niet zo lastig vandaag maar om nu te zeggen dat het 'mooie' code is...
https://github.com/mbe81/.../main/days/day04/day04.go

[Thorwing]

Vandaag was het initieel huilen vanwege alles handmatig doen, maar na wat schoonmaakwerk ziet het er wel wat netter uit: https://github.com/mdekas...src/year2024/day4/Day4.kt

[Thorwing]

Soultaker schreef op woensdag 4 december 2024 @ 06:46:
[...]

Dat is leuk om te debuggen ja. Eigenlijk was deel 2 ook makkelijker dan deel 1, omdat je geen rekening hoeft te houden met de rand van het grid.

Dit is waarom ik eigenlijk altijd werk met een Map ipv direct op een matrix. Verschil tussen IndexOutOfBoundsException en null maakt uit

[Remcoder]

Dit moet wel haast het vroegste zijn dat ik iets uit mijn library nodig heb gehad.

Mijn grid kwam goed van pas, de hele zwik daarin ingeladen en daarin gaan zoeken naar XMAS.

https://github.com/remcos...er/adventofcode/Day4.java

[ Voor 24% gewijzigd door Remcoder op 04-12-2024 08:29 ]

[Mugwump]

mbe81 schreef op woensdag 4 december 2024 @ 06:49:
Niet zo lastig vandaag maar om nu te zeggen dat het 'mooie' code is...
https://github.com/mbe81/.../main/days/day04/day04.go

Ik schaam me ook diep voor wat ik vandaag nou weer geproduceerd heb.

[TrailBlazer]

leuke opdracht weet niet of ik deel 2 lastiger vond dat deel 1 tbh. Misschien een keer de goede implemenatie voor deel 1 gekozen

Python

zal mijn code nog wel wat opschonen hier en daar.

[ Voor 38% gewijzigd door TrailBlazer op 04-12-2024 08:50 ]

[Woy]

Ik had bij part1 een klein denkfoutje waardoor ik er iets langer over deed dan ik wou, maar verder was het vrij eenvoudig:

spoiler:

Ik telde alle posities waarvanaf je XMAS kon vinden, maar niet het aantal dat er vanaf die posities te vinden was

https://github.com/rverst.../blob/main/Y2024/Day04.cs

Part2 was eingelijk nog wat makkelijker dan Part1 IMHO

[ Voor 8% gewijzigd door Woy op 04-12-2024 08:57 ]

[FCA]

Soultaker schreef op woensdag 4 december 2024 @ 06:46:
[...]

Dat is leuk om te debuggen ja. Eigenlijk was deel 2 ook makkelijker dan deel 1, omdat je geen rekening hoeft te houden met de rand van het grid.

Ja, en nee. In rust heb je een trucje om i.p.v. zowel een cast van isize/i32 naar usize (die niet negatief mogen zijn) als de bound-check >=0 te doen, er usize::MAX bij op te tellen (met wrapping_add), en dan alleen de check aan de bovenkant te hieven doen. En in mijn geval hielp het met debuggen, want een usize::MAX op de verkeerde plek valt een stuk meer op dan een -1 i.p.v. een 1.

Ik heb ooit lang geleden (in Java 5 denk ik) de n-queens met exceptions voor de bounds checking geprogrammeerd, en er snel achter gekomen dat dat heel veel trager kan zijn.

[P_Tingen]

Ik lees iets niet goed denk ik. In mijn programma kom ik met de testinvoer al op 61 keer XMAS. Een steekproef in de resultaten laten geen valse positieven zien, dus ik snap iets niet.

Neem het onderste deel van het voorbeeld:

 7 S.S.S.S.SS  
 8 .A.A.A.A.A
 9 ..M.M.M.MM
10 .X.X.XMASX
   1234567890

Alleen hier haalt mijn programma al 29 combinaties uit.
Neem als voorbeeld de X linksonder. Daar haal ik deze combinaties uit:



Wat zie ik over het hoofd?

[Mugwump]

P_Tingen schreef op woensdag 4 december 2024 @ 09:04:
Ik lees iets niet goed denk ik. In mijn programma kom ik met de testinvoer al op 61 keer XMAS. Een steekproef in de resultaten laten geen valse positieven zien, dus ik snap iets niet.

Neem het onderste deel van het voorbeeld:

 7 S.S.S.S.SS  
 8 .A.A.A.A.A
 9 ..M.M.M.MM
10 .X.X.XMASX
   1234567890

Alleen hier haalt mijn programma al 29 combinaties uit.
Neem als voorbeeld de X linksonder. Daar haal ik deze combinaties uit:

[Afbeelding]

Wat zie ik over het hoofd?

Maar deze zijn toch niet correct? Je moet de woorden vinden als in een kruiswoordpuzzel. In deze voorbeelden lijken ze eerst diagonaal naar rechts te gaan en dan weer naar links voor 1 woord.

[Woy]

@P_Tingen je kunt niet halverwege een XMAS van richting veranderen, dus ik denk dat je code een stuk eenvoudiger kan

[ Voor 27% gewijzigd door Woy op 04-12-2024 09:07 ]

[Mschamp]

P_Tingen schreef op woensdag 4 december 2024 @ 09:04:
Ik lees iets niet goed denk ik. In mijn programma kom ik met de testinvoer al op 61 keer XMAS. Een steekproef in de resultaten laten geen valse positieven zien, dus ik snap iets niet.

Neem het onderste deel van het voorbeeld:

 7 S.S.S.S.SS  
 8 .A.A.A.A.A
 9 ..M.M.M.MM
10 .X.X.XMASX
   1234567890

Alleen hier haalt mijn programma al 29 combinaties uit.
Neem als voorbeeld de X linksonder. Daar haal ik deze combinaties uit:

[Afbeelding]

Wat zie ik over het hoofd?

Zodra je in een richting vertrokken bent, blijf je in dezelfde richting kijken. Het moet in een rechte lijn staan

[P_Tingen]

Ah, daar ga ik dus fout. Dank!

edit:

That's the right answer! You are one gold star closer to finding the Chief Historian. [Continue to Part Two]

[ Voor 68% gewijzigd door P_Tingen op 04-12-2024 09:23 ]

[Corniel]

Een beetje zitten kl#ten bij deel 1 wat wat tijd kostte:

spoiler:

Ik bouwde een buffer op, en als daar XX in stond gooide ik hem leeg...

Deel twee vond ik (net als velen) veel makkelijker, maar ook geniaal gevonden: een X van MAS. Hoe verzin je het...

[bras]

Vreemde bug; de testcase werkt, maar bij de echte opdracht zit ik er maar een paar te hoog. Geen idee welke edge case ik teveel vind. Iemand een idee?

Code in Python

[Janoz]

Soultaker schreef op dinsdag 3 december 2024 @ 17:23:
[...]

Dit zeg je wel maar als ik je code bekijk dan lees je alsnog de hele string in het geheugen, dus dat voordeel is puur theoretisch op dit moment

Klopt, maar ombouwen is relatief triviaal en zou ik pas gaan doen wanneer het nodig zou zijn

[Janoz]

Soultaker schreef op dinsdag 3 december 2024 @ 18:36:
Maar eerst, een pop quiz: wat is het beste statement in een programmeertaal? Fout! Het is goto. Hier is een oplossing met maar liefst 81 goto statements!

Nice, uitgeschreven state machine

[Robbinb1993]

bras schreef op woensdag 4 december 2024 @ 09:39:
Vreemde bug; de testcase werkt, maar bij de echte opdracht zit ik er maar een paar te hoog. Geen idee welke edge case ik teveel vind. Iemand een idee?

Code in Python

Er missen boundary checks voor [x1, y1], [x2, y2] en [x3, y3] om te checken of ze binnen de lines grid liggen.

[Soultaker]

FCA schreef op woensdag 4 december 2024 @ 08:56:
Ja, en nee. In rust heb je een trucje om i.p.v. zowel een cast van isize/i32 naar usize (die niet negatief mogen zijn) als de bound-check >=0 te doen, er usize::MAX bij op te tellen (met wrapping_add), en dan alleen de check aan de bovenkant te hieven doen. En in mijn geval hielp het met debuggen, want een usize::MAX op de verkeerde plek valt een stuk meer op dan een -1 i.p.v. een 1.

Ik ben hier eigenlijk niet echt fan van, omdat de intentie veel minder duidelijk is dan een expliciete range check. Qua performance maakt het ook niet uit want het compileert naar precies dezelfde code: https://gcc.godbolt.org/z/h8Tnc94db (dit is C++ maar praktisch hetzelfde als Rust).

Ik heb ooit lang geleden (in Java 5 denk ik) de n-queens met exceptions voor de bounds checking geprogrammeerd, en er snel achter gekomen dat dat heel veel trager kan zijn.

In het algemeen is het goed advies om exceptions alleen te gebruiken voor uitzonderlijke situaties, en niet als vorm van flow control, aangezien het raisen van exceptions meestal slechtere performance heeft dan het checken van een conditional (al kan de compiler het soms optimaliseren).

Python is een beetje raar in dat ze het tegenovergestelde aanraden, maar Python gebruik je meestal niet als je de performance wil maximaliseren.

bras schreef op woensdag 4 december 2024 @ 09:39:
Vreemde bug; de testcase werkt, maar bij de echte opdracht zit ik er maar een paar te hoog. Geen idee welke edge case ik teveel vind. Iemand een idee?

Code in Python

Hint: in Python is -1 een geldige lijstindex.

[ Voor 11% gewijzigd door Soultaker op 04-12-2024 09:52 ]

[bras]

Robbinb1993 schreef op woensdag 4 december 2024 @ 09:51:
[...]


Er missen boundary checks voor [x1, y1], [x2, y2] en [x3, y3] om te checken of ze binnen de lines grid liggen.

Dat wordt afgevangen via de try/except was de insteek. Maar ben wel benieuwd of er dan een edge case is die daardoor wel geteld wordt. Het is een poging waard.

En tnx Soultaker, dat klinkt inderdaad als een boosdoener, wat afgevangen zou worden met boundary checking.

[ Voor 12% gewijzigd door bras op 04-12-2024 09:54 ]

[Woy]

Soultaker schreef op dinsdag 3 december 2024 @ 18:36:
@Janoz inspireerde me met z'n suggestie van een oplossing die voor willekeurig grote invoer werkt zonder eerst alles in het geheugen te lezen.

Maar eerst, een pop quiz: wat is het beste statement in een programmeertaal? Fout! Het is goto. Hier is een oplossing met maar liefst 81 goto statements!

Het resulterende programma gebruikt een constante hoeveelheid geheugen (ongeveer 1,5 MiB op mijn systeem) ongeacht hoe groot de invoer is. Maar is het ook snel? Ja, best wel!

$ time ./solve2 < aoc-2024-day-03-challenge-2.txt
...33600
...57973

real    0m4.797s
user    0m4.592s
sys     0m0.198s

Part2 kan nog wat efficienter door als je een don't tegen komt naar een andere state te springen die alleen do() probeert te parsen. Dat werkt natuurlijk niet als je in 1 run zowel Part1 als 2 wil doen.

[ Voor 3% gewijzigd door Woy op 04-12-2024 09:55 ]

[Mugwump]

Robbinb1993 schreef op woensdag 4 december 2024 @ 09:51:
[...]


Er missen boundary checks voor [x1, y1], [x2, y2] en [x3, y3] om te checken of ze binnen de lines grid liggen.

Dat wordt deels afgevangen door de except, maar zoals @Soultaker zegt is lijstje[-1] of string[-1] een geldige index. Dus als je gaat zoeken vanaf 0,0 naar links, wat gebeurt er dan?

en om een voorbeeldje te geven, dit gaat een match opleveren.
X..SAM

[ Voor 38% gewijzigd door Mugwump op 04-12-2024 09:57 ]

[Litpho]

Deze opdracht klikte een stuk beter dan die van gisteren. Coordinaten in een HashMap en 8 matrices voor de richtingen in combinatie met Rust's if let Some maakt het goed leesbaar.

De performance is niet geweldig, maar met ongeveer een milliseconde ben ik blij genoeg.

[Mugwump]

Litpho schreef op woensdag 4 december 2024 @ 10:03:
Deze opdracht klikte een stuk beter dan die van gisteren. Coordinaten in een HashMap en 8 matrices voor de richtingen in combinatie met Rust's if let Some maakt het goed leesbaar.

De performance is niet geweldig, maar met ongeveer een milliseconde ben ik blij genoeg.

Ik doe natuurlijk Kotlin, maar ik ben ook vooral wat aan het spelen met features. Vandaag voor de lol wat aan de slag gegaan met extension functions.

spoiler:

Dit om b.v. transpose en rotate operations te bouwen op een List van String, zodat ik enkel een sumOf countSubstring (waarbij je ook occurences van substring.reversed() telt) hoefde te doen op elke String in het lijstje.

Is dat efficiënt? Natuurlijk niet, maar voor iets dat 50ms duurt maak ik me daar niet druk om.

[TrailBlazer]

Soultaker schreef op woensdag 4 december 2024 @ 09:52:
[...]

Ik ben hier eigenlijk niet echt fan van, omdat de intentie veel minder duidelijk is dan een expliciete range check. Qua performance maakt het ook niet uit want het compileert naar precies dezelfde code: https://gcc.godbolt.org/z/h8Tnc94db (dit is C++ maar praktisch hetzelfde als Rust).


[...]

In het algemeen is het goed advies om exceptions alleen te gebruiken voor uitzonderlijke situaties, en niet als vorm van flow control, aangezien het raisen van exceptions meestal slechtere performance heeft dan het checken van een conditional (al kan de compiler het soms optimaliseren).

Python is een beetje raar in dat ze het tegenovergestelde aanraden, maar Python gebruik je meestal niet als je de performance wil maximaliseren.


[...]

Hint: in Python is -1 een geldige lijstindex.

ik heb net even gekeken. In mijn oplossing heb ik voor part 1 47006 waardes gechecked en hiervan genereerden er 516 een exception. Dus iets meer dan 1 % resulteerde in een exception. Ik weet niet wat meer performance kost het checken of ze allemaal in boundary zijn of deze exceptie afhandelen in deze use case.

[Friits]

Als je van een afstandje kijkt, zijn deel 1 en 2 ongeveer hetzelfde. Enige verschil is dat we zoeken:

spoiler:

- naar XMAS vs. MAS,
- in 4 vs. 2 richtingen zoeken,
- in "any" vs. beide richtingen.

Daar kan je variabelen van maken, en dan wordt dit de volledige oplossing:

spoiler:

g, m = open('in.txt').read(), 'SAMX'
for f, l, s in (sum, 4, (1,140,141,142)), (all, 3, (140,142)):
print(sum(f(g[i-x::x][:l] in (m[:l], m[:l][::-1]) for x in s) for i in range(len(g))))

[ Voor 32% gewijzigd door Friits op 04-12-2024 11:19 ]

[breew]

Zo... dag 4 in R... redelijk rechtoe rechtaan.. al kan het vast korter.
vanochtend ook dag2 - deel2 maar even gebruteforced.... dus tot nu toe 8 sterren