Advent of Code 2022

[Marcj]

MatHack schreef op vrijdag 2 december 2022 @ 18:21:
[...]


Ik zou met alle liefde willen kijken, maar volgens mij staat je repo private

Oops, dank je Heb het gefixed!

[Creepy]

Janoz schreef op vrijdag 2 december 2022 @ 18:15:
Voor de vingeroefening ook nog even effectief 2 regels in java.

spoiler:

Er zijn toch maar 3x3 = 9 mogelijkheden dus die tabelletjes zijn zo gemaakt

[code=java]
static final int[] p1 = new int[] {4, 1, 7, 8, 5, 2, 3, 9, 6};
static final int[] p2 = new int[] {3, 1, 2, 4, 5, 6, 8, 9, 7};
[/code]

Vervolgens kun je met wat lambda shizzle alles in 1 regel klaar krijgen waarbij het grootste deel nog het inlezen is (vooral omdat ik het van het classpath haal)

[code=java]
System.out.println(
Files.lines(Paths.get(Objects.requireNonNull(Day2Lazy.class.getResource(file)).toURI()))
.mapToInt(s -> p1[(s.charAt(0)-'A') + 3 * (s.charAt(2) - 'X')]).sum());
[/code]

Voor deel 1 p1 gebruiken en voor deel 2 p2

nice.

[MatHack]

Marcj schreef op vrijdag 2 december 2022 @ 18:26:
[...]

Oops, dank je Heb het gefixed!

M.i is je code goed begrijpbaar/leesbaar.

Voor de beeldvorming: Ik ken Kotlin inhoudelijk niet, maar ben bekend genoeg met een aantal andere talen, en ik kan prima lezen hoe je oplossing werkt. Dat vind ik deels ook het leuke van dit topic/Advent of Code, het zien van oplossingen in andere talen, zeker ook van talen waar ik niet/minder bekend mee ben.

[.oisyn]

Voutloos schreef op donderdag 1 december 2022 @ 13:03:
Even de guru triggeren: Wedden dat @.oisyn de grote dataset niet onder 0.5s kan?

Challenge accepted

[.oisyn]

Haahaha first try

spoiler:

Time: 486929 us
Max: 184028272
Top 3: 549010145

[.oisyn]

313ms met een AVX2 string-to-int conversie

Kan waarschijnlijk nog sneller door niet ieder nummer naar een 32-bits getal te converteren, maar de digits in een 16x16-bits breed AVX2 register te laten staan en die op te tellen, en aan het eind pas de conversie naar een 32-bits getal te doen.

.edit:

spoiler:

Time: 260831 us
Max: 184028272
Top 3: 549010145

261ms . Tijd om naar bed te gaan

[ Voor 17% gewijzigd door .oisyn op 03-12-2022 04:59 ]

[jmerle]

Dag 3 in Python

Ik heb altijd 2 terminals open staan die mijn Python code draaien op de voorbeeld input en de volledige input zodra ik mijn code opsla, maar vandaag kwam ik er pas relatief laat achter dat ik vergeten was om de voorbeeld input te kopiëren naar een lokaal bestand . Gelukkig heb ik de top 100 nog wel gehaald op beide delen (85e/80e), maar ik ben wel 15 plekken gedaald op de algemene ranglijst.

Ook mooi om te zien hoe goed OpenAI's modellen zijn, het schijnt dat de 1e plek op deel 1 (10 seconden ) en de 2e plek op deel 2 geautomatiseerd behaald zijn (zie https://twitter.com/ostwilkens/status/1598458146187628544).

[Dricus]

Dag 3 - Kotlin

Ik was vroeg wakker, dus ben maar meteen klaar gaan zitten om om 6:00 te kunnen beginnen. Ik heb helemaal geen haast gemaakt en rustig gelezen, dus ik ben best tevreden met 9:57 over deel 1 en 7:05 over deel 2.

[Asgardian28]

@jmerle Indrukwekkend!

Die plek 2 deel 2 ook met GPT? Want dat duurde 2 minuten. Misschien met de prompts zitten stoeien?

[jmerle]

Asgardian28 schreef op zaterdag 3 december 2022 @ 07:06:
@jmerle Indrukwekkend!

Die plek 2 deel 2 ook met GPT? Want dat duurde 2 minuten. Misschien met de prompts zitten stoeien?

Zo te zien zijn de 2e plek op deel 1 en de 81e plek op deel 2 ook geautomatiseerd behaald (zie https://twitter.com/max_sixty/status/1598911166465835010), maar is de gegenereerde code voor de 81e plek op deel 2 wel handmatig aangepast om een bug te fixen. Ik denk dat de gegenereerde code voor de 2e plek op deel 2 ook een bug had, maar dat ostwilkens 'm sneller wist te vinden dan max-sixty.

[MatHack]

Vond vandaag makkelijker dan gisteren. Gisteren zat ik toch redelijk vaak te kijken wat is nou rock/paper/scissors en wat wint daar nu van, etc...

[MaNDaRK]

Ben het met je eens @MatHack deze was makkelijker. Die van gister moest ik inderdaad opschrijven

Dag 3 - Python

[Diderikdm]

Prima dagje vandaag! Dag 3 - Python

[ Voor 11% gewijzigd door Diderikdm op 08-12-2022 14:22 ]

[Mschamp]

Dag 3 in C# ook gelukt.
Moeilijkheid valt inderdaad mee vandaag.

[FrankMennink]

Dag 3 in Python

Altijd interessant om te zien hoe veel verschillende wegen er naar Rome leiden

[Swedish Clown]

Dag 3 in Erlang

Eerste oplossing was Maar na een bakkie koffie, uiteindelijk mooi opgeschoond

[breew]

Dag 3 in R

spoiler:

eingelijk weer eens een reden om [code]Reduce()[/code] te gebruiken.. daar word ik altijd blij van

[MrHaas]

Ik heb net als meeste zo te zien de O(n^2) manier gebruikt, maar moet wel O(n*log(n)) kunnen denk ik.
Mocht iemand zin hebben, hier een generator voor grotere cases:

Python:

#!/usr/bin/env python3
import random
import sys
from string import ascii_letters

random.seed(1337)

NUMBER_OF_SETS = 100
LIMITS = [100_000, 500_000]


def generate():
    part_1 = 0
    part_2 = 0

    for n in range(NUMBER_OF_SETS):
        chars = list(ascii_letters)
        random.shuffle(chars)
        common = chars.pop()

        for i in range(3):
            char_set = chars[i * 17 : i * 17 + 17]
            char_set_common = char_set.pop()
            k = random.randint(*LIMITS)
            parts = [
                random.choices(char_set[:8], k=k) + [char_set_common],
                random.choices(char_set[8:], k=k - 1) + [char_set_common, common],
            ]
            random.shuffle(parts[0])
            random.shuffle(parts[1])
            random.shuffle(parts)
            part_1 += ascii_letters.index(char_set_common) + 1
            print("".join(parts[0] + parts[1]))

        part_2 += ascii_letters.index(common) + 1

    print(f"Expected part 1: {part_1}", file=sys.stderr)
    print(f"Expected part 2: {part_2}", file=sys.stderr)


if __name__ == "__main__":
    generate()

[Tubby]

ben een beetje laat begonnen, werd gisteren pas getriggerd, heb mij aangemeld voor de leaderboard en day1 gedaan

https://github.com/tubbynl/adventofcode/

[ElkeBxl]

Dag 3 in Rust

Langer op gedaan dan verwacht maar kwam vooral omdat ik niet goed aan het lezen was

spoiler:

Ik was mijn hoofd al aan het breken op een algoritme hoe ik de 3 matchende rugzakken zou vinden in de hele dataset. Ik had erover gelezen dat ze al geordend waren en dus per 3 al klaar stonden in de input...

[TrailBlazer]

prima te doen. Oplossing is een beetje hetzelfde als de meeste andere gedaan hebben. Ik bereken de uitslag pas aan het eind maar verder niks bijzonders.
https://gitlab.com/NetTin...-/blob/main/day3/task1.py

[.oisyn]

Terwijl jullie met dag 3 bezig zijn ga ik ondertussen nog even door op dag 1.

.oisyn schreef op zaterdag 3 december 2022 @ 03:54:
313ms met een AVX2 string-to-int conversie

Kan waarschijnlijk nog sneller door niet ieder nummer naar een 32-bits getal te converteren, maar de digits in een 16x16-bits breed AVX2 register te laten staan en die op te tellen, en aan het eind pas de conversie naar een 32-bits getal te doen.

.edit:

spoiler:

Time: 260831 us
Max: 184028272
Top 3: 549010145

261ms . Tijd om naar bed te gaan

Enter multitheading: 37472us. 7,4% van de challenge van @Voutloos

.edit: https://github.com/oisyn/Advent2022/tree/master/Problem1
Wel even nog die grote db in de dir gooien.

[ Voor 7% gewijzigd door .oisyn op 03-12-2022 11:23 ]

[Creepy]

.oisyn schreef op zaterdag 3 december 2022 @ 11:07:
Terwijl jullie met dag 3 bezig zijn ga ik ondertussen nog even door op dag 1.


[...]


Enter multitheading: 37472us. 7,4% van de challenge van @Voutloos

.edit: https://github.com/oisyn/Advent2022/tree/master/Problem1
Wel even nog die grote db in de dir gooien.

Maar goed, dag 3 ook weer klaar. Ik merk dat ik Java streams e.d. wel wil gebruiken maar als ik na 10 seconden googlen er niet achter kom hoe ik de boel kan groeperen voor deel 2 ,dan maar gewoon weer een for loop. Met iets als project reactor kan dit wel direct maar alweer geen zin om een hele reactive lib naar binnen te halen: https://github.com/CodeEn...er/aoc/aoc2022/Day03.java

[bertware]

MrHaas schreef op zaterdag 3 december 2022 @ 10:26:
Ik heb net als meeste zo te zien de O(n^2) manier gebruikt, maar moet wel O(n*log(n)) kunnen denk ik.
Mocht iemand zin hebben, hier een generator voor grotere cases:

In python duurt mijn oplossing met sets 5.491s voor part1 en 6.1849s voor part 2, de gegenereerde invoerdata was 170Mb groot.

spoiler:

Mijn eerste oplossing, waarbij ik geen intersect gebruikte maar 2 gesorteerde lijsten en een merge-sort-achtige vergelijking om dubbels te vinden duurde gemiddeld 5.66s. Ben zelf verbaasd over het kleine verschil op de relatief grote dataset, dacht dat de sort() en handmatige vergelijking veel meer tijd zou kosten dan een insert.

De oude (merge-sort achtige) code die op elke lijn voor part 1 werd uitgevoerd:

comp1 = line[0:len(line) // 2]
comp2 = line[len(line) // 2:len(line) - 1]
comp1 = {char for char in comp1}
comp1 = list(comp1)
comp1.sort()
comp2 = {char for char in comp2}
comp2 = list(comp2)
comp2.sort()
j = 0
for i in range(0, len(comp1)):
    while j < len(comp2) and comp1[i] > comp2[j]:
        j += 1
    if j < len(comp2) and comp1[i] == comp2[j]:
        scoreToAdd = get_score(comp1[i])
        score += scoreToAdd

Code: https://github.com/Bertwa...22/blob/master/advent3.py

[ Voor 3% gewijzigd door bertware op 03-12-2022 12:40 ]

[TrailBlazer]

spoiler:

Bij deel twee vind ik het wel apart dat er meerdere groepen zijn met dezelfde badge.

[eheijnen]

Er staan 300 regels in de input / 3 = 100 groepen
Er zijn 52 mogelijk types [a..Z]

[Woy]

Ik ben er ook maar weer eens aan begonnen, maar ook dit jaar zal ik rond dag 20 wel weer afhaken omdat ik dan echt geen tijd meer heb

https://github.com/rverst.../blob/main/Y2022/Day01.cs
https://github.com/rverst.../blob/main/Y2022/Day02.cs
https://github.com/rverst.../blob/main/Y2022/Day03.cs

Ieder geval even dag 1 t/m 3 gedaan, allemaal gewoon op de easy manier.

[DataGhost]

MrHaas schreef op zaterdag 3 december 2022 @ 10:26:
Ik heb net als meeste zo te zien de O(n^2) manier gebruikt, maar moet wel O(n*log(n)) kunnen denk ik.
Mocht iemand zin hebben, hier een generator voor grotere cases:

Python:

#!/usr/bin/env python3
import random
import sys
from string import ascii_letters

random.seed(1337)

NUMBER_OF_SETS = 100
LIMITS = [100_000, 500_000]


def generate():
    part_1 = 0
    part_2 = 0

    for n in range(NUMBER_OF_SETS):
        chars = list(ascii_letters)
        random.shuffle(chars)
        common = chars.pop()

        for i in range(3):
            char_set = chars[i * 17 : i * 17 + 17]
            char_set_common = char_set.pop()
            k = random.randint(*LIMITS)
            parts = [
                random.choices(char_set[:8], k=k) + [char_set_common],
                random.choices(char_set[8:], k=k - 1) + [char_set_common, common],
            ]
            random.shuffle(parts[0])
            random.shuffle(parts[1])
            random.shuffle(parts)
            part_1 += ascii_letters.index(char_set_common) + 1
            print("".join(parts[0] + parts[1]))

        part_2 += ascii_letters.index(common) + 1

    print(f"Expected part 1: {part_1}", file=sys.stderr)
    print(f"Expected part 2: {part_2}", file=sys.stderr)


if __name__ == "__main__":
    generate()

Zo, weekend en inderdaad vandaag kan het al stuk Voor mij was O(n*log(n)) de "naïeve" oplossingsrichting, misschien heb ik dit te vaak gedaan. Maar ik begon het topic bij te lezen en zag als eerste de code van @jmerle dus heb direct ook een grote test-input gemaakt. Niet met zo'n hele generator zoals jij maar ik keek gewoon naar de code / het algoritme en daarmee was het heel makkelijk een worst-case input te maken met een simpele

$ python3 -c 'for a, b in ["ab", "cd", "ef"]: print(a*1000000+"X"+b*1000000+"X")' > 3.in.groot

Omdat ik hem toch al gemaakt had staat 'ie op https://dataghost.com/aoc/2022/3.in.groot.gz met als uitkomst dus resp. 150 en 50 voor beide delen. Mijn algoritme was er in 0.1s mee klaar terwijl die met de code van @jmerle bijna 26 seconden bezig was op deel 1, deel 2 niet getest maar het zal niet sneller zijn.

Ook mijn code dan maar: https://gitlab.dataghost....ent-of-code/-/snippets/31

[Velvet]

Ik doe dit jaar voor het eerst mee, in Python, want dat ben ik recent gaan leren. Erg leuk om elke dag even wat te kunnen oefenen. Ik doe niet competitief mee, dus ik sta niet extra vroeg op, en zie wel hoe ver ik kom.
Tot nu toe smaakt het naar meer
Ook leuk om te zien hoe anderen het aanpakken.

[ Voor 9% gewijzigd door Velvet op 06-12-2022 21:38 ]

[Beneveerg]

Dag 3 ging mij een stuk beter af als dag 1 en 2. Ik heb vooral even gedaan over de letters en getallen

spoiler:

het uitschrijven van 52 waarde leek mij wat overdreven, dat is gelukt met ord()

[jmerle]

DataGhost schreef op zaterdag 3 december 2022 @ 13:18:
[...]

Zo, weekend en inderdaad vandaag kan het al stuk Voor mij was O(n*log(n)) de "naïeve" oplossingsrichting, misschien heb ik dit te vaak gedaan. Maar ik begon het topic bij te lezen en zag als eerste de code van @jmerle dus heb direct ook een grote test-input gemaakt. Niet met zo'n hele generator zoals jij maar ik keek gewoon naar de code / het algoritme en daarmee was het heel makkelijk een worst-case input te maken met een simpele

$ python3 -c 'for a, b in ["ab", "cd", "ef"]: print(a*1000000+"X"+b*1000000+"X")' > 3.in.groot

Omdat ik hem toch al gemaakt had staat 'ie op https://dataghost.com/aoc/2022/3.in.groot.gz met als uitkomst dus resp. 150 en 50 voor beide delen. Mijn algoritme was er in 0.1s mee klaar terwijl die met de code van @jmerle bijna 26 seconden bezig was op deel 1, deel 2 niet getest maar het zal niet sneller zijn.

Ook mijn code dan maar: https://gitlab.dataghost....ent-of-code/-/snippets/31

spoiler:

Mijn focus ligt dit jaar volledig op de leaderboard i.p.v. efficiënte of nette code, maar ik was toch benieuwd waardoor mijn code zo ontiegelijk lang doet over "maar" 6 MB aan input. Zo te zien loopt mijn code in deel 1 vooral langzaam in het checken of een karakter van de eerste helft ook in de tweede helft zit (of in de 2e en 3e lijn in de groep voor deel 2). Met minimale wijzigingen draaien mijn twee delen ook in 0.1s op 3.in.groot: https://gist.github.com/j...7827968fa36639ead16d1cc91

[Remcoder]

TrailBlazer schreef op zaterdag 3 december 2022 @ 12:39:

spoiler:

Bij deel twee vind ik het wel apart dat er meerdere groepen zijn met dezelfde badge.

spoiler:

Als alle badges uniek moeten zijn wordt je dataset wel klein. Maximaal 153 regels dan maar als je ook nog verschillende uitkomsten wil hebben.

Ik kijk ook zelden tot nooit naar de dataset.

[MrHaas]

Ook mooi om te zien hoe goed OpenAI's modellen zijn, het schijnt dat de 1e plek op deel 1 (10 seconden ) en de 2e plek op deel 2 geautomatiseerd behaald zijn (zie https://twitter.com/ostwilkens/status/1598458146187628544).

Ja, bizar, net ff zelf mee gespeeld op https://chat.openai.com/chat door er gewoon de hele AoC tekst in te plakken. Je krijgt beknopte samenvatting van het probleem met hele lappen voorbeeldcode die grotendeels klopt.

[Janoz]

Creepy schreef op zaterdag 3 december 2022 @ 11:59:
[...]



Maar goed, dag 3 ook weer klaar. Ik merk dat ik Java streams e.d. wel wil gebruiken maar als ik na 10 seconden googlen er niet achter kom hoe ik de boel kan groeperen voor deel 2 ,dan maar gewoon weer een for loop. Met iets als project reactor kan dit wel direct maar alweer geen zin om een hele reactive lib naar binnen te halen: https://github.com/CodeEn...er/aoc/aoc2022/Day03.java

Ik had exact hetzelfde. Ook bij dag 1 werd er al geaggregeerd. Ben net even een half uurtje bezig geweest of er ook iets voor was, maar kom toch uit op een tussenliggende itterator oid. Sowieso wil ik mijn 'AoC frameworkje' even een leuke refactor geven. Ik merk dat ik toch nog relatief veel aan het boilerplaten ben telkens.

[Wraldpyk]

Dag 3 in JavaScript. Vond vandaag ook makkelijker als gisteren!

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

[DataGhost]

jmerle schreef op zaterdag 3 december 2022 @ 13:46:
[...]

spoiler:

Mijn focus ligt dit jaar volledig op de leaderboard i.p.v. efficiënte of nette code, maar ik was toch benieuwd waardoor mijn code zo ontiegelijk lang doet over "maar" 6 MB aan input. Zo te zien loopt mijn code in deel 1 vooral langzaam in het checken of een karakter van de eerste helft ook in de tweede helft zit (of in de 2e en 3e lijn in de groep voor deel 2). Met minimale wijzigingen draaien mijn twee delen ook in 0.1s op 3.in.groot: https://gist.github.com/j...7827968fa36639ead16d1cc91

Waarom gebruik je voor de eerste helft niet

spoiler:

ook een set? Je kan deze opgave compleet zonder loops doen als je de door de library reeds gegeven standaardcontainers gebruikt. Maakt het verder qua looptijd niet sneller want nu heb je ook gewoon O(n*log(n)) op een iets andere manier, maar het is misschien eenvoudiger coden. Je gaat deze containers nog veeeeeeeel vaker nodig hebben deze maand dus je kan er beter alvast mee oefenen in de eerste week

Edit: looptijd klopt volgens mij niet, even rekenen, moment.
Edit2: oh nee toch wel, diff verkeerd gelezen.
Edit3: ook voor leaderboard ipv efficientie besparen de standaardcontainers je een hele bult code, je had de loops bijvoorbeeld niet uit hoeven typen want dat kan met sets gewoon in 1 operatie.

[ Voor 12% gewijzigd door DataGhost op 03-12-2022 14:47 ]

[gedonie]

Zo ik had niet eens door dat de AoC al bezig was. Heb gelijk maar even alle drie de dagen vandaag gedaan in Java. Hier dag 3: https://github.com/gjong/...e/main/src/main/java/day3.

Moet wel zeggen dat dag 1 en 2 weer erg makkelijk waren dit jaar.

[Tubby]

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


***members only***


@P_Tingen ^

Leuk!, heb mijn day1 oplossing (Java) hier tegenaan gezet en die deed er 43sec over. Heb eraan zitten schaven en nu zit ik op 2.9s

[.oisyn]

Tubby schreef op zaterdag 3 december 2022 @ 20:32:
[...]


Leuk!, heb mijn day1 oplossing (Java) hier tegenaan gezet en die deed er 43sec over. Heb eraan zitten schaven en nu zit ik op 2.9s

Je bent er dus nog lang niet

[YoToP]

DataGhost schreef op zaterdag 3 december 2022 @ 14:43:
[...]

Waarom gebruik je voor de eerste helft niet

spoiler:

ook een set?

Goeie tip, ik ben van dit naar dit gegaan.

En daarmee kan ik ook 3.in.groot in 76ms draaien

[Tubby]

.oisyn schreef op zaterdag 3 december 2022 @ 20:39:
[...]
Je bent er dus nog lang niet

Lol ja, maar t blijft Java eh

Maar wil ook nog opdracht 3 maken zodat ik morgen vers aan 4 kan beginnen

[Barin]

Ben vandaag maar eens een klein inhaalslagje gemaakt, in Julia.

Een naïeve implementatie doet over de grote dataset van vandaag 54ms en 39ms voor respectievelijk deel 1 en 2; valt me niets tegen.

De grote dataset van dag 1 enigszins optimaal verwerkt krijgen daarentegen:

spoiler:

9 seconden voor een simpele readline implementatie. Alles als blob werkt sneller met inlezen, maar alle tijd gaat dan in het splitten van de string(s) en regel voor regel parsen zitten. Alle fancy packages voegen enkel tijd toe. Komende dagen nog eens op terugkomen om te zien hoe snel Julia daar te krijgen is met preallocation en een dommere parser.

https://github.com/MHoogesteger/AoC

[jmerle]

DataGhost schreef op zaterdag 3 december 2022 @ 14:43:
[...]

Waarom gebruik je voor de eerste helft niet

spoiler:

ook een set? Je kan deze opgave compleet zonder loops doen als je de door de library reeds gegeven standaardcontainers gebruikt. Maakt het verder qua looptijd niet sneller want nu heb je ook gewoon O(n*log(n)) op een iets andere manier, maar het is misschien eenvoudiger coden. Je gaat deze containers nog veeeeeeeel vaker nodig hebben deze maand dus je kan er beter alvast mee oefenen in de eerste week

Edit: looptijd klopt volgens mij niet, even rekenen, moment.
Edit2: oh nee toch wel, diff verkeerd gelezen.
Edit3: ook voor leaderboard ipv efficientie besparen de standaardcontainers je een hele bult code, je had de loops bijvoorbeeld niet uit hoeven typen want dat kan met sets gewoon in 1 operatie.

spoiler:

In de diff die ik linkte gebruik ik geen set in de eerste helft omdat dat qua performance weinig uitmaakt en ik het bij "minimale wijzigingen" wilde houden. Vanochtend had het inderdaad een stuk korter gekunt, je hebt gelijk dat daar nog tijdswinst te behalen valt. Waarom ik vanochtend niet op set intersection uitkwam weet ik eigenlijk ook niet, normaal schuw ik Python's stdlib niet zo.

[Voutloos]

.oisyn schreef op zaterdag 3 december 2022 @ 11:07:
Enter multitheading: 37472us. 7,4% van de challenge van @Voutloos

.edit: https://github.com/oisyn/Advent2022/tree/master/Problem1

Je eerste versie zat niet zo gek ver van de genoemde 0.5s, maar nu ben je weer lekker aan het overdrijven.

[Visitor.q]

Vandaag was leuk, en daagde me uit om regex wat beter in de vingers te krijgen. Toen ik dat eenmaal door had was het goed te doen. Ik ging eerst de mist in omdat ik dacht dat uppercase en lowercase elkaar opvolgden bij het toekennen van priorities, en daar moest ik iets voor bedenken. Uiteindelijk

spoiler:

ben ik gegaan voor het aanmaken van een string met 2 keer het hele alfabet (lowercase+uppercase), en die matchen met het gevonden item

.

Members only: oplossing dag 3

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Swedish Clown]

Toch leuk om af en toe de gelegenheid te pakken en weer wat meer inzicht te krijgen in Erlang Zelfs na al die jaren in de Erlang wereld blijf je je af en toe verbazen over waar precies de verschillen kunnen zitten.

lists:split/2 vs split_binary/2

Resultaat: grofweg 50% sneller dan mijn oorspronkelijke oplossing

[Camulos]

Deel 3 was mooie snack altijd leuk om met Characters te klooien.
In C# is het vrij straightforward om van een Char naar een Int te gaan; ergo het sommeren is een zoals dit:

code:

sum += char.IsUpper(line[i]) ? (line[i] - 'A' + 27) : (line[i] - 'a' + 1);

Verder hashmaps gebruikt om te filteren

@Woy heel nice zoals jij LINQ statements gebruikt

[YoToP]

Les van gisteren kwam vandaag goed van pas. Lekker snel klaar.
link naar code

[jmerle]

Dag 4 in Python

spoiler:

Vandaag een stuk langer gelezen dan nodig was. Ik kwam weer niet op het idee om sets te gebruiken

[Dricus]

Dag 4 - Kotlin

Vooralsnog vond ik de puzzels erg goed te doen, ook vandaag. Ik maak nu gebruik van Kotest voor unit testing. Ik kwam het tegen op de Thoughtworks Tech Radar, dus ben dat met AoC maar eens aan het uitproberen. Best geinig dat je daarmee super compacte tests kunt schrijven. Dit is een unit test class met 4 tests:

Kotlin:

class Day04Test : StringSpec({
    "example part 1" { ::solution1 invokedWith exampleInput shouldBe 2 }
    "part 1 solution" { ::solution1 invokedWith input(YEAR, DAY) shouldBe 532 }
    "example part 2" { ::solution2 invokedWith exampleInput shouldBe 4 }
    "part 2 solution" { ::solution2 invokedWith input(YEAR, DAY) shouldBe 854 }
})

De infix assertions vind ik ook wel fijn om te gebruiken.

[Woy]

Dag 4 was weer goed te doen ook:
https://github.com/rverst.../blob/main/Y2022/Day04.cs

[Diderikdm]

Goed slaapdronken dus begrijpend lezen was de lastigste taak vandaag

Dag 4 - Python

[ Voor 8% gewijzigd door Diderikdm op 08-12-2022 14:22 ]

[TrailBlazer]

even uittekenen hielp me we wel.

spoiler:

ik was eerst vergeten te converteren naar int dat ging goed met het sample omdat daar alles onder de 10 is, maar niet met de de puzzel input. Niet gekozen voor sets omdat dat misschien te veel geheugen nodig had als in een keer die secties enorm werden

[coop]

Ook weer begonnen dit jaar. Vorig jaar 17 dagen volbracht. Ga voor meer dit jaar.

Dag 4 in Python.

[Cranzai]

Toch jammer dat vandaag eigenlijk een rehash was van gisteren. In het weekend heb ik wel tijd om te puzzelen dus doe me dan maar iets moeilijks

[breew]

Dag 4 in R, nog steeds appeltje eitje. Wel jammer, had graga langer gepuzzeld. Nu moet ik van mezelf de hond uitlaten en daar had ik nog geen zin in, want koud ;-)

spoiler:

Ergens wel jammer dat part 1 precies dezelfde oplossing had als part 2, maar dan met een paar <= , >= omgekeerd..

[ Voor 54% gewijzigd door breew op 04-12-2022 09:07 ]

[Swedish Clown]

Dag 4 in Erlang

Toch jammer dat het parsen van de input het grootste deel van de tijd in beslag neemt 84% van de tijd word in beslag genomen door het preppen van de input.

[Mschamp]

Dag 4 in C#

Beetje opletten met de symbooltjes zo vroeg in een ochtend, maar eigenlijk niet zo een moeilijke puzzel.

[Visitor.q]

Members only: Dag 4 in Python

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Het is voor mij altijd wat gedoe om zo'n tabel mooi in het geheugen te krijgen. Toen het eenmaal arrays waren was het zo gepiept.

[FrankMennink]

Dag 4 in Python

Eerst op de naive manier gedaan, daarna iets vriendelijker voor het geheugen

spoiler:

Naief door de twee sets op de ranges aan te maken en ze te subtracten en dan kijken wat er overblijft. Werkt prima voor kleine gevallen maar als er ineens een paar miljard getallen in het geheugen worden gedumpt zal t niet heel fijn zijn. Daarna omgebouwd naar een boundary check waarbij alleen de gegeven getallen met elkaar vergeleken worden

[eheijnen]

Swedish Clown schreef op zondag 4 december 2022 @ 09:24:
Dag 4 in Erlang

Toch jammer dat het parsen van de input het grootste deel van de tijd in beslag neemt 84% van de tijd word in beslag genomen door het preppen van de input.

In C-Scherp
De eerste is de gemakkelijkste maar ook de traagste.

Als ik de grote file van day_01 in een keer inlees: ca. 11 - 12 Sec

C#:

string[] s = System.IO.File.ReadAllLines( "aoc_2022_day01_large_input.txt" );

Als ik het bestand regel voor regel doorloop in een loop dan is het ca. 2,2 sec

C#:

StreamReader sr = new( "aoc_2022_day01_large_input.txt", System.Text.Encoding.ASCII );

while ( ( line = sr.ReadLine() ) != null ) { 
....
}

EDIT:
Nog even wat verder gekeken naar de .NET source naar die ReadAllLines(...)
Waarbij er eerst naar een List<> wordt geschreven. Als laatste een return met een conversie naar string[].

C#:

public static string[] ReadAllLines( string path, Encoding encoding )
{
    Validate( path, encoding );

    string? line;
    List<string> lines = new List<string>();

    using StreamReader sr = new StreamReader(path, encoding);

    while ( ( line = sr.ReadLine() ) != null ) {
        lines.Add( line );
    }

    return lines.ToArray();
}

[ Voor 24% gewijzigd door eheijnen op 04-12-2022 12:20 ]

[Creepy]

Dag 4 was inderdaad weer makkelijk idd.
https://github.com/CodeEn...er/aoc/aoc2022/Day04.java

[Reptile209]

Tot nu toe alle opgaven in Excel (meestal native, eentje met VBA erbij) opgelost. Bij Day 4 zat ik in eerste instantie te hoog, terwijl de testinput klopte. Met de hand alles nagelopen, en vanaf pair 40 ofzo zaten er opeens foutjes in...

spoiler:

Ik had TEXTSPLIT() gebruikt om de input te splitten in de losse getallen van de twee ranges. Maar dan is het resultaat nog steeds een string, dus doet Excel bij iets als =A1>=B2 een compare op basis van strings en niet op basis van de values. Dat ging blijkbaar heel lang goed, tot op een bepaald punt... Overal VALUE() omheen en opgelost, maar duurde effe voordat ik hem door had

[Creepy]

jmerle schreef op zondag 4 december 2022 @ 07:05:
Dag 4 in Python

spoiler:

Vandaag een stuk langer gelezen dan nodig was. Ik kwam weer niet op het idee om sets te gebruiken

Die zijn dan ook echt niet nodig Je oplossing is prima zo toch?

[MaNDaRK]

Zo, daar ging ik even de mist in met de range en set functie van Python.

Laten we het er maar op houden dat ik nog niet helemaal wakker ben

Day 4 - Python

[.oisyn]

eheijnen schreef op zondag 4 december 2022 @ 10:38:
[...]

In C-Scherp
De eerste is de gemakkelijkste maar ook de traagste.

Als ik de grote file van day_01 in een keer in lees: ca. 11 - 12 Sec

C#:

string[] s = System.IO.File.ReadAllLines( "aoc_2022_day01_large_input.txt" );

Als ik het bestand regel voor regel doorloop in een loop dan is het ca. 2,2 sec

C#:

StreamReader sr = new( "aoc_2022_day01_large_input.txt", System.Text.Encoding.ASCII );

while ( ( line = sr.ReadLine() ) != null ) { 
....
}

En dan nu als een memory mapped file

[eheijnen]

.oisyn schreef op zondag 4 december 2022 @ 11:06:
[...]

En dan nu als een memory mapped file

Ik heb in jouw code zitten neuzen maar dat zal nog even duren.
Maar ga ik zeker nog eens naar kijken.

[Soultaker]

Ik had wel op een iets grotere uitdaging gehoopt in het weekend. Tot nu toe ben ik meer tijd kwijt aan het lezen van de opdracht en het parsen van de invoer dan het nadenken over/implementeren van een oplossing.

[MueR]

Hier ook dag 4 weer af.

[.oisyn]

eheijnen schreef op zondag 4 december 2022 @ 11:13:
[...]

Ik heb in jouw code zitten neuzen maar dat zal nog even duren.
Maar ga ik zeker nog eens naar kijken.

Nou ja ik ga natuurlijk los met AVX2 maar wat je iig wil doen is de file openen als memory mapped file en direct op die data werken ipv allemaal string objecten zitten te maken. Je zult dan wel zelf op zoek moeten naar de newlines en de regels omzetten naar getallen.

[eheijnen]

.oisyn schreef op zondag 4 december 2022 @ 11:20:
[...]
Nou ja ik ga natuurlijk los met AVX2 maar wat je iig wil doen is de file openen als memory mapped file en direct op die data werken ipv allemaal string objecten zitten te maken. Je zult dan wel zelf op zoek moeten naar de newlines en de regels omzetten naar getallen.

Dan vraag ik me af, dat ik heb een gewone SSD heb die 550 MB/s sequentieel kan lezen.
Als jij zulk soort tijden kunt realiseren heb jij dan een NVME schijf?

[CMG]

Mijn 4 dagen (Reddit solution thread; voor wie het leuk vind, zijn daar ook de links naar de streams):

Dag 1
Dag 2
Dag 3
Dag 4

Ik ben net zoals de vorige paar jaren de dagen elke dag weer aan het livestreamen, maar ik doe het pas nadat ik de kids naar school heb gebracht, etc, dus geen race om de snelste 😅

Tot nu toe zijn de weekend dagen nog het makkelijkst😅 ben gewend van voorgaande jaren dat de tasks voor het weekend wat meer tijd kosten, maar dag 3 en 4 gingen voor mij sneller dan dag 1 en 2 😅

[Soultaker]

eheijnen schreef op zondag 4 december 2022 @ 11:31:
Dan vraag ik me af, dat ik heb een gewone SSD heb die 550 MB/s sequentieel kan lezen.
Als jij zulk soort tijden kunt realiseren heb jij dan een NVME schijf?

Je besturingssysteem cachet de inhoud van bestanden, dus als je benchmarkt met een bestand van ~100 MB zoals hier, dan zal het bestand na de eerste executie volledig in RAM staan en maakt de snelheid van de vaste schijf niet uit.

Na een reboot of met bestanden die zo groot zijn dat ze niet in het geheugen passen zal disk I/O inderdaad de bottleneck gaan vormen bij dit soort problemen.

[CMG]

Wat me wel opvalt is dat een hoop mensen niet weten dat je voor 'enige overlap' maar 2 checks hoeft te doen; had het aan het eind van de video met een crappy MS-Paint actie nog even gevisualiseerd hoe je dat makkelijk kunt doen voor de gene die daar behoefte aan hebben 😊

[gedonie]

Dag 4 in Java was goed te doen: https://github.com/gjong/...e/main/src/main/java/day4.

Moest wel even goed opletten dat ze per regel de overlap wilde weten en niet over het geheel .

[eheijnen]

Soultaker schreef op zondag 4 december 2022 @ 11:42:
[...]

Je besturingssysteem cachet de inhoud van bestanden, dus als je benchmarkt met een bestand van ~100 MB zoals hier, dan zal het bestand na de eerste executie volledig in RAM staan en maakt de snelheid van de vaste schijf niet uit.

Na een reboot of met bestanden die zo groot zijn dat ze niet in het geheugen passen zal disk I/O inderdaad de bottleneck gaan vormen bij dit soort problemen.

Dat was idd de redenering die ik volgde...

[TrailBlazer]

CMG schreef op zondag 4 december 2022 @ 11:45:
Wat me wel opvalt is dat een hoop mensen niet weten dat je voor 'enige overlap' maar 2 checks hoeft te doen; had het aan het eind van de video met een crappy MS-Paint actie nog even gevisualiseerd hoe je dat makkelijk kunt doen voor de gene die daar behoefte aan hebben 😊

Ik had ook maar even een tekening gemaakt voor mezelf en toen bleek de logic heel simpel te zijn inderdaad.

[Glewellyn]

Toch fijn om te lezen dat anderen ook waren vergeten

spoiler:

te converteren naar int

voel ik me toch weer een beetje minder dom.

[Basje]

Leuke puzzel weer. Het duurde met name even voordat ik de parsing op orde had. Daarna was het vrij snel opgelost. Lang leve Linq: Day 4 in C#.

[eheijnen]

Achteraf gezien.
Hoef je voor deel 2 alleen die te tellen die helemaal geen overlap hebben.
Dat waren er 91 van de 1000 regels.

[Remcoder]

CMG schreef op zondag 4 december 2022 @ 11:45:
Wat me wel opvalt is dat een hoop mensen niet weten dat je voor 'enige overlap' maar 2 checks hoeft te doen; had het aan het eind van de video met een crappy MS-Paint actie nog even gevisualiseerd hoe je dat makkelijk kunt doen voor de gene die daar behoefte aan hebben 😊

Wat dan als je de volgende case hebt:

code:

        <-->
<-->

Dan ligt het eindpunt van de bovenste lijn wel na het beginpunt van de onderste lijn, maar er is géén overlap. Volgens de check die jij doet is er dan wel overlap. Tenzij ik iets verkeerd begrijp.

[Creepy]

Het startpunt van de bovenste lijn ligt niet voor het eindpunt van de onderste lijn, dus is er geen overlap. Dus ook die situatie gaat goed.

spoiler:

start1 <= end2 && start2 <= end1

[Soultaker]

Remcoder schreef op zondag 4 december 2022 @ 12:05:
[...]

Wat dan als je de volgende case hebt:

code:

        <-->
<-->

Dan ligt het eindpunt van de bovenste lijn wel na het beginpunt van de onderste lijn, maar er is géén overlap. Volgens de check die jij doet is er dan wel overlap. Tenzij ik iets verkeerd begrijp.

Het is makkelijker om je eerst af te vragen wanneer er géén overlap is. Stel we noemen de coordinaten a, b, c, d (met a ≤ b en c ≤ d). Dan zijn er precies twee mogelijkheden om geen overlap te hebben:

a--b
       c--d

en

       a--b
c--d

In het eerste geval geldt b < c en in het tweede geval d < a. Er is dus geen overlap als (b < c || d < a), en dus wél overlap als !(b < c || d < a). Die expressie kun je vereenvoudigen:

1. !(b < c || d < a)
2. !(b < c) && !(d < a) (De Morgan's law)
3. b >= c && d >= a

en dat is precies de check die @CMG (en ik) gebruiken.

edit:
Een andere manier om het te beredeneren, puur logisch zonder te visualiseren, is de observatie dat als er overlap is tussen a-b en c-d, dan is er een punt x zodat a <= x <= b en c <= x <= d. Dat is equivalent aan a, b <= x <= c, d. En dat is equivalent aan a <= c && a <= d && b <= c && b <= d. Van die vier clausules waren a <= b en c <= d al gegeven, dus blijft a <= d && b <= c over .

[ Voor 27% gewijzigd door Soultaker op 04-12-2022 12:29 ]

[Beneveerg]

Ik loop vast op Dag 4 het eerste deel. Mijn code doet echter wel wat ik wil.

Zoals ik de opgave begrijp willen we weten bij hoeveel paren de eerste sectie volledig in de tweede sectie valt en andersom. Mijn code doet dat maar toch heb ik een te hoog antwoord,

/edit

ah daar zit dus gelijk de denkfout. Blijkbaar werkt opschrijven.

[ Voor 12% gewijzigd door Beneveerg op 04-12-2022 12:26 ]

[.oisyn]

eheijnen schreef op zondag 4 december 2022 @ 11:48:
[...]

Dat was idd de redenering die ik volgde...

Maar dat is het niet alleen. Met een memory mapped file zie je direct het geheugen dat door de kernel wordt gebruikt om de file te lezen. De cache is natuurlijk een enorm voordeel, omdat het enige dat dan hoeft te gebeuren is het mappen van de betreffende pages in de address space van je proces. Maar ook als de data nog van disk moet komen is het een voordeel, omdat je direct met de betreffende data werkt ipv dat het eerst nog gekopieerd wordt naar user space en who knows wat er daarna nog mee gebeurt in het framework wat je gebruikt.

In jouw geval, waarbij je Strings gebruikt in .Net, dan zal de textuele data geconverteerd worden naar UTF-16 in een voor de string gealloceerde buffer. En sowieso als je de file opent als tekst dan zullen allle Windows newlines (\r\n) geconverteerd worden naar enkele newlines (\n). Er gaat dus zo ontzettend veel processing overheen voordat je überhaupt iets met de data doet. Het converteren van string naar int zal ook wel de nodige locale settings gebruiken, die die UTF-16 data van een String dan weer juist moet interpreteren (terwijl je al weet dat de input plain old ascii is), etc.

[ Voor 9% gewijzigd door .oisyn op 04-12-2022 12:37 ]

[eheijnen]

@Beneveerg
Het linker deel kan in het rechter deel liggen maar ook andersom...
1-1,2-2
of
2-2,1-1

[Beneveerg]

eheijnen schreef op zondag 4 december 2022 @ 12:32:
@Beneveerg
Het linker deel kan in het rechter deel liggen maar ook andersom...
1-1,2-2
of
2-2,1-1

Zo ver was ik. Maar daar maakte ik ook gelijk de denkfout

spoiler:

Ik controleerde of het eerste deel in het tweede ligt én of het tweede deel in het eerste ligt. Dan krijg je bij twee gelijke delen een dubbele positieve uitkomst

[eheijnen]

Beneveerg schreef op zondag 4 december 2022 @ 12:34:
[...]


Zo ver was ik. Maar daar maakte ik ook gelijk de denkfout

spoiler:

Ik controleerde of het eerste deel in het tweede ligt én of het tweede deel in het eerste ligt. Dan krijg je bij twee gelijke delen een dubbele positieve uitkomst

Als de eerste een match is hoef je niet meer verder te zoeken
Dan stopt de if ook door de || omdat al aan de conditie is voldaan:

spoiler:

//full overlap
( nLeftLeft >= nRightLeft && nLeftRight <= nRightRight ) ||
( nRightLeft >= nLeftLeft && nRightRight <= nLeftRight ) )

[Trasos]

Wellicht leuk voor degenen die tijd over hebben, en geïnteresseerd zijn in Vue.js: Advent of Vue. https://www.getrevue.co/profile/AdventOfVue

[jmerle]

Creepy schreef op zondag 4 december 2022 @ 11:00:
[...]

Die zijn dan ook echt niet nodig Je oplossing is prima zo toch?

In dit geval maakt het inderdaad weinig uit

[Wraldpyk]

Dit was een leuke! Moest even nadenken waarom ik meer matches had als dat nodig was.

Hier is mijn oplossing in JavaScript https://github.com/Topene...blob/2022/day4/program.js

[Daos]

Wraldpyk schreef op zondag 4 december 2022 @ 16:32:
Dit was een leuke! Moest even nadenken waarom ik meer matches had als dat nodig was.

Hier is mijn oplossing in JavaScript https://github.com/Topene...blob/2022/day4/program.js

Dat is een creatieve oplossing voor het eerste deel (bij deel twee kan je ook met array's werken; functie om die te maken heb je al).

Een kleine tip:

spoiler:

In plaats van indexOf en dan kijken of het resultaat ongelijk is aan -1 kan je ook includes gebruiken (een array heeft die ook)

[ElkeBxl]

Dag 4 in Rust

Eens op papier uittekenen om overzicht te houden hielp wel voor deel 2

[Ghehe]

Ik doe dit jaar ook nog eens mee (eerste en laatste keer was in 2015 zo blijkt ) en wederom in Perl.

Wel interessant vond ik het gedrag van Perl met het 500MB bestand van dit topic voor dag 1. Daar was mijn implementatie met "map { ... } <>" een 20 seconden trager (34s) dan de implementatie met "while(<>) {...}" (12s). Nu is dat waarschijnlijk omdat "map" een returnvalue wil teruggeven maar ik had niet verwacht dat het 12GB geheugen ging gebruiken om dat te voltrekken (met de bijhorende traagheid) Als het morgen nog een gemakkelijk dagje is, ga ik er een profiler aan hangen om te kijken wat die allemaal uitspookt achter de schermen.

[ Voor 6% gewijzigd door Ghehe op 10-12-2022 23:39 ]

[Gurbuh]

Doe voor het eerst mee, vandaag dag 1 tm 4 gedaan. Leuke uitdaging. Ik doe C#/.NET.

Dag 4 deel 2 was het lastigst imo, misschien even moeten tekenen inderdaad maar opende het topic pas na de tijd om spoilers te voorkomen. Heb nu niet de meest optimale optie denk ik:

spoiler:

Alle getallen in beide ranges uitgenereren met Enumerable.Range en daarna met .Intersect checken of er overlap is

[Tubby]

leuk. ben nu "bij", dag 4 deel 2 was idd even lastig, maar vooral omdat m'n eerste route doodliep, heb uiteindelijk gewoon sets gebakken van die ranges.

wel lekker aan het spelen met junit5 en var/intStreams enzo

https://github.com/tubbyn...ubby/aoc/SectionTest.java

[jmerle]

Dag 5 in Python

spoiler:

Mijn input downloader trimde de whitespace aan voor- en achterkant, dus de eerste regel die ik inlas kwam niet overeen met de daadwerkelijke input. Helaas kwam ik daar pas na 2 foute inzendingen achter .

[Janoz]

@jmerle Ik had exact hetzelfde, maar kwam daar tijdens het debuggen gelukkig al snel achter

spoiler:

Wel had ik per ongeluk eerst part 2 gedaan omdat ik te snel gelezen had

[MatHack]

Eindelijk iets meer complexiteit, de moeite zat hem m.i. voornamelijk in het parsen van de input, gelukkig had ik niet het probleem dat @jmerle & @Janoz beschrijven. Maar kijkend naar hun oplossing zie ik nog wel ruimte voor verbetering in mijn code, voornamelijk in het parsen van

spoiler:

de stack grid

[bakkerjangert]

Leuke opdracht vandaag. Omdat ik enkele zaken handmatig invul had ik vandaag het meeste moeite met de switch tussen de test input en de echte input. Part 2 was een eitje gezien mijn opzet voor part 1.

Code in python