Advent of Code 2021

[Anoniem: 610852]

-

[ Voor 100% gewijzigd door Anoniem: 610852 op 05-09-2023 11:15 ]

[DataGhost]

Anoniem: 610852 schreef op vrijdag 3 december 2021 @ 18:30:
[...]

code:

func dominantBit(in column: Int) -> Bit[s][/s]

code:

func submissiveBit(in column: Int) -> Bit[s][/s]

OwO

Ik dacht vanochtend eindelijk misschien punten te krijgen, had mijn answer voor deel een binnen 15 minuten. Da's dus blijkbaar lang niet snel genoeg
Kwam door dat ik in WSL zat te kutten en een wget deed op de url van de input, maar ik had niet door dat de je ingelogged moest zijn voor de input, en dat die uniek voor iedereen was. (ik was ofc wel ingelogged op mijn browser in Windows maar dat mocht niet baten, natuurlijk) :c

De hoeveel eerste N mensen krijgen eigenlijk punten is dat ergens te zien ofzo?

Ik had zoals wel meer mensen hier best wel moeite met deel twee, ik was echt eventjes flink gebamboozled.

spoiler:

Eh, op het leaderboard? Alleen de top100 krijgt punten. Niet om je heel hard af te kraken maar 15 minuten lijkt me te langzaam voor een wereldwijde top100 finish op een opdracht als die van vandaag. Er zijn mensen met veel meer ervaring die hier voor klaar zitten op de F5-knop, binnen een paar seconden de relevante delen van de opdracht gelezen hebben en binnen een minuut of misschien twee een werkende oplossing ingestuurd hebben. Ik heb al een oplossing voor deel 1 gezien op Youtube die binnen 2,5 minuut was opgelost en correct, en toen waren er al 38 oplossingen voor hem ingestuurd. Deel twee had 'ie krap 10 minuten later opgelost en dat leverde een schamele 229e plek op. Daarna moest jij dus je deel 1 nog insturen Dus opzich hoef je niet zo heel hard te balen dat het ophalen van je input niet direct wilde lukken.

[ Voor 7% gewijzigd door Moonsugar op 26-03-2024 15:06 . Reden: URL verwijderd op verzoek van gebruiker ]

[Anoniem: 610852]

-

[ Voor 99% gewijzigd door Anoniem: 610852 op 05-09-2023 11:16 ]

[DataGhost]

Anoniem: 610852 schreef op vrijdag 3 december 2021 @ 18:43:
[...]

Nah it's fine . Ik had gewoon niet door hoe het werke, ik dacht misschien is de distributie wel zo dat je nog soort van pity points krijgt ofzo.

Op het GoT-leaderboard kom je dan waarschijnlijk wel redelijk hoog binnen.

[Kazu]

Bij puzzels als die van vandaag mis ik toch nog wel wat array/list functions in Go die het aantal regels hadden kunnen reduceren, maar ach, dat zit nou eenmaal in de taal. Ietsje meer zelf moeten doen, dus.

De oplossing voor deel 1 ben ik wel tevreden over, maar ik wilde deze ook voor een deel toepassen in deel 2, wat me niet helemaal lekker lukte (probeerde iets te veel te haasten, denk ik). Hierdoor ben ik over deel 2 een stuk minder tevreden. Het is een beetje een rommeltje geworden. Misschien dat ik hem op een latere dag nog even wat opschoon.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

spoiler:

Voor deel 1 dus lekker een klein beetje bitshiften , maar die lijn doortrekken in deel 2 lukte me niet echt

[Creepy]

Op youtube staan wat talks van Eric Wastl, die AoC maakt, en die zegt heel simpel: niet proberen mee te doen om punten te halen als je niet een shitload aan code al hebt liggen om aan dit soort "competities" mee te doen. Een hoop mensen doen dit als sport of hebben echt niks beters te doen en die hebben van het gros van de mogelijke vragen al een zo goed als werkende oplossing al liggen waarbij alleen nog de details moeten worden aangepast. Voor die mensen is het alleen een kwestie van herkennen welke (mogelijk) oplossing Eric bedoelt met z'n omschrijving. Met de eerste paar dagen zou je misschien nog kans maken, maar daarna.......

Ennuh "That private leaderboard is full"

[ Voor 5% gewijzigd door Creepy op 03-12-2021 19:39 ]

[DataGhost]

Creepy schreef op vrijdag 3 december 2021 @ 19:37:

Ennuh "That private leaderboard is full"

Hm. Er kunnen er wmb zeker 45 uitgeyeet worden want die staan nog op 0 sterren. @Daanoz?

[Cranzai]

Man man man, wat een gedoe dat tweede deel.
Heb er op het moment een behoorlijke puinhoop van gemaakt.

[rescla]

Weer een leuk puzzeltje: https://github.com/Rescla...blob/main/2021/day3.ipynb

Deel 2 was inderdaad even tricky. Ik heb uiteindelijk het stukje code van deel 1 een beetje herschreven om het wat beter herbruikbaar te maken. Maar op zich lukt het allemaal nog vrij aardig.

Mijn code stijl is nog niet echt des pythons als ik de andere inzendingen zo een beetje bekijk, maar misschien komt dat nog

[Cranzai]

Cranzai schreef op vrijdag 3 december 2021 @ 20:48:
Man man man, wat een gedoe dat tweede deel.
Heb er op het moment een behoorlijke puinhoop van gemaakt.

Allright, fixed
Stom logic foutje waarin in de "most"/"least" voorkomende bit niet steeds op niet werd bepaald na de deleties.

https://github.com/Cranzai/AoC

Edit:

spoiler:

Besef me net wel dat mijn "bitCounter" wat redundant is voor het tweede deel. Bereken nu voor alles weer wat het meest voorkomt, in principe niet nodig.

[ Voor 19% gewijzigd door Cranzai op 03-12-2021 22:45 ]

[Woy]

Sowieso is dat hele leaderboard voor mij niet interessant. Ik vind het leuk om een mooie oplossing te maken, maar het is meer de fun om een lekker puzzel op te lossen op een elegante manier. Soms een beetje nieuwe dingen uitproberen. Maar ik ga er echt niet eerder voor wakker worden of andere dingen voor uitstellen

[damiii]

Leuk om te lezen hoe iedereen, zoals altijd bij dit soort vraagstukken, toch weer met zijn eigen oplossing komt!

tot nu toe alles zelf ook opgelost in de avonduren!

https://github.com/da-i/adventofcode2021

[Daanoz]

DataGhost schreef op vrijdag 3 december 2021 @ 20:02:
[...]

Hm. Er kunnen er wmb zeker 45 uitgeyeet worden want die staan nog op 0 sterren. @Daanoz?

Ik heb alle 45 eruit gegooid, @Creepy probeer het nog eens?

Beetje jammer dat dit dan ook invloed heeft op het leaderboard voorgaande jaren, maar ja het is niet anders. Heb dit elk jaar al een keer moeten doen.

[Creepy]

Ja, check. Nu wel Wel onder CodeEngineerNL, maar ja....

[zwippie]

Zijn er hier nog meer mensen met Elixir in de weer? Leuke taal hoor!

Heb de eerste drie dagen maar eens online gezet: https://github.com/zwippie/aoc2021/tree/master/lib/aoc

[ Voor 6% gewijzigd door zwippie op 04-12-2021 00:49 ]

[armageddon_2k1]

Dag 4 in Kotlin

Was wel weer lekker goed te doen. Dit was een van die opdrachten dat ik blij ben dat ik alles gewoon opsplits in de domeinspecifieke functies en een helper class. Het is wat meer typewerk, maar daarna is de oplossing een eitje.

[ Voor 38% gewijzigd door armageddon_2k1 op 04-12-2021 08:03 ]

[Hydra]

Dag 4 in Kotlin

Prima te doen. Later even iets mooier maken

[Varienaja]

BINGO! Bij het intypen van antwoord twee een tikfout gemaakt. Vervolgens een half uur naar een bug gezocht die er helemaal niet was. Huil. ;-)

Tip van de dag: antwoorden copy-pasten.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 60% gewijzigd door Varienaja op 04-12-2021 11:46 ]

[Woy]

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

Op zich een makkelijke opdracht, maar ik merk dat ik het gisteren wel wat te laat gemaakt heb , nu is het nogal verbose code allemaal, later op de dag als ik wat bijgekomen ben nog maar eens een opschoonslag maken.

[KabouterSuper]

Goed te doen vandaag (in python). Wel me het leplazarus gezocht waarom python mijn numpy-array niet netjes wilde sommeren over de tweede as (hint aan mezelf: onthouden dat sum en numpy.sum niet hetzelfde werken. Bij twijfel named parameters gebruiken).

spoiler:

>>> bingo_board
array([[-1, -1, 44, -1, -1],
[-1, 30, -1, -1, -1],
[-1, -1, -1, 99, -1],
[-1, -1, 20, -1, -1],
[56, -1, -1, -1, 17]], dtype=int8)
>>> sum(bingo_board,0)
array([52, 26, 61, 95, 13], dtype=int8)
>>> sum(bingo_board,1)
array([53, 27, 62, 96, 14], dtype=int8)
>>> np.sum(bingo_board,0)
array([52, 26, 61, 95, 13])
>>> np.sum(bingo_board,1)
array([40, 26, 95, 16, 70])

[ Voor 8% gewijzigd door KabouterSuper op 04-12-2021 09:20 ]

[Woy]

Ik had vooral bij deel twee even lopen prutsen door:

spoiler:

De 0 waardes op de kaarten. Ik markeer een nummer afgestreept door hem negatief te maken, maar voor 0 werkt dat natuurlijk niet. Voor deel 1 haalde dat toevallig niks uit

[ Voor 9% gewijzigd door Woy op 04-12-2021 09:36 ]

[Remcoder]

Dag 4 ook weer gedaan, ik krijg wel het idee dat ik een stuk meer verbose code schrijf dan de rest hier

Nu heeft dat ook enigszins te maken met het feit dat Java veel methodes mist voor het werken met collecties die andere talen en frameworks wel hebben.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Mschamp]

Ik heb het gevoel dat ik vandaag wat overengineered heb.
Maar op zich wel blij met mijn oplossing:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 47% gewijzigd door Mschamp op 04-12-2021 10:03 ]

[KabouterSuper]

Woy schreef op zaterdag 4 december 2021 @ 09:36:
Ik had vooral bij deel twee even lopen prutsen door:

spoiler:

De 0 waardes op de kaarten. Ik markeer een nummer afgestreept door hem negatief te maken, maar voor 0 werkt dat natuurlijk niet. Voor deel 1 haalde dat toevallig niks uit

Haha, klinkt bekend

spoiler:

want ik had eerst niet gezien dat er uberhaubt nullen op de kaarten stonden, dus ik streepte nummers af door ze op nul te zetten. Daarna zette ik ze op -1 (en daarmee heb je bingo als de som van een kolom of rij -5 is).

[Moofnor]

Doh, dat duurde veel langer dan nodig. Vooral omdat 2 grove fouten toevallig net wel werkten op de voorbeelden... Wel een leuke opdracht!

spoiler:

Alleen checken op Bingo in de rijen ipv ook de kolommen...
Ipv de kaarten weggooien die bingo hebben, de kaarten weggooien die geen "hit" hebben op het huidige nummer.

[Cranzai]

(Hoewel dit niet perse het juiste topic is maar ik de vraag te klein vind voor een eigen topic...)

Python is een fijne taal maar het enige waar ik me aan stoor is hoe de lists/arrays werken. Natuurlijk is elke array uiteindelijk een soort list, maar ik vroeg me af:
Bestaat er een taal die in de meeste opzichten (vooral wat de easy I/O betreft) zoals python is maar dan wel met native arrays?

[ Voor 4% gewijzigd door Cranzai op 04-12-2021 09:54 ]

[Daanoz]

Moofnor schreef op zaterdag 4 december 2021 @ 09:51:

spoiler:

Alleen checken op Bingo in de rijen ipv ook de kolommen...

spoiler:

En niet gewoon aannemen dat je de diagonaal ook moet checken.... whoops

[DataGhost]

Mooi. Ik had het dus ook overengineered, want ik dacht hey, het is zaterdag en dan zijn de opdrachten normaal iets pittiger. Ik ging ervan uit dat deel 2 misschien wel eens langzaam zou kunnen zijn met de naïeve implementatie of met andere kaarten zou werken Uiteindelijk 10 minuutjes ofzo bezig geweest en toen was het alweer gedaan

spoiler:

Ik heb sets gebruikt voor elke kolom en rij met verwijzingen ernaartoe per nummer op de kaart, daarom zijn mijn lookups average O(1) en weet ik dus ook in diezelfde O(1) of er bingo is, zonder elke keer de hele kaart te hoeven scannen. Voor deel 2 gokte ik dus dat er bijvorobeeld 100x100 bingokaarten zouden komen maar dat viel allemaal nog mee dus

[DataGhost]

Cranzai schreef op zaterdag 4 december 2021 @ 09:54:
(Hoewel dit niet perse het juiste topic is maar ik de vraag te klein vind voor een eigen topic...)

Python is een fijne taal maar het enige waar ik me aan stoor is hoe de lists/arrays werken. Natuurlijk is elke array uiteindelijk een soort list, maar ik vroeg me af:
Bestaat er een taal die in de meeste opzichten (vooral wat de easy I/O betreft) zoals python is maar dan wel met native arrays?

Waar stoor je je concreet aan dan? Wat kan je niet maar wil je wel?

[EfBe]

Ook maar aangemeld bij het tweakers leaderboard Dag 4 in C#

Was een leuke opdracht Niet per-se erg lastig, maar wel veel kleine details waar je wel over kunt struikelen (ik deed dat dus ook ). Heb het niet via de naive/brute force manier gedaan, dus wat meer code, maar boeiend

spoiler:

Ik heb een hashset gebruikt voor alle unmarked numbers, en een dictionary met de numbers + hun plaats op het bord, verder een lijst met # of marked numbers per row and column, die ik ophoog via de position op het bord van een getrokken number. Zo is alles O(1) zonder scannen. Ik streep dus niets af, ik haal een getrokken number uit de lijst van unmarked numbers (hashset, dus O(1), en haal dan de position van het number op op het board, als het op het board te vinden is uiteraard. Dan hoog ik het getal voor de row en column op met 1. Als een of beide 5 zijn, is de board een 'winner' en zet ik een property.

[ Voor 46% gewijzigd door EfBe op 04-12-2021 11:30 ]

[Diderikdm]

Deze was leuk.

Python dag 4

[Cranzai]

DataGhost schreef op zaterdag 4 december 2021 @ 11:00:
[...]

Waar stoor je je concreet aan dan? Wat kan je niet maar wil je wel?

Ik werk heel graag met multidimensional arrays en matrices, daarbij vind ik het irritant dat dat dus via numpy moet. Anderzijds is het fijne van de lists dat je van te voren niet hoeft te weten hoe groot ze zijn.

Uiteindelijk zou ik ook vrede hebben met een taal waarin je wel de grootte van een array van tevoren moet specificeren maar je gewoon een .append() hebt.

[DataGhost]

Cranzai schreef op zaterdag 4 december 2021 @ 11:52:
[...]


Ik werk heel graag met multidimensional arrays en matrices, daarbij vind ik het irritant dat dat dus via numpy moet. Anderzijds is het fijne van de lists dat je van te voren niet hoeft te weten hoe groot ze zijn.

Uiteindelijk zou ik ook vrede hebben met een taal waarin je wel de grootte van een array van tevoren moet specificeren maar je gewoon een .append() hebt.

code:

board = [
    [1, 2, 3, 4, 5],
    [6, 7, 8, 9, 10],
    [11, 12, 13, 14, 15],
    ...
]
board[2][3] == 14

Werkt gewoon hoor. Je moet alleen wel op elke dimensie een list maken ja, maar zodra die er is kan je er gewoon aan appenden of assignen op een index. Je kan er ook zelf een kleine convenience class voor maken. Numpy heb je in ieder geval nergens voor nodig. Ik heb het nog nooit gebruikt en toch vorig jaar alle sterren gehaald, het jaar daarvoor bijna allemaal.

Maar wat ik vaker doe is een dictionary gebruiken met een tuple als key. Dan kan je gewoon direct assignen en ook met zoveel dimensies als je graag wilt:

code:

board = {}
board[(2,3)] = 14

Ik gok dat ik dat dit jaar ook weer bij een paar opdrachten ga doen. Voor bepaalde soorten opdrachten heeft dat ook heftige voordelen over lists/arrays. Er zitten ook een paar nadelen aan, maar ja, dat heb je overal wel mee eigenlijk.

[Hydra]

En opgeruimd!

Hoeveelheid code ongeveer gehalveerd.

[Cranzai]

DataGhost schreef op zaterdag 4 december 2021 @ 12:02:
[...]

code:

board = [
    [1, 2, 3, 4, 5],
    [6, 7, 8, 9, 10],
    [11, 12, 13, 14, 15],
    ...
]
board[2][3] == 14

Werkt gewoon hoor. Je moet alleen wel op elke dimensie een list maken ja, maar zodra die er is kan je er gewoon aan appenden of assignen op een index. Je kan er ook zelf een kleine convenience class voor maken. Numpy heb je in ieder geval nergens voor nodig. Ik heb het nog nooit gebruikt en toch vorig jaar alle sterren gehaald, het jaar daarvoor bijna allemaal.

Maar wat ik vaker doe is een dictionary gebruiken met een tuple als key. Dan kan je gewoon direct assignen en ook met zoveel dimensies als je graag wilt:

code:

board = {}
board[(2,3)] = 14

Ik gok dat ik dat dit jaar ook weer bij een paar opdrachten ga doen. Voor bepaalde soorten opdrachten heeft dat ook heftige voordelen over lists/arrays. Er zitten ook een paar nadelen aan, maar ja, dat heb je overal wel mee eigenlijk.

Ja precies het is idd meer een list of lists, denk dat het idd wel net zo praktisch is maar meer aan mijn koppigheid ligt dat ik liever een board[2,3] opvraag dan een board[2][3]

[DataGhost]

Cranzai schreef op zaterdag 4 december 2021 @ 12:10:
[...]


Ja precies het is idd meer een list of lists, denk dat het idd wel net zo praktisch is maar meer aan mijn koppigheid ligt dat ik liever een board[2,3] opvraag dan een board[2][3]

Dat kan ook, die tuple-notatie werkt ook zonder haakjes

Python:

>>> board = {}
>>> board[2,3] = 14
>>> board
{(2, 3): 14}

Maar zoals ik zei heeft dit ook al nadelen, dus ik zou hier zeker geen gewoonte van maken. Elke taal heeft verder een verschillende notatie waar je uiteindelijk niet heel veel aan gaat doen. In bijv. PHP heb je ook gewoon multidimensional arrays native, maar moet je die ook via $board[2][3] gebruiken, $board[2,3] bestaat daarin niet. Ook niet in veel andere "echte" talen.

[ Voor 29% gewijzigd door DataGhost op 04-12-2021 12:15 ]

[Cranzai]

DataGhost schreef op zaterdag 4 december 2021 @ 12:11:
[...]

Dat kan ook, die tuple-notatie werkt ook zonder haakjes

Python:

>>> board = {}
>>> board[2,3] = 14
>>> board
{(2, 3): 14}

Maar zoals ik zei heeft dit ook al nadelen, dus ik zou hier zeker geen gewoonte van maken. Elke taal heeft verder een verschillende notatie waar je uiteindelijk niet heel veel aan gaat doen. In bijv. PHP heb je ook gewoon multidimensional arrays native, maar moet je die ook via $board[2][3] gebruiken, $board[2,3] bestaat daarin niet. Ook niet in veel andere "echte" talen.

Thanks haha, "i've just been schooled"

Maar euh, zeg je nou dat Fortran geen "echte" taal is?

[ Voor 40% gewijzigd door Cranzai op 04-12-2021 12:17 ]

[fruitschaal2]

Cranzai schreef op zaterdag 4 december 2021 @ 12:10:
[...]


Ja precies het is idd meer een list of lists, denk dat het idd wel net zo praktisch is maar meer aan mijn koppigheid ligt dat ik liever een board[2,3] opvraag dan een board[2][3]

Ik denk dat je dan beter het onderscheid moet zien tussen een list of een numpy.array. Een list kan van alles bevatten, ook een list in een list zonder dat elke list dezelfde grootte hoeft te hebben:

l = ['a', [1, 2, 3], 1]

Alles kan door elkaar.

Als je de list wilt gebruiken als array dan kun je een list opzetten naar een numpy.array. Dan moet het wel een geldige list zijn maar een 5x5 nummer list kan dus omgezet worden en dan kun je de index gebruiken zoals jij beschrijft.

Ik zie het als twee in de basis verschillende functies van python, net als dat een dictionary niet hetzelfde is als een list.

[DataGhost]

Cranzai schreef op zaterdag 4 december 2021 @ 12:15:
[...]

Maar euh, zeg je nou dat Fortran geen "echte" taal is?

Ik zei alleen dat veel "echte" talen (zoals C) multidimensional array access dmv [y][x] doen ipv [y,x], niet dat dat een criterium is om een "echte" taal te zijn.

En ik heb Fortran zelf nooit gebruikt dus het zal wel niet zo'n heel boeiend taaltje zijn

[Kazu]

EfBe schreef op zaterdag 4 december 2021 @ 11:24:
Ook maar aangemeld bij het tweakers leaderboard Dag 4 in C#

Was een leuke opdracht Niet per-se erg lastig, maar wel veel kleine details waar je wel over kunt struikelen (ik deed dat dus ook ). Heb het niet via de naive/brute force manier gedaan, dus wat meer code, maar boeiend

spoiler:

Ik heb een hashset gebruikt voor alle unmarked numbers, en een dictionary met de numbers + hun plaats op het bord, verder een lijst met # of marked numbers per row and column, die ik ophoog via de position op het bord van een getrokken number. Zo is alles O(1) zonder scannen. Ik streep dus niets af, ik haal een getrokken number uit de lijst van unmarked numbers (hashset, dus O(1), en haal dan de position van het number op op het board, als het op het board te vinden is uiteraard. Dan hoog ik het getal voor de row en column op met 1. Als een of beide 5 zijn, is de board een 'winner' en zet ik een property.

spoiler:

Dit was ook de oplossing die mij te binnen schoot toen ik al halverwege was met het implementeren van een scan. Maar toen was ik te lui om het alsnog om te gooien Ik heb het nu dus maar super langzaam geimplementeerd. Niet trots op, maar ach...

Nadat ik hierdoor een tijdje bezig was met deel 1 had ik het vermoeden dat deel 2 o.a. diagonaal zou gaan introduceren. Maar het was letterlijk 2 minuten coding en toen was deel 2 ook af, dus dat was een meevaller.

[ Voor 7% gewijzigd door Kazu op 04-12-2021 12:25 ]

[DataGhost]

Kazu schreef op zaterdag 4 december 2021 @ 12:22:
[...]

spoiler:

Dit was ook de oplossing die mij te binnen schoot toen ik al halverwege was met het implementeren van een scan. Maar toen was ik te lui om het alsnog om te gooien Ik heb het nu dus maar super langzaam geimplementeerd. Niet trots op, maar ach...

Nadat ik hierdoor een tijdje bezig was met deel 1 had ik het vermoeden dat deel 2 o.a. diagonaal zou gaan introduceren. Maar het was letterlijk 2 minuten coding en toen was deel 2 ook af, dus dat was een meevaller.

Ik heb wat testinvoer gemaakt voor deel twee, met

spoiler:

grotere bingokaarten, deze zijn 100x100. Deel 2 met deze kaarten duurt bij mij zo'n 4 seconden (Python, in een VM op een 11 jaar oude laptop) met als antwoord 3074334900. Ik ben benieuwd hoe snel dat bij jou gaat dan, als je daar zin in hebt

https://sigyn.dataghost.com/aoc/2021/aoc-2021-day3-part2.txt

[gedonie]

Ik heb dag 4 ook maar eens gedaan. Dag 4 in Java

Was de eerste dag met een beetje puzzelen, maar wel leuk.

[Remcoder]

gedonie schreef op zaterdag 4 december 2021 @ 12:52:
Ik heb dag 4 ook maar eens gedaan. Dag 4 in Java

Was de eerste dag met een beetje puzzelen, maar wel leuk.

Ik denk dat je repo nog private staat, ik krijg een 404 en als ik je repos bekijk zie ik geen AOC repo in de lijst.

[DevWouter]

Meh, de opdrachten zijn nog redelijk simpel. Net even snel gedaan en het grootste probleem bij mij is toch echt dat ik de opdracht niet lees. Bij deel 1 had ik al na een paar zinnen al: "Oh, we zullen waarschijnlijk dit moeten doen" en halverwege het schrijven dacht ik "goh, toch even lezen wat we moeten doen" gevolgd door "Oh... Maar wedden dat de laatste opdracht.... is" en vervolgens blijkt dat te kloppen.

Ik merk wel dat ik geen enkele zin heb om de code netjes te maken. Vind ik zonde van mijn tijd. Hopelijk worden de puzzels snel wat uitdagender zodat ik wat meer mijn best ga doen

[Dricus]

Dag 4 in Clojure

Poeh, best lastig als je de taal en de library nog aan het uitvogelen bent... Maar uiteindelijk wel tevreden met het resultaat. Iteratie 1 was lomp. Na refactoring 1 was het nog traag (dikke 500 ms voor deel 2). Na refactoring 2 was het een stuk sneller (66 ms voor deel 2).

[DevWouter]

@DataGhost Moet je natuurlijk wel opdezelfde omgeving testen

[glorytothesun]

Heel interessant om dit ook in een andere programmeertaal te doen dan waar je normaal mee werkt. Al een hele tijd geen Python meer gedaan, kijken hoe dat zal verlopen.

[Janoz]

spoiler:

Ik heb helemaal niks gemarkt. Zodra ik de trekkingen inlees maak ik ook een lookup tabel zodat ik van elk nummer weet in welke beurt hij getrokken wordt. Tijdens het inlezen schrijf ik vervolgens de posities in een tabel. Door dan het maximum van een rij of kolom te nemen weet ik in welke beurt deze vol is. Neem ik vervolgens het minimum van alle rijen en kolommen dan weet ik in welke beurt dat bord gewonnen heeft.

Score berekening is vervolgens heel simpel. Weer over dat tabelletje heen en overal waar de score hoger is dan de beurt telt hij wel mee.

Zo kan ik elk bord behandelen en kan ik alle borden negeren die niet de eerste of laatste zijn.

[armageddon_2k1]

Dricus schreef op zaterdag 4 december 2021 @ 13:46:
Dag 4 in Clojure

Poeh, best lastig als je de taal en de library nog aan het uitvogelen bent... Maar uiteindelijk wel tevreden met het resultaat. Iteratie 1 was lomp. Na refactoring 1 was het nog traag (dikke 500 ms voor deel 2). Na refactoring 2 was het een stuk sneller (66 ms voor deel 2).

Er zit toch bijna geen verschil tussen deel 1 en 2?

[armageddon_2k1]

glorytothesun schreef op zaterdag 4 december 2021 @ 13:47:
Heel interessant om dit ook in een andere programmeertaal te doen dan waar je normaal mee werkt. Al een hele tijd geen Python meer gedaan, kijken hoe dat zal verlopen.

Dat heb ik ook geprobeerd maar dan ben ik meer bezig met de taal dan met het probleem en dat duurt me te lang. Ik haal plezier uit een elegante oplossing in een taal welke ik goed ken Wat ik wel graag doe is eerder opgeloste problemen oplossen in een nieuwe taal.

[Janoz]

armageddon_2k1 schreef op zaterdag 4 december 2021 @ 13:52:
[...]


Er zit toch bijna geen verschil tussen deel 1 en 2?

Ligt aan je oplossing. Als je daadwerkelijk het hele spel gaat simuleren ben je klaar wanneer je bij de eerste winnaar bent, voor deel 2 moet je in dat geval doorgaan tot iedereen bingo heeft.

[glorytothesun]

armageddon_2k1 schreef op zaterdag 4 december 2021 @ 13:53:
[...]


Dat heb ik ook geprobeerd maar dan ben ik meer bezig met de taal dan met het probleem en dat duurt me te lang. Ik haal plezier uit een elegante oplossing in een taal welke ik goed ken Wat ik wel graag doe is eerder opgeloste problemen oplossen in een nieuwe taal.

Ik vind het altijd leuk om te experimenteren met een nieuwe programmeertaal met dit soort dingen. Zelf stop ik ook als ik het idee heb dat de opdracht voor mij te lastig is om op te lossen met die taal. Maar goed, het is inderdaad ook erg leuk om oplossingen ook te proberen in een andere taal, kan je veel van leren.

[armageddon_2k1]

Hydra schreef op zaterdag 4 december 2021 @ 12:09:
En opgeruimd!

Hoeveelheid code ongeveer gehalveerd.

Altijd goed om te zien dat iemand naar dezelfde oplossing convergeert als ik, zelfs met dezelfde naamgeving op sommige plekken

[armageddon_2k1]

Janoz schreef op zaterdag 4 december 2021 @ 13:54:
[...]


Ligt aan je oplossing. Als je daadwerkelijk het hele spel gaat simuleren ben je klaar wanneer je bij de eerste winnaar bent, voor deel 2 moet je in dat geval doorgaan tot iedereen bingo heeft.

Ja, dus bijna geen verschil

Ik simuleer gewoon de hele bende en die is binnen 50ms klaar.

[gedonie]

Remcoder schreef op zaterdag 4 december 2021 @ 13:27:
[...]

Ik denk dat je repo nog private staat, ik krijg een 404 en als ik je repos bekijk zie ik geen AOC repo in de lijst.

Je hebt helemaal gelijk. Ik heb hem op public gezet nu.

[MaNDaRK]

Hier nu ook dag 4 opgelost in C#.

Ik ben ook voor de strategie gegaan om alle spellen te spelen

Oh en: LINQ

[Janoz]

armageddon_2k1 schreef op zaterdag 4 december 2021 @ 13:58:
[...]


Ja, dus bijna geen verschil

Ik simuleer gewoon de hele bende en die is binnen 50ms klaar.

Kijk je naar het voorbeeld, dan zou je in deel 1 maar 11 trekkingen moeten simuleren terwijl dat in deel 2 13 zijn. Voor de werkelijke testcases is het verschil een stuk groter dus kan ik me voorstellen dat een naïve implementatie 4x zo lang over de simulatie doet. Dat is best een verschil. Merk je waarschijnlijk niet doordat de hele bende eerder IO- bound is. Maar 'bijna geen' vind ik het niet.

[armageddon_2k1]

Janoz schreef op zaterdag 4 december 2021 @ 14:07:
[...]


Kijk je naar het voorbeeld, dan zou je in deel 1 maar 11 trekkingen moeten simuleren terwijl dat in deel 2 13 zijn. Voor de werkelijke testcases is het verschil een stuk groter dus kan ik me voorstellen dat een naïve implementatie 4x zo lang over de simulatie doet. Dat is best een verschil. Merk je waarschijnlijk niet doordat de hele bende eerder IO- bound is. Maar 'bijna geen' vind ik het niet.

Je hebt helemaal gelijk hoor. Maar op het moment dat de hele oplossing brute-force < 50ms komt dan ga ik me persoonlijk niet zo drukmaken om optimalisaties Die komen later wel met de echt moeilijke problemen.

[Cranzai]

Dag 4 opgelost, grootste deel van de uitdaging was dat mijn strategie voor A niet werkte voor B.
edit:
@DataGhost alles zonder numpy overigens

spoiler:

https://github.com/Cranza.../2021/day4/python/day4.py
Reden dat mijn oplossing voor A niet simpel aan te passen was naar B is dat het niet mogelijk is te verwijderen in een lijst waar je op dat moment over heen loopt. Daarnaast zou ik met die manier wel weten welke kaart wint maar niet welk nummer deze heeft.

Voor deel B dus herschreven naar een stijl waarin ik bijhoudt welke kaarten nog mee spelen.
In principe zou ik het inverse hiervan ook gedaan kunnen hebben voor A maar dan vind je de winnaar pas als laatste waar je deze ook als eerste zou kunnen finden...

[ Voor 4% gewijzigd door Cranzai op 04-12-2021 14:31 ]

[Dricus]

armageddon_2k1 schreef op zaterdag 4 december 2021 @ 13:52:
Er zit toch bijna geen verschil tussen deel 1 en 2?

Wat @Janoz zegt, en mijn implementatie was super inefficiënt. Maar qua algoritme is er bijna geen verschil inderdaad.

Verder is performance in principe natuurlijk volstrekt oninteressant, maar wel leuk .

[Kazu]

DataGhost schreef op zaterdag 4 december 2021 @ 12:32:
[...]

Ik heb wat testinvoer gemaakt voor deel twee, met

spoiler:

grotere bingokaarten, deze zijn 100x100. Deel 2 met deze kaarten duurt bij mij zo'n 4 seconden (Python, in een VM op een 11 jaar oude laptop) met als antwoord 3074334900. Ik ben benieuwd hoe snel dat bij jou gaat dan, als je daar zin in hebt

https://sigyn.dataghost.com/aoc/2021/aoc-2021-day3-part2.txt

spoiler:

Oef, ja, zo'n grote dataset trekt mijn O(n^2) implementatie wel op z'n knieën. 3 minuut 51, maar wel met een andere uitkomst: 6307576443, dus dat is wel vreemd. Ik ben een beetje teleurgesteld in m'n luie oplossing, dus ik denk dat ik hem nog wel ga verbeteren als ik er tijd voor heb

[DataGhost]

DevWouter schreef op zaterdag 4 december 2021 @ 13:47:
@DataGhost Moet je natuurlijk wel opdezelfde omgeving testen

Als het gaat om grote O-notatie van looptijden maakt de omgeving bijna niks meer uit Ik heb een andere oplossing uit dit topic getest op mijn nieuwe input en dat duurde ruim 33 minuten Die van Kazu heb ik moeten aanpassen en die gaf na 25 seconden het verkeerde antwoord, dus dat ligt of aan mij of niet. Met de "verkeerde aanpak" ben je in ieder geval een orde van grootte (of twee) langer bezig en dan gaat geen snelle CPU je helpen. Ook staat in about van AoC dat alle oplossingen maximaal 15 seconden nodig hebben op 10 jaar oude hardware. Bij in ieder geval de wedstrijden waaraan ik heb meegedaan (BAPC en NWERC) was algoritmische complexiteit van zeer groot belang en moest je oplossing eigenlijk binnen een paar seconden eruit komen rollen anders werd 'ie niet goedgerekend.

Als ik jouw code zo zie (nofi, qua code prima maar qua tijdscomplexiteit ziet het er niet heel snel uit) wil ik je daarom uitdagen om het binnen 15 seconden te laten lopen op welke hardware dan ook Misschien dat je daar wel meer zin van krijgt om het "netjes te maken"

Edit: hoewel snelle code meestal niet heel netjes/duidelijk is voor een lezer. Maar het kan wel.

[ Voor 15% gewijzigd door DataGhost op 04-12-2021 14:58 ]

[ShitHappens]

Hehe, ook eindelijk klaar

spoiler:

Was stiekem toch even een puzzel bij part 2 om op tijd te stoppen met getallen trekken, in m'n eerste paar pogingen schoot 'ie door de hele lijst heen en klopte het eindresultaat niet


M'n code houdt nog net té erg vast aan 5x5 grids (vooral aan de 5 rijen) dus sla de 100x100 tests van hierboven nog maar even over.

[DataGhost]

Kazu schreef op zaterdag 4 december 2021 @ 14:34:
[...]

spoiler:

Oef, ja, zo'n grote dataset trekt mijn O(n^2) implementatie wel op z'n knieën. 3 minuut 51, maar wel met een andere uitkomst: 6307576443, dus dat is wel vreemd. Ik ben een beetje teleurgesteld in m'n luie oplossing, dus ik denk dat ik hem nog wel ga verbeteren als ik er tijd voor heb

Hm, gek. Ik kon ook niet direct vinden waarom jouw uitkomst niet klopte. Met wat simpele aanpassingen aan je magic numbers (in revisie g3929193) komt er bij mij nog een andere (wederom verkeerde) uitkomst uit, namelijk 3098648098 na 25 seconden. Dus dat is zo mogelijk nog vreemder

[DataGhost]

ShitHappens schreef op zaterdag 4 december 2021 @ 14:47:
Hehe, ook eindelijk klaar

spoiler:

Was stiekem toch even een puzzel bij part 2 om op tijd te stoppen met getallen trekken, in m'n eerste paar pogingen schoot 'ie door de hele lijst heen en klopte het eindresultaat niet


M'n code houdt nog net té erg vast aan 5x5 grids (vooral aan de 5 rijen) dus sla de 100x100 tests van hierboven nog maar even over.

spoiler:

Als je het niet dynamisch naar de input wilt maken en dus magic numbers gebruikt: die gaan heel prima in constanten, dan hoef je maar op 1 plek een nummertje aan te passen en dan is je hele programma er klaar voor

[MueR]

Ik snap vandaag even niets van code blijkbaar.. met AoC bezig. M'n code werkt met de testinput, geeft correct resultaat. Maar met de live input niet. Wtf

[DataGhost]

MueR schreef op zaterdag 4 december 2021 @ 14:58:
Ik snap vandaag even niets van code blijkbaar.. met AoC bezig. M'n code werkt met de testinput, geeft correct resultaat. Maar met de live input niet. Wtf

De testinput is wel vaker zo gemaakt dat er weinig edge cases in zitten die in de volledige testdata wel zitten

[Daos]

MaNDaRK schreef op zaterdag 4 december 2021 @ 14:06:
Hier nu ook dag 4 opgelost in C#.

Als je in Visual Studio naar de properties van "day4.txt" gaat dan kan je de "Copy to Output Directory" op "Copy always" zetten. In je code hoef je dan niet meer 3 mappen terug te gaan, maar kan je dit doen:

C#:

System.IO.File.ReadAllLines("day4.txt");

[Patriot]

Ik heb dag vier ook afgerond, voornaamste probleem waar ik tegenaan liep was iets wat ik verkeerd begreep van hoe Python werkt (niet de eerste en vast ook niet de laatste keer, toch @DataGhost? ). Maar goed, tegen dat soort dingen aanlopen is uiteindelijk ook het idee want daar leer je van. Deel 2 was voor mij een makkelijke aanpassing omdat ik het spel simuleer, kwestie van stoppen met markeren als het bord al klaar is en steeds het meest recente bord dat klaar is bijhouden.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ShitHappens]

DataGhost schreef op zaterdag 4 december 2021 @ 14:51:
[...]

spoiler:

Als je het niet dynamisch naar de input wilt maken en dus magic numbers gebruikt: die gaan heel prima in constanten, dan hoef je maar op 1 plek een nummertje aan te passen en dan is je hele programma er klaar voor

spoiler:

Nee magic numbers is in deze nog niet het ergste, maar het 5x verzamelen van een specifieke index van een List, eentje voor elke row Zou dat eigenlijk even netjes in een loopje moeten afhandelen

[DataGhost]

ShitHappens schreef op zaterdag 4 december 2021 @ 15:12:
[...]

spoiler:

Nee magic numbers is in deze nog niet het ergste, maar het 5x verzamelen van een specifieke index van een List, eentje voor elke row Zou dat eigenlijk even netjes in een loopje moeten afhandelen

Oh, is het echt copy/paste? ja dan snap ik m

[Patriot]

ShitHappens schreef op zaterdag 4 december 2021 @ 15:12:
[...]

spoiler:

Nee magic numbers is in deze nog niet het ergste, maar het 5x verzamelen van een specifieke index van een List, eentje voor elke row Zou dat eigenlijk even netjes in een loopje moeten afhandelen

Sowieso is het 'nadeel' van zo'n challenge dat je natuurlijk heel makkelijk niet al te robuuste code schrijft. Tegelijkertijd is dat ook wel leuk, want dan ben je bezig met het probleem i.p.v. alleen maar afhandeling van "wat als dit fout gaat?"

[MueR]

DataGhost schreef op zaterdag 4 december 2021 @ 14:59:
[...]

De testinput is wel vaker zo gemaakt dat er weinig edge cases in zitten die in de volledige testdata wel zitten

Ja ik heb ergens een valse bingo. Maar ik zal jullie het liedje zingen besparen.

[Patriot]

MueR schreef op zaterdag 4 december 2021 @ 15:15:
[...]

Ja ik heb ergens een valse bingo. Maar ik zal jullie het liedje zingen besparen.

Ik luister wel weer naar het audioclipje op naardekloot.nl

[Cranzai]

DataGhost schreef op zaterdag 4 december 2021 @ 12:32:
[...]

Ik heb wat testinvoer gemaakt voor deel twee, met

spoiler:

grotere bingokaarten, deze zijn 100x100. Deel 2 met deze kaarten duurt bij mij zo'n 4 seconden (Python, in een VM op een 11 jaar oude laptop) met als antwoord 3074334900. Ik ben benieuwd hoe snel dat bij jou gaat dan, als je daar zin in hebt

https://sigyn.dataghost.com/aoc/2021/aoc-2021-day3-part2.txt

Mijn oude trouwe MB Air 2015, komt er niet echt doorheen met mijn code

edit:

spoiler:

Denk dat dit komt doordat ik het hele spel simuleer waardoor ik meerdere keren over elke kaart moet.
Misschien als ik iets schrijf waarbij je per kaart evalueert wanneer deze zou winnen, dat het eenvoudiger wordt.

[ Voor 17% gewijzigd door Cranzai op 04-12-2021 15:26 ]

[DataGhost]

Cranzai schreef op zaterdag 4 december 2021 @ 15:18:
[...]


Mijn oude trouwe MB Air 2015, komt er niet echt doorheen met mijn code

Ik heb er een voortgangsdingetje in geknutseld, een voorzichtige schatting lijkt me een uur of anderhalf op mijn laptop.

[Cranzai]

DataGhost schreef op zaterdag 4 december 2021 @ 15:25:
[...]

Ik heb er een voortgangsdingetje in geknutseld, een voorzichtige schatting lijkt me een uur of anderhalf op mijn laptop.

Whahaha, dan zet ik het wel eventjes op de universiteitscluster

spoiler:

Het hele spel simuleren is dus niet de snelste oplossing

[ Voor 11% gewijzigd door Cranzai op 04-12-2021 15:28 ]

[Varienaja]

Cranzai schreef op zaterdag 4 december 2021 @ 15:18:

spoiler:

Denk dat dit komt doordat ik het hele spel simuleer waardoor ik meerdere keren over elke kaart moet.
Misschien als ik iets schrijf waarbij je per kaart evalueert wanneer deze zou winnen, dat het eenvoudiger wordt.

Als je Grote O leert uitrekenen dan weet je of het eenvoudiger (sneller) wordt ipv dat je het alleen maar denkt.

Mijn oplossing doet 400ms over jouw 100x100 invoer.

Cranzai schreef op zaterdag 4 december 2021 @ 15:27:
Whahaha, dan zet ik het wel eventjes op de universiteitscluster

spoiler:

Het hele spel simuleren is dus niet de snelste oplossing

Bij mijn weten simuleer ik het hele spel en dat duurt echt niet lang. Beter gezegd: dat hoeft niet lang te duren.

[ Voor 29% gewijzigd door Varienaja op 04-12-2021 15:31 ]

[DataGhost]

Cranzai schreef op zaterdag 4 december 2021 @ 15:27:
[...]


Whahaha, dan zet ik het wel eventjes op de universiteitscluster

spoiler:

Het hele spel simuleren is dus niet de snelste oplossing

Die cluster zou het niet sneller maken aangezien je code totaal niet parallel is
Wbt je spoiler: dat moet tot op zekere hoogte nog wel, maar

spoiler:

een aantal controles welke heel relatief heel veel tijd kosten zijn grotendeels nutteloos omdat er tussen trekkingen maar heel weinig verandert

Je bent niet de enige hiermee trouwens. Het is een stuk leesbaarder/logischer op de naïeve manier, zoals dat wel vaker zo is. Gelukkig is dat de eerste paar dagen nog niet zo erg, maar dat zijn wel de dagen dat je tijd hebt om met betere aanpakken te komen, zodat je daar in latere dagen nog maar relatief weinig tijd aan kwijt bent (haha).

[ Voor 22% gewijzigd door DataGhost op 04-12-2021 15:32 ]

[Soultaker]

DataGhost schreef op zaterdag 4 december 2021 @ 12:32:
Ik heb wat testinvoer gemaakt voor deel twee, met

spoiler:

grotere bingokaarten, deze zijn 100x100. Deel 2 met deze kaarten duurt bij mij zo'n 4 seconden (Python, in een VM op een 11 jaar oude laptop) met als antwoord 3074334900. Ik ben benieuwd hoe snel dat bij jou gaat dan, als je daar zin in hebt

Leuk! Mijn Python code doet het in iets minder dan 1 seconde.

Dit algoritme is O(N) (bewijs als oefening voor de lezer) dus asymptotisch optimaal, al zal hetzelfde algoritme in bijvoorbeeld C veel sneller lopen.

[MueR]

Kan iemand eens meekijken? Input staat er ook bij. Ik moet echt iets over het hoofd zien.

https://github.com/MueR/a...fCode2021/Day04/Day04.php

spoiler:

Ik kom met deze input op kaart 11, na het trekken van nummer 98, doordat de middelste kolom vol is. Het totaal van de overgebleven getallen is dan 792. 792 * 98 = 77616.

BINGO Card 11 Num 98

29 18 -94 -63 -55 :: Remaining 47
91 93 -98 45 34 :: Remaining 263
60 8 -2 86 -38 :: Remaining 154
95 89 -65 -22 59 :: Remaining 243
-39 -5 -20 44 41 :: Remaining 85
Card total: 792

[ Voor 27% gewijzigd door MueR op 04-12-2021 15:34 ]

[keeperson]

Had er in het begin een beetje een hard hoofd in, maar deze was heel goed te doen in Swift.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[TrailBlazer]

Voor de eerste keer met numpy en arrays gewerkt. Vooral problemen met deel twee totdat ik besefte

spoiler:

Dat ik gewoon de 100e winnende kaart moest hebben.

[Varienaja]

MueR schreef op zaterdag 4 december 2021 @ 15:33:
Kan iemand eens meekijken? Input staat er ook bij. Ik moet echt iets over het hoofd zien.

Ik vind deze kaart voor A met jouw input.

spoiler:

[59, 35, 52, 60, 91]
[75, 86, 13, 39, 21]
[33, 99, 11, 64, 50]
[37, 58, 71, 22, 54]
[6, 72, 88, 3, 85]

Met overblijfsel: [71, 72, 75, 11, 13, 21, 85, 86, 88, 91, 33, 35, 37, 50, 52, 54, 58, 59] en 63424 als uiteindelijk antwoord.

[dcm360]

MueR schreef op zaterdag 4 december 2021 @ 15:33:
Kan iemand eens meekijken? Input staat er ook bij. Ik moet echt iets over het hoofd zien.

https://github.com/MueR/a...fCode2021/Day04/Day04.php

spoiler:

Ik kom met deze input op kaart 11, na het trekken van nummer 98, doordat de middelste kolom vol is. Het totaal van de overgebleven getallen is dan 792. 792 * 98 = 77616.

BINGO Card 11 Num 98

29 18 -94 -63 -55 :: Remaining 47
91 93 -98 45 34 :: Remaining 263
60 8 -2 86 -38 :: Remaining 154
95 89 -65 -22 59 :: Remaining 243
-39 -5 -20 44 41 :: Remaining 85
Card total: 792

Hoe werken die negatieve waarden? Ik zie ze niet (als positief) in de invoer staan op die kaart.

[MueR]

dcm360 schreef op zaterdag 4 december 2021 @ 15:40:
[...]

Hoe werken die negatieve waarden? Ik zie ze niet (als positief) in de invoer staan op die kaart.

Alles wat getrokken is maak ik negatief.

[rescla]

Zeker niet de meest efficiënte implementatie, maar een beetje prutsen met Numpy is wel leuk.

https://github.com/Rescla...blob/main/2021/day4.ipynb

Ik maak trouwens wel elke keer de fout dat ik de output van een filter/map/etc. niet eerst in een list stop. Dat gaat de eerste keer goed (want literator, dus daar komen gewoon waardes uit). Maar als je hem daarna nog een keer uitvraagt natuurlijk niet.

[dcm360]

MueR schreef op zaterdag 4 december 2021 @ 15:40:
[...]

Alles wat getrokken is maak ik negatief.

Dan gebeurt er ergens iets dat vrij raar is. Ik zie dit als invoer van die kaart:

spoiler:

29 18 49 10 67
91 93 37 45 34
60 8 56 86 32
95 89 71 51 59
87 3 27 44 41

[MueR]

Varienaja schreef op zaterdag 4 december 2021 @ 15:38:
[...]

Ik vind deze kaart voor A met jouw input.

spoiler:

[59, 35, 52, 60, 91]
[75, 86, 13, 39, 21]
[33, 99, 11, 64, 50]
[37, 58, 71, 22, 54]
[6, 72, 88, 3, 85]

Met overblijfsel: [71, 72, 75, 11, 13, 21, 85, 86, 88, 91, 33, 35, 37, 50, 52, 54, 58, 59] en 63424 als uiteindelijk antwoord.

Grom, dat is wel het goede antwoord. Maar ik snap dus nog even niet waar m'n code zich verslikt.

[joppybt]

Toen mijn tweede oplossing nog een fout bevatte kwam ik er toevallig op uit dat bij het trekken van de '0' het spel zou eindigen. Daarmee werd het antwoord ook 0 natuurlijk.
Toen ik de fout had hersteld kwam ik wel op een getal uit.

Ik vraag me af of er persoonlijke invoer is waarbij daadwerkelijk iemand met 0 eindigt.

[MueR]

dcm360 schreef op zaterdag 4 december 2021 @ 15:42:
[...]

Dan gebeurt er ergens iets dat vrij raar is. Ik zie dit als invoer van die kaart:

spoiler:

29 18 49 10 67
91 93 37 45 34
60 8 56 86 32
95 89 71 51 59
87 3 27 44 41

Wait.. what...

[DataGhost]

Soultaker schreef op zaterdag 4 december 2021 @ 15:31:
[...]

Leuk! Mijn Python code doet het in iets minder dan 1 seconde.

Dit algoritme is O(N) (bewijs als oefening voor de lezer) dus asymptotisch optimaal, al zal hetzelfde algoritme in bijvoorbeeld C veel sneller lopen.

Nice. Mijne is dat dus niet, maar average-case wel Het is ook net iets intuitiever leesbaar denk ik maar dat levert dus in op rauwe snelheid.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[DataGhost]

edit: - nvm ik zie dat je die case al had afgedekt

[ Voor 93% gewijzigd door DataGhost op 04-12-2021 15:57 ]

[Soultaker]

MueR schreef op zaterdag 4 december 2021 @ 15:33:
https://github.com/MueR/a...fCode2021/Day04/Day04.php

Volgens mij behandel je in markNumber() álle kaarten, en niet alleen $card.

[KabouterSuper]

DataGhost schreef op zaterdag 4 december 2021 @ 12:32:
[...]

Ik heb wat testinvoer gemaakt voor deel twee, met

spoiler:

grotere bingokaarten, deze zijn 100x100. Deel 2 met deze kaarten duurt bij mij zo'n 4 seconden (Python, in een VM op een 11 jaar oude laptop) met als antwoord 3074334900. Ik ben benieuwd hoe snel dat bij jou gaat dan, als je daar zin in hebt

https://sigyn.dataghost.com/aoc/2021/aoc-2021-day3-part2.txt

Ik kom ook uit op 3074334900, dus hetzelfde als jij. Het duurde een handvol minuten (maar in mijn verdediging, ik draai ook continue twee python processen die cryptografie-puzzels aan het decrypten zijn).

[MueR]

Soultaker schreef op zaterdag 4 december 2021 @ 15:50:
[...]

Volgens mij behandel je in markNumber() álle kaarten, en niet alleen $card.

* MueR gaat zich stilletjes in een hoekje schamen.

Thanks

[Cranzai]

Varienaja schreef op zaterdag 4 december 2021 @ 15:28:
[...]

Als je Grote O leert uitrekenen dan weet je of het eenvoudiger (sneller) wordt ipv dat je het alleen maar denkt.

Mijn oplossing doet 400ms over jouw 100x100 invoer.


[...]

Bij mijn weten simuleer ik het hele spel en dat duurt echt niet lang. Beter gezegd: dat hoeft niet lang te duren.

Officieel zou ik moeten weten hoe ik de big O bereken, heb gewerkt aan GPU parallelisatie van een O(N^5) probleem. (Nou blijken die vaardigheden niet perse uit mijn geklungel met python )

DataGhost schreef op zaterdag 4 december 2021 @ 15:30:
[...]

Die cluster zou het niet sneller maken aangezien je code totaal niet parallel is
Wbt je spoiler: dat moet tot op zekere hoogte nog wel, maar

spoiler:

een aantal controles welke heel relatief heel veel tijd kosten zijn grotendeels nutteloos omdat er tussen trekkingen maar heel weinig verandert

Je bent niet de enige hiermee trouwens. Het is een stuk leesbaarder/logischer op de naïeve manier, zoals dat wel vaker zo is. Gelukkig is dat de eerste paar dagen nog niet zo erg, maar dat zijn wel de dagen dat je tijd hebt om met betere aanpakken te komen, zodat je daar in latere dagen nog maar relatief weinig tijd aan kwijt bent (haha).

De cluster zou het wel enigszins sneller maken door de snellere cores en meer/sneller geheugen neem ik aan?
Om nou direct met OpenACC te gaan werken o.i.d is me ook zo wat

Doe het idd op de naïve manier omdat ik het ook als een verhaaltje probeer uit te voeren en tijdens het programmeren op die manier aan mezelf vertel, echt slim programmeren moet ik altijd nog over nadenken.
Vaak komen de verbeterpunten in de code al gauw in mij op als ik klaar ben. Geavanceerdere technieken zoals mapping en weet ik veel wat heb ik nooit gehad / meegewerkt dus ik baseer programma's vaak op logica en for loopjes

[DataGhost]

Cranzai schreef op zaterdag 4 december 2021 @ 16:01:
[...]

De cluster zou het wel enigszins sneller maken door de snellere cores en meer/sneller geheugen neem ik aan?

Nja zolang je maar 1 core kan gebruiken gaat het door die speedup alsnog nooit zomaar onder de 10 minuten zakken.

Doe het idd op de naïve manier omdat ik het ook als een verhaaltje probeer uit te voeren en tijdens het programmeren op die manier aan mezelf vertel, echt slim programmeren moet ik altijd nog over nadenken.
Vaak komen de verbeterpunten in de code al gauw in mij op als ik klaar ben. Geavanceerdere technieken zoals mapping en weet ik veel wat heb ik nooit gehad / meegewerkt dus ik baseer programma's vaak op logica en for loopjes

Vaak gaat een groot deel al vanzelf als je de juiste datastructuren kiest, die voor het doel wat je beoogt en de operaties die je vaak doet een snelle looptijd hebben. Iets simpels als het verschil tussen een linked list en een normale list is al O(n) voor element access. Op dezelfde manier is

spoiler:

zoeken naar een getal in een array/list O(n) terwijl dat sneller kan met andere structuren

Dan hoef je qua leesbaarheid nog niet eens heel veel in te leveren. Je kan eens een blik werpen op mijn implementatie (dat zijn wel spoilers) en daarna op die van @Soultaker, die weliswaar iets lastiger te lezen is maar nog sneller omdat zijn aanpak nog iets beter/sneller is.

[ Voor 10% gewijzigd door DataGhost op 04-12-2021 16:06 ]

[ydderf]

Day 4 C#

Vanmorgen met ontbijt gekeken wat de opdracht was, maar helaas nog geen tijd deze te maken. Ofwel de hele ochtend gedacht hoe de opdracht te maken.
Deze keer vond ik de opdracht goed te begrijpen, maar zat ik wel te stoeien hoe ik het programma technisch mooi zou kunnen oplossen.
Mijn programma doet het wel, maar ik heb nog niet het gevoel dat ik de juiste oplossingsrichting heb gekozen. Of mijn input data op een andere manier opslaan of handiger worden met Linq....

spoiler:

Eerst een tijd aan het stoeien geweest om de input in te lezen, totdat ik zag dat er soms een dubbele spatie tussen staat wat mijn string.split() niet fijn vond.

[DataGhost]

ydderf schreef op zaterdag 4 december 2021 @ 16:14:

spoiler:

Eerst een tijd aan het stoeien geweest om de input in te lezen, totdat ik zag dat er soms een dubbele spatie tussen staat wat mijn string.split() niet fijn vond.

Ik zag dat in Python direct al mis gaan dus zonder het te proberen heb ik direct

spoiler:

gesplit met een regex \s+ in plaats van gewoon str.split()

tot ik hier een oplossing zag die de normale library-functie gebruikte die het kennelijk toch wel goed deed