Advent of Code 2020

[Mschamp]

Vandaag viel ook mee en is gelukt.
Waarschijnlijk zijn er vlottere manieren, maar vond het best kort en leesbaar
https://github.com/mscham.../blob/master/2020/Day5.cs

[ProAce]

Beetje bitshiften later en dag 5 was ook klaar

https://github.com/ProAce...de/tree/master/2020/Day_5

[Woy]

Deze was ook weer makkelijk: https://github.com/rverst.../blob/main/Y2020/Day05.cs

spoiler:

Wat mij snel opvalt is dat veel mensen de row/column los parsen, maar dat is helemaal niet nodig, het ID is gewoon een binary number

[Caelorum]

Woy schreef op zaterdag 5 december 2020 @ 09:08:
Deze was ook weer makkelijk: https://github.com/rverst...de2020/blob/main/Day05.cs

spoiler:

Wat mij snel opvalt is dat veel mensen de row/column los parsen, maar dat is helemaal niet nodig, het ID is gewoon een binary number

Dat werkt beter inderdaad ^^ Soms zit je ook gewoon even 'vast' in het probleem en denk je niet al te ver na. Vond die berekening al "apart" en meestal betekent dat dat er een optimalisatie te vinden is.

[Wesley]

Ongetwijfeld dat dag 5 in code een stuk sneller en netter kon, toch ook wel weer gelukt in een sheet. Sheet trouwens publiek gezet: https://docs.google.com/s...luhgNc29yCQNG0/edit#gid=0.

[ppx17]

Deze was leuk! Day 5, in 13 regels Julia

[Bolukan]

Jammer dat deze oneliner overflowed bij >511

spoiler: EXCEL formule

=BIN2DEC(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE("BFFFFFFLLL";"F";"0");"B";"1");"R";"1");"L";"0"))

maar dit kan wel:

spoiler: andere EXCEL formule

=BIN2DEC(SUBSTITUTE(SUBSTITUTE(MID($A1;1;7);"F";"0");"B";"1"))*8+BIN2DEC(SUBSTITUTE(SUBSTITUTE(MID($A1;8;3);"R";"1");"L";"0"))

[ Voor 33% gewijzigd door Bolukan op 05-12-2020 11:15 ]

[com2,1ghz]

Nou Dag 5 part 1 was inderdaad een makkie.
https://github.com/com2gh...lin/nl/orhun/day5/Day5.kt

Part 2 heb ik een beetje afgekeken. Ik snapte, en snap nog steeds de opdracht niet.

Dus mijn seatId zou dus niet helemaal vooraan zitten maar ook niet achteraan. En alleen de seatId's met -1 en +1 zou in mijn lijst moeten zitten.
Kan iemand dit in andere woorden mij uitleggen?

[Wesley]

com2,1ghz schreef op zaterdag 5 december 2020 @ 11:34:
Nou Dag 5 part 1 was inderdaad een makkie.
https://github.com/com2gh...lin/nl/orhun/day5/Day5.kt

Part 2 heb ik een beetje afgekeken. Ik snapte, en snap nog steeds de opdracht niet.

Dus mijn seatId zou dus niet helemaal vooraan zitten maar ook niet achteraan. En alleen de seatId's met -1 en +1 zou in mijn lijst moeten zitten.
Kan iemand dit in andere woorden mij uitleggen?

Ergens in het lijstje met seatId's dat je hebt gevonden mist er een id, dat is jouw stoel. Die stoel is niet voor of achteraan, dus als je lijstje van 100 t/m 800 loopt is het niet 99 of 801, maar mist er ergens tussen die twee getallen 1 bepaald id.

[Moofnor]

Ik heb deel 2 uiteindelijk opgelost door alle rijen maar gewoon te printen. En uiteindelijk (voor het eerst) met regex het antwoord kunnen vinden.
https://github.com/Moofnor/AoC2020/tree/main/day4 in Java. Kan nog steeds heel veel beter, maar met 3 maanden ervaring ben ik al blij dat ik de puzzels op kan lossen

Wat betreft binair:

spoiler:

Ik moet toch eens eerst de hele opdracht lezen. Had de code voor de rijen net af toen ik doorkreeg dat je net zo goed de hele string in 1 keer kon converteren. Onder het mom van "misschien nodig in opdracht 2" maar zo gelaten

[Varienaja]

Ik vond het een leuke bijkomstigheid dat mijn stoelnummer 747 was. Of heeft iedereen die?

[Postman]

Varienaja schreef op zaterdag 5 december 2020 @ 11:58:
Ik vond het een leuke bijkomstigheid dat mijn stoelnummer 747 was. Of heeft iedereen die?

741 hier.

[Varienaja]

Het gaf mij hetzelfde gevoel als vroeger op een proefwerk wiskunde. Uitkomst een mooi getal? Dat is geen toeval, dat moet wel goed zijn!
Maar blijkbaar hier gewoon toeval.

[Hydra]

Oh deze was leuk!

Kotlin oplossing

Mooi gebruik maken van Kotlin extension functions (voor de split op IntRange) en fold-left

[Caelorum]

@Varienaja de input is random en verschilt per gebruiker, dus als je hier een mooi getal uitkrijgt zou ik het juist verdenken ^_^

[Varienaja]

@Caelorum Er zijn volgens mij maar een stuk of wat verschillende inputs en het had me niet verwonderd als alle mogelijke uitkomsten iets met vliegtuigtypes te maken hadden gehad. :-)

[WernerL]

Mijn TypeScript oplossing: https://github.com/Werner...blob/main/src/05/index.ts
Deze was wat leuker dan die van gisteren. Ook gekozen om de seatId in één keer te parsen. Begrijp niet waarom in de uitleg zo'n omslachtige manier vermeld staat.

[Hydra]

Fuck me. Left shifts. Goddamnit. Waarom ben ik daar niet opgekomen? Heb em aangepast

[Belindo]

Dag 5 maar weer in Excel. Daar werk ik dagelijks mee en voelt bij sommige opdrachten toch lekkerder dan PHP. @Daanoz, misschien kun je Excel/VBA toevoegen bij mijn naam in de OP?

Verder nog wel even mijn hoofd tegen de muur geslagen toen AOC mijn oplossing voor Part 1 steeds maar niet accepteerde. Hoe vaak kun je 995 invullen als er duidelijk op mijn scherm 955 staat 😛 Uitkomst voor Part 2 maar even copy/paste gedaan.

[Varienaja]

WernerL schreef op zaterdag 5 december 2020 @ 12:27:
Begrijp niet waarom in de uitleg zo'n omslachtige manier vermeld staat.

Anders was het geen puzzelen meer. En natuurlijk om de bokken van de schapen te scheiden. :-P

[DataGhost]

WernerL schreef op zaterdag 5 december 2020 @ 12:27:
Begrijp niet waarom in de uitleg zo'n omslachtige manier vermeld staat.

Heb je ooit met klanten gepraat die iets specifieks gemaakt willen hebben? En als ik naar jouw oplossing kijk heeft de "omslachtige manier" gewerkt want je hebt het "omslachtig" opgelost Het is veel simpeler als je er nog wat beter over nadenkt.

[ Voor 24% gewijzigd door DataGhost op 05-12-2020 12:39 ]

[WernerL]

DataGhost schreef op zaterdag 5 december 2020 @ 12:37:
[...]

Heb je ooit met klanten gepraat die iets specifieks gemaakt willen hebben?

Nog nooit een klant meegemaakt die mij verteld hoe een bepaald algorithme moet werken nee.

En als ik naar jouw oplossing kijk heeft de "omslachtige manier" gewerkt want je hebt het "omslachtig" opgelost Het is veel simpeler als je er nog wat beter over nadenkt.

Niet zo omslachtig als omschreven in de uitleg. Dan had ik row en column los berekend. Maar nu ben ik wel benieuwd hoe ik dit nog slimmer kan doen.

[ Voor 26% gewijzigd door WernerL op 05-12-2020 12:45 ]

[heuveltje]

Wesley schreef op zaterdag 5 december 2020 @ 11:40:
[...]


Ergens in het lijstje met seatId's dat je hebt gevonden mist er een id, dat is jouw stoel. Die stoel is niet voor of achteraan, dus als je lijstje van 100 t/m 800 loopt is het niet 99 of 801, maar mist er ergens tussen die twee getallen 1 bepaald id.

Hmm heb ik het per ongeluk goed gedaan dan.
Ik las het als "allebei de buren moeten er zijn" dus het kan best zijn dat stoel 107 en 108 ontbreken.
en dan waren beide niet goed geweest.

[Reptile209]

DataGhost schreef op zaterdag 5 december 2020 @ 12:37:
[...]

Heb je ooit met klanten gepraat die iets specifieks gemaakt willen hebben? En als ik naar jouw oplossing kijk heeft de "omslachtige manier" gewerkt want je hebt het "omslachtig" opgelost Het is veel simpeler als je er nog wat beter over nadenkt.

Voor hetzelfde geld was er in part 2 een M geïntroduceerd, dan zit je opeens trinair te rekenen (bitshifts kom je dan niet meer mee weg), of moet je toch per letter gaan werken.

[jelknab]

Woy schreef op zaterdag 5 december 2020 @ 09:08:
Deze was ook weer makkelijk: https://github.com/rverst...de2020/blob/main/Day05.cs

spoiler:

Wat mij snel opvalt is dat veel mensen de row/column los parsen, maar dat is helemaal niet nodig, het ID is gewoon een binary number

Dit is echt weer zo'n big brain oplossing waar ik jaloers op word >:(.
Dag 5 in C# maar dan blijkbaar onnodig groot uitgewerkt: https://github.com/jelkna...0Code%202020/Day5/Day5.cs

[ElkeBxl]

heuveltje schreef op zaterdag 5 december 2020 @ 12:50:
[...]


Hmm heb ik het per ongeluk goed gedaan dan.
Ik las het als "allebei de buren moeten er zijn" dus het kan best zijn dat stoel 107 en 108 ontbreken.
en dan waren beide niet goed geweest.

Maar de opdracht zegt dat het fully booked was dus dat zou niet kunnen voorkomen?

[DataGhost]

WernerL schreef op zaterdag 5 december 2020 @ 12:42:
[...]


Niet zo omslachtig als omschreven in de uitleg. Dan had ik row en column los berekend. Maar nu ben ik wel benieuwd hoe ik dit nog slimmer kan doen.

Hmm, met alleen maar hints is dat lastig, maar ik zal het proberen:

spoiler:

Kijk eens naar alleen de kolommen bijvoorbeeld (L en R). Dat zijn er maar 8. Schrijf ze allemaal eens uit en kijk wat je ziet gebeuren.

[heuveltje]

ElkeBxl schreef op zaterdag 5 december 2020 @ 12:53:
[...]

Maar de opdracht zegt dat het fully booked was dus dat zou niet kunnen voorkomen?

"some of the seats at the very front and back of the plane don't exist on this aircraft"
Ik interpreteerde dat dus als "sommige stoelnr's bestaan niet. Dus 100 en 101 bestaan, maar waar 102en103 zouden moeten staan, staat het karretje van de stewardess ofzo.

[ Voor 3% gewijzigd door heuveltje op 05-12-2020 13:39 ]

[WernerL]

DataGhost schreef op zaterdag 5 december 2020 @ 12:56:
[...]

Hmm, met alleen maar hints is dat lastig, maar ik zal het proberen:

spoiler:

Kijk eens naar alleen de kolommen bijvoorbeeld (L en R). Dat zijn er maar 8. Schrijf ze allemaal eens uit en kijk wat je ziet gebeuren.

spoiler:

Ik zag al staan in een van de eerdere spoilers dat de seat als binair getal behandeld kan worden. Ook hoorde ik iemand iets roepen over left-shift. Het is me gelukt om Hydra's implementatie te vertalen naar een reduce in TypeScript, maar was daar zelf dus nooit opgekomen.

//edit
spoier toegevoegd, just in case.

[ Voor 4% gewijzigd door WernerL op 05-12-2020 13:00 ]

[Mschamp]

Ik las "Your seat wasn't at the very front or back" eerst als, het is niet de eerste of de laatste rij. Dus ik deed al controle of bij de rij-nummers het niet 0 of 127 was

[DataGhost]

Reptile209 schreef op zaterdag 5 december 2020 @ 12:51:
[...]

Voor hetzelfde geld was er in part 2 een M geïntroduceerd, dan zit je opeens trinair te rekenen (bitshifts kom je dan niet meer mee weg), of moet je toch per letter gaan werken.

spoiler:

Je hoeft helemaal niet met bitshifts te werken als je in een bepaald talstelsel werkt. Dat kan je je taal/library voor je af laten handelen, of met wat simpele wiskunde zelf doen. De algemene vorm is ∑_i=0^n-1 (val[i] * baseⁱ) als je val "van achter naar voren bekijkt", dus 11₂ (11 binair) is 1 * 2⁰ + 1 * 2¹ = 3₁₀, en 47₁₀ = 7 * 10⁰ + 4 * 10¹. Op dezelfde manier voor 122₃ = 2 * 3⁰ + 2 * 3¹ + 1 * 3² = 17₁₀. Een bitshift is trouwens niet meer dan vermenigvuldigen met de base van je talstelstel tot de macht van je shift. Een bitshift 3 naar links (x<<3) is dus x * 2³. Trinair heb je dan x * 3³ voor hetzelfde.

[ Voor 10% gewijzigd door DataGhost op 05-12-2020 13:18 ]

[kaesve]

Deze was leuk inderdaad. Toen ik het trucje door had, kon ik stap 1 in 1 js regel in de console van de input pagina oplossen. Niks data downloaden ofzo.

spoiler:

[code]Math.max(...$0.innerText.trim().split("\n").map(l => parseInt(l.split("").map(c => Number(c == "B" || c == "R")).join(""), 2)))[/code]

Stap 2 was daarna ook niet meer zo moeilijk. Ik krijg alleen geen sterren op de tweakers leaderboard

[DataGhost]

kaesve schreef op zaterdag 5 december 2020 @ 13:19:
Ik krijg alleen geen sterren op de tweakers leaderboard

Ben je wel ingelogd met de juiste account?

[ Voor 46% gewijzigd door DataGhost op 05-12-2020 13:22 ]

[WernerL]

Ik realiseer me nu pas dat de parseInt functie in JavaScript een argument accepteert waarmee je de base kunt opgeven. Je kunt dus gewoon zoiets doen: parseInt("1001", 2)

Hiermee is het me gelukt mijn oplossing heel veel simpeler te maken.

spoiler:

const processLine = (line: string) =>
parseInt([...line].map((c) => (c == "B" || c == "R" ? 1 : 0)).join(""), 2);

[Hydra]

spoiler:

Ja, je kunt gewoon string-replaces zodat het een binair getal wordt, en die dan naar Int omzetten. In kotlin is dat .toInt(2). Maar ik ga het niet verder aanpassen, want dan is het echt helemaal niet meer 'mijn' oplossing.

[evanraalte]

spoiler:

Je kan de characters ook naar binair parsen doormiddel van c%7%2 (waar c de ascii waarde van het karakter representeert. e.g. in python ord('F') ).

[Osxy]

Hydra schreef op zaterdag 5 december 2020 @ 13:34:

spoiler:

Ja, je kunt gewoon string-replaces zodat het een binair getal wordt, en die dan naar Int omzetten. In kotlin is dat .toInt(2). Maar ik ga het niet verder aanpassen, want dan is het echt helemaal niet meer 'mijn' oplossing.

Dat is letterlijk hoe ik in C# heb gedaan. Erg simpele dag daardoor.

https://github.com/osxy/A...2020/AoC2020/Days/Day5.cs

[ Voor 8% gewijzigd door Osxy op 05-12-2020 13:46 ]

[_Mithrandir]

Vanonchtend nog even deel 2 van gisteren afgemaakt. Het was nogal wat werk. Net die van vandaag gedaan. Ging een stuk sneller

[P_Tingen]

Die van vandaag was een eitje. Ik had hem vanmorgen al gelezen maar was er nog niet aan toegekomen. Nu deel 1 in 6 minuten en deel 2 in drie minuten gedaan: day 5 in OpenEdge 4GL

Even laten bezinken heeft ook zo zijn voordelen trouwens:

spoiler:

Toen ik vanmorgen naar het zwembad reed drong het tot me door dat zowel het FB gedeelte als het LR deel een binair getal is dat je in 1x kan verwerken. Dus de FB's en de LR's replacen naar 0 en 1 en zo in een bin2dec functie.

Ik had gegokt dat deel 2 zou zijn dat mijn stoelnummer het enige ontbrekende nummer was, maar ik had er geen rekening mee gehouden dat sommige nummers niet zouden bestaan.

[MrHaas]

spoiler:

Volgens mij nog niet voorbij zien komen hier, maar om de gap te vinden in part B kan je ook gewoon de som van de totale lijst nemen en daar de som van je id-lijst aftrekken. Som van een lijst opeenvolgende nummers kun je bereken door (max^2 - min^2 + min +max).

Mijn implementatie: https://github.com/arjand...ain/day05/src/main.rs#L21

[ Voor 15% gewijzigd door MrHaas op 05-12-2020 13:51 ]

[evanraalte]

MrHaas schreef op zaterdag 5 december 2020 @ 13:49:

spoiler:

Volgens mij nog niet voorbij zien komen hier, maar om de gap te vinden in part B kan je ook gewoon de som van de totale lijst nemen en daar de som van je id-lijst aftrekken. Som van een lijst opeenvolgende nummers kun je bereken door (max^2 - min^2 + min +max).

Mijn implementatie: https://github.com/arjand...ain/day05/src/main.rs#L21

spoiler:

Dat kan ook ja, mits je de 'valide' zit plaatsen stelt als je totale lijst.

Heb het zelf met 2 set operaties in python gedaan: https://github.com/evanra.../blob/master/day5/day5.py

[MrHaas]

evanraalte schreef op zaterdag 5 december 2020 @ 14:04:
[...]

spoiler:

Dat kan ook ja, mits je de 'valide' zit plaatsen stelt als je totale lijst.

Heb het zelf met 2 set operaties in python gedaan: https://github.com/evanra.../blob/master/day5/day5.py

Ik ben vooral gecharmeerd van deze:

spoiler:

str(ord(z)%7%2)

Goed gevonden!

[Varienaja]

Caelorum schreef op vrijdag 4 december 2020 @ 15:46:
compactheid is overrated.

The Applications Division at Microsoft experiences about 10–20 defects per 1000 lines of code during in-house testing and 0.5 defects per 1000 lines of code in released product

Dit lijkt me een goed argument om korte code te verkiezen boven lange code.

[wmkuipers]

Varienaja schreef op zaterdag 5 december 2020 @ 15:54:
[...]


[...]

Dit lijkt me een goed argument om korte code te verkiezen boven lange code.

Ho ho dit is slaat natuurlijk als een tang op een varken, hiermee impliceer je dat korte code en lange code ook dezelfde foutgevoeligheid hebben, en dat daarom korte code te prefereren is.

volgens dezelfde drogreden: Als ik bezopen ben stap ik liever in de auto en rij veel harder, dan zijn er minder minuten waarin ik een ongeval kan krijgen.

Ik prefereer leesbare code die mijn collega's ook met vertrouwen kunnen editten, op die manier reduceren wij het aantal fouten in de code.

[ Voor 12% gewijzigd door wmkuipers op 05-12-2020 16:00 ]

[Varienaja]

Als je collega's je code moeten refactoren is _ook_ korte code te verkiezen boven lange code. Immers: voordat je 100 lijnen begrepen hebt ben je langer bezig dan voor 50. Leesbaar moet je code altijd zijn, kort of lang.

[ Voor 12% gewijzigd door Varienaja op 05-12-2020 16:08 ]

[Rips10]

Code uitdrukken in kort of lang is altijd subjectief, zodra daar het woordje te ... voor komt te staan is het allebei niet goed. Code moet gewoon leesbaar zijn, dat is het allerbelangrijkste.

[ydderf]

Dag 5 in C# ook gereed. Was goed te doen.

spoiler:

Twijfelde bij deel 1 om om te zetten naar binaire code, en maar gegokt dat ik de rij en/of kolom voor deel twee nog wel nodig zou hebben. Dus alles maar netjes uitgesplitst....

[Dricus]

Rips10 schreef op zaterdag 5 december 2020 @ 16:48:
Code uitdrukken in kort of lang is altijd subjectief, zodra daar het woordje te ... voor komt te staan is het allebei niet goed. Code moet gewoon leesbaar zijn, dat is het allerbelangrijkste.

• En beknopte code is doorgaans leesbaarder dan langdradige code.
• En code met minder mogelijke executiepaden (lage cyclomatic complexity) is doorgaans leesbaarder dan code met veel mogelijke executiepaden.
• En functies/classes die 1 responsibility hebben zijn doorgaans leesbaarder dan functies/classes met meerdere responsibilities.
• En functies met weinig parameters zijn doorgaans leesbaarder dan functies met veel parameters.

Het thema is: Less is more!

En ja, je kunt overal in doorschieten, maar zeggen dat kort of lang subjectief is, is gewoon een enorme dooddoener en voegt helemaal niks toe. Er is een heel zinvolle en leerzame discussie te voeren over wat code kwaliteit inhoudt. Dit wordt veelvuldig gedaan, en er zijn allerlei statische code analyse tools die een poging doen om dat de kwantificeren.

De Software Improvement Group is een voorbeeld van een organisatie die serieus met code kwaliteit bezig is. Zij hanteren een wetenschappelijk onderbouwd model (ISO/IEC 25010:2011) voor het meten van code kwaliteit. En guess what? Alle metrieken die zij in kaart brengen gaan over veel versus weinig en lang versus kort. En met beknopte, simpele code ga je daarin altijd beter scoren dan met langdradige ingewikkelde code.

Natúúlijk moet het niet té kort of té lang, en daardoor obscuur zijn, daar zal iedereen het over eens zijn. Maar met dat in het achterhoofd te suggereren dat er eigenlijk geen zinvolle discussie over te voeren is omdat het toch allemaal subjectief is, is gewoon onzin en contraproductief.

Excuus voor deze wat pittig geformuleerde rant, maar ik vind het een groot probleem dat dit onderwerp door te veel collega IT'ers naar mijn mening onvoldoende serieus genomen wordt.

[Camulos]

Osxy schreef op zaterdag 5 december 2020 @ 13:45:
[...]
Dat is letterlijk hoe ik in C# heb gedaan. Erg simpele dag daardoor.

Had dit initieel ook als gedachte, maar om 2x omzetten/converten te omzeilen gewoon in 1x doorheen parsen (zonder meteen binary search te implementeren).

Sowieso ben ik erg gecharmeerd van de Range expressies (C#8), waardoor substrings ook niet meer zo clunky aanvoelen. Zoals geeft me de laatste 3 chars van een regel wordt dan

code:

var last3chars = line[^3..]

[ Voor 13% gewijzigd door Camulos op 05-12-2020 17:56 ]

[Soultaker]

Woy schreef op zaterdag 5 december 2020 @ 09:08:

spoiler:

Wat mij snel opvalt is dat veel mensen de row/column los parsen, maar dat is helemaal niet nodig, het ID is gewoon een binary number

Dit bedacht ik ook nét nadat ik klaar was met de oplossing. Maar wat mij dan weer opvalt is dat mensen doen alsof deze observatie de implementatie enorm veel simpeler maakt. Zonder deze versimpeling is de code nog steeds vrij eenvoudig (code).

MrHaas schreef op zaterdag 5 december 2020 @ 13:49:

spoiler:

Volgens mij nog niet voorbij zien komen hier, maar om de gap te vinden in part B kan je ook gewoon de som van de totale lijst nemen en daar de som van je id-lijst aftrekken.

Ook een goede observatie. Daarmee kun je het probleem in principe in O(1) ruimte oplossen. Heel veel praktisch nut heeft het in dit geval niet.

spoiler:

Som van een lijst opeenvolgende nummers kun je bereken door (max^2 - min^2 + min +max).

Volgens mij mis je hier een deling door twee.

spoiler:

Som van 0..x = x × (x + 1) / 2, dus
Som van a..b = b × (b + 1) / 2 - a × (a - 1) / 2 = (b² - a² + a + b)/2

aangenomen 0 ≤ a ≤ b.

[MrHaas]

Soultaker schreef op zaterdag 5 december 2020 @ 17:59:
[...]

Volgens mij mis je hier een deling door twee.

Oops, my bad

[Rips10]

Dricus schreef op zaterdag 5 december 2020 @ 17:45:
[...]

• En beknopte code is doorgaans leesbaarder dan langdradige code.
• En code met minder mogelijke executiepaden (lage cyclomatic complexity) is doorgaans leesbaarder dan code met veel mogelijke executiepaden.
• En functies/classes die 1 responsibility hebben zijn doorgaans leesbaarder dan functies/classes met meerdere responsibilities.
• En functies met weinig parameters zijn doorgaans leesbaarder dan functies met veel parameters.

Het thema is: Less is more!

En ja, je kunt overal in doorschieten, maar zeggen dat kort of lang subjectief is, is gewoon een enorme dooddoener en voegt helemaal niks toe. Er is een heel zinvolle en leerzame discussie te voeren over wat code kwaliteit inhoudt. Dit wordt veelvuldig gedaan, en er zijn allerlei statische code analyse tools die een poging doen om dat de kwantificeren.

De Software Improvement Group is een voorbeeld van een organisatie die serieus met code kwaliteit bezig is. Zij hanteren een wetenschappelijk onderbouwd model (ISO/IEC 25010:2011) voor het meten van code kwaliteit. En guess what? Alle metrieken die zij in kaart brengen gaan over veel versus weinig en lang versus kort. En met beknopte, simpele code ga je daarin altijd beter scoren dan met langdradige ingewikkelde code.

Natúúlijk moet het niet té kort of té lang, en daardoor obscuur zijn, daar zal iedereen het over eens zijn. Maar met dat in het achterhoofd te suggereren dat er eigenlijk geen zinvolle discussie over te voeren is omdat het toch allemaal subjectief is, is gewoon onzin en contraproductief.

Excuus voor deze wat pittig geformuleerde rant, maar ik vind het een groot probleem dat dit onderwerp door te veel collega IT'ers naar mijn mening onvoldoende serieus genomen wordt.

Kijk dit is nou een duidelijk bericht, als het op deze manier geformuleerd wordt ben ik het er helemaal mee eens. Aanleiding van mijn bericht waren de voorgaande berichten die gewoon behoorlijk vaag blijven. Het vaag zijn daar doe ik overigens net zo goed aan mee in mijn vorige bericht

[Osxy]

Camulos schreef op zaterdag 5 december 2020 @ 17:51:
[...]


Had dit initieel ook als gedachte, maar om 2x omzetten/converten te omzeilen gewoon in 1x doorheen parsen (zonder meteen binary search te implementeren).

Sowieso ben ik erg gecharmeerd van de Range expressies (C#8), waardoor substrings ook niet meer zo clunky aanvoelen. Zoals geeft me de laatste 3 chars van een regel wordt dan

code:

var last3chars = line[^3..]

De range expressie wordt ik ook erg happy van maar oude gewoontes enzo. Persoonlijk vond ik converteren naar binary logischer en stuk minder code.

[ Voor 4% gewijzigd door Osxy op 05-12-2020 19:43 ]

[Reynouts]

Dricus schreef op zaterdag 5 december 2020 @ 17:45:
[...]

• En beknopte code is doorgaans leesbaarder dan langdradige code.
• En code met minder mogelijke executiepaden (lage cyclomatic complexity) is doorgaans leesbaarder dan code met veel mogelijke executiepaden.
• En functies/classes die 1 responsibility hebben zijn doorgaans leesbaarder dan functies/classes met meerdere responsibilities.
• En functies met weinig parameters zijn doorgaans leesbaarder dan functies met veel parameters.

Het thema is: Less is more!

Natuurlijk helemaal eens met je genoemde punten. Echter betekent dat uiteindelijk niet dat je minder of compactere code schrijft. Zeker je derde punt betekent misschien meer code, maar betere onderhoudbaarheid en uitbreidbaarheid.

Laten we "hoe goed" code isvooral niet uitdrukken in regels code of compactheid van code. Sommige slaan daarin echt door. Parameternamen met 1 letter, zoveel mogelijk op 1 regel proppen, omdat het dan op 1 regel staat, terwijl er verschillenden operaties worden uitgevoerd, etc.

[ Voor 25% gewijzigd door Reynouts op 05-12-2020 19:50 ]

[Reynouts]

Terug naar AoC! Als ik de afgelopen jaren bekijk via dit toffe overzicht en met de interviews met Topaz , gok ik dat morgen een grotere puzzel gaat zijn, waar misschien wel meer tijd in gaat zitten dan voorgaande puzzels bij elkaar. Wat denken jullie? En mag het van jullie wat moeilijker?

Ik vind deze moeilijkheidsgraad leuk. Iedereen kan een oplossing verzinnen. Er kan gediscussieerd worden over mogelijke snellere oplossingen met een lagere complexiteit, maar het is niet noodzakelijk voor de sterren (up the ante op reddit). Zo blijven denk ik meer mensen gemotiveerd om door te gaan.

Ergens zal vast weer een dag komen zoals dag 22 van vorig jaar. Dan hoop ik dat ik hier tips kan krijgen

[ Voor 200% gewijzigd door Reynouts op 05-12-2020 19:50 ]

[Down]

Voor dag 5 weer gewisseld van C# naar JS.

Deel 1
Deel 2

Ik was ook begonnen met bit shiften en toen ik klaar was viel het kwartje dat het 'gewoon' binary was . Dat was gelukkig lekker simpel met parseInt(x, 2). Ik vergeet echter nog wel eens dat de string replace in JS eigenlijk regex is, dus er moest nog een /g op het eind.

Meestal doe ik dit soort dingen in C#, maar ik ben stiekem toch wel erg van JS gaan houden, ondanks al z'n nukken. Hier miste ik dan weer b.v. een simpele range, min of max en moest daar weer een (klein) beetje moeite voor doen.

Ik zie alleen dat ik qua efficiëntie nog iets heb gemist:

spoiler:

De laatste bepaling van deel 2 kan gewoon in O(1) zoals iemand hier aangaf, nice.

[ThoNohT]

Sinterklaasvieringen dus ik ben wat laat. Maar ik ben tevreden met de oplossing die ik in een half uurtje heb weten te maken.

[Dricus]

Reynouts schreef op zaterdag 5 december 2020 @ 19:48:
Sommige slaan daarin echt door.

Dit is een open deur die in dit soort gesprekken vaak tot in den treure herhaald wordt en daardoor disproportioneel veel aandacht krijgt en die in mijn ervaring ook vrij theoretisch is. Ik kom in de praktijk maar weinig tegen dat er te weinig code geschreven wordt. Overengineering en onnodige complexiteit kom ik véél vaker tegen. Als iedere developer YAGNI en Clean Code boven zijn/haar bed zou hangen, dan zou de wereld er een stuk mooier uitzien .

Laten we "hoe goed" code isvooral niet uitdrukken in regels code of compactheid van code.

Het is niet de be all end all, maar wel een bruikbare en belangrijke metriek om code kwaliteit, of beter: onderhoudbaarheid mee te meten. Zie ook de eerder genoemde ISO/IEC 25010:2011 standaard.

[ Voor 36% gewijzigd door Dricus op 05-12-2020 22:45 ]

[Kalentum]

Dricus schreef op zaterdag 5 december 2020 @ 17:45:
[...]

• En beknopte code is doorgaans leesbaarder dan langdradige code.
• En code met minder mogelijke executiepaden (lage cyclomatic complexity) is doorgaans leesbaarder dan code met veel mogelijke executiepaden.
• En functies/classes die 1 responsibility hebben zijn doorgaans leesbaarder dan functies/classes met meerdere responsibilities.
• En functies met weinig parameters zijn doorgaans leesbaarder dan functies met veel parameters.

Het thema is: Less is more!

En ja, je kunt overal in doorschieten, maar zeggen dat kort of lang subjectief is, is gewoon een enorme dooddoener en voegt helemaal niks toe. Er is een heel zinvolle en leerzame discussie te voeren over wat code kwaliteit inhoudt. Dit wordt veelvuldig gedaan, en er zijn allerlei statische code analyse tools die een poging doen om dat de kwantificeren.

De Software Improvement Group is een voorbeeld van een organisatie die serieus met code kwaliteit bezig is. Zij hanteren een wetenschappelijk onderbouwd model (ISO/IEC 25010:2011) voor het meten van code kwaliteit. En guess what? Alle metrieken die zij in kaart brengen gaan over veel versus weinig en lang versus kort. En met beknopte, simpele code ga je daarin altijd beter scoren dan met langdradige ingewikkelde code.

Natúúlijk moet het niet té kort of té lang, en daardoor obscuur zijn, daar zal iedereen het over eens zijn. Maar met dat in het achterhoofd te suggereren dat er eigenlijk geen zinvolle discussie over te voeren is omdat het toch allemaal subjectief is, is gewoon onzin en contraproductief.

Excuus voor deze wat pittig geformuleerde rant, maar ik vind het een groot probleem dat dit onderwerp door te veel collega IT'ers naar mijn mening onvoldoende serieus genomen wordt.

Ik neem altijd maar aan dat elke commit door een Linter gaat en dat die afdwingt dat je geen lange methods of classes hebt. Dus ofwel je schrijft fatsoenlijke leesbare code ofwel je schakelt bepaalde checks van de linter uit en hebt goede redenen daarvoor.

[Varienaja]

Jeetje wat ben ik een prutser. Helemaal geen ingewikkelde puzzle, maar ik heb enorm tijd verspild met dom debuggen (de laatste regel van de input _leek_ leeg, maar was het niet, en daarom werd de laatste groep niet meegeteld. Ik moet er geloof ik mee ophouden als laatste regel een lege lijn te verwachten in de input..) en tikfoutjes opsporen. Ik heb vannacht ook niet lekker geslapen. Is dat het? :-)

>klik<

[ Voor 23% gewijzigd door Varienaja op 06-12-2020 06:47 ]

[Woy]

Soultaker schreef op zaterdag 5 december 2020 @ 17:59:
[...]

Dit bedacht ik ook nét nadat ik klaar was met de oplossing. Maar wat mij dan weer opvalt is dat mensen doen alsof deze observatie de implementatie enorm veel simpeler maakt. Zonder deze versimpeling is de code nog steeds vrij eenvoudig (code).

Niet perse heel erg, als je zoals jij al een goed begrip van het probleem hebt. Maar het helpt wel om het "probleem" beter te doorgronden.

[Woy]

Day 6 was ook weer goed te doen: https://github.com/rverst.../blob/main/Y2020/Day06.cs

Ik hoop dat ik er vanaf morgen nog genoeg tijd voor heb, aangezien het dan weer drukker is op het werk

[ Voor 36% gewijzigd door Woy op 21-12-2020 16:12 ]

[Woy]

Varienaja schreef op zondag 6 december 2020 @ 06:37:
klik<

Ik blijf mij toch ergeren aan jouw single file oplossing , moet je verder natuurlijk helemaal zelf weten, maar ik begin er bijna van tegen mijn scherm te schreeuwen

[Varienaja]

Woy schreef op zondag 6 december 2020 @ 07:01:
Ik blijf mij toch ergeren aan jouw single file oplossing , moet je verder natuurlijk helemaal zelf weten, maar ik begin er bijna van tegen mijn scherm te schreeuwen

Om even te laten zien met een linkje naar Github is het inderdaad niet ideaal. Maar in de IDE merk ik er niks van.

Mooie Code overigens @Woy, al vat ik "x=>x.Count() == grp.Length)" mentaal nog niet.

[ Voor 10% gewijzigd door Varienaja op 06-12-2020 07:15 ]

[Woy]

Varienaja schreef op zondag 6 december 2020 @ 07:09:
[...]
Mooie Code overigens @Woy, al vat ik "x=>x.Count() == grp.Length)" mentaal nog niet.

De lookup is een collectie van de mensen binnen de groep met dat antwoord, als dat aantal gelijk is aan de groep grootte heeft iedereen het antwoord gegeven.

[ Voor 3% gewijzigd door Woy op 06-12-2020 07:24 ]

[ppx17]

Dag 6 in Julia.

Uiteindelijk was hij wel te doen, maar heb toch even 3 kwartier vast gezeten op deel 2.

spoiler:

Input vergeten te trimmen, dus de laatste regel werd als een lege set gelezen, na de intersection was er geen antwoord meer over voor de onderste groep, dus miste een hele groep in de som.

[MrHaas]

Had gehoopt op wat moeilijke puzzel voor mn vrije zondag .

spoiler:

Oplossing in Rust

Deel 2 was zowat copy paste en de set operator aanpassen.

[Dricus]

Dag 6
Leuke opdracht weer, alhoewel ik de opdrachten tot nu toe wel erg makkelijk vind. Hopelijk worden ze nog iets uitdagender.

De antwoorden had ik snel, maar ik heb nog wel wat tijd besteed om de code een beetje begrijpelijk te maken. Bij zo'n aaneenschakeling van map, flatMap, fold is het soms lastig om te zien waar zo'n operatie precies voor bedoeld is. Ik vind mijn poging om met een minimaal "domeinmodelletje" de boel wat inzichtelijker te maken best redelijk geslaagd.

Oh, en jammer dat je in Kotlin bij een flatMap van sets een list van alle elementen in die sets terugkrijgt, in plaats van een set. Daar zal vast een gedachte achter zitten, maar het voelt voor mij niet intuïtief.

[armageddon_2k1]

Eitje deze :-)

https://github.com/rj-cod.../rjcoding/aoc2020/Day6.kt

spoiler:

Gewoon union en intersect van sets. Even rekening houden bij de intersect dat je moet beginnen met het hele alfabet natuurlijk.

[armageddon_2k1]

MrHaas schreef op zondag 6 december 2020 @ 08:45:
Had gehoopt op wat moeilijke puzzel voor mn vrije zondag .

Dan heb je nu tenminste gewoon tijd voor klusjes!

[MrHaas]

armageddon_2k1 schreef op zondag 6 december 2020 @ 08:50:

spoiler:

Gewoon union en intersect van sets. Even rekening houden bij de intersect dat je moet beginnen met het hele alfabet natuurlijk.

Heeft Kotlin geen fold-variant waar het eerste element als de initial wordt gebruikt?

[Dricus]

MrHaas schreef op zondag 6 december 2020 @ 08:59:
Heeft Kotlin geen fold-variant waar het eerste element als de initial wordt gebruikt?

Goeie, net even uitgezocht en Kotlin heeft dat wel, alleen heet het dan reduce.

[Wesley]

Somehow deel 1 verkeerd gelezen en daar opnieuw moeten beginnen, bleek bij deel 2 dat dat was wat ik eerst voor 1 had gedaan dus dat was snel opgelost Stuk makkelijker dan de vorige 2 dagen.

[heuveltje]

Zucht eerst te snel gelezen, en op de 2e manier geimplementeerd.
na 10 min vraag nog eens gelezen. en toen goed geimplementeerd.

Om het vervolgens alsnog op de andere manier te moeten doen die ik natuurlijk al weggegooid had

Maar deze was eigenlijk best wel simpel in vergelijking met vorige.
En ik heb weer een nieuw commando geleerd : set

Wel moet ik me verplichten het creatief(voor deze n00b dan) op te lossen.
Want volgens mij was alles tot nu toe ook nog prima te doen met wat for loopjes en if statements.

[ Voor 19% gewijzigd door heuveltje op 06-12-2020 09:35 ]

[vliegnerd]

Ik doe ook mee, maar was hier nog niet echt aan het meelezen ;-)

De puzzel van gisteren (dag 5) vond ik echt leuk, omdat er een (best wel voor de hand liggende) oplossing is die veel leuker, sneller is dan "naief het voorbeeld implementeren".
Ik had echt zo'n "klok en klepel" gevoel en heb eerst maar de naieve oplossing geimplementeerd. Pas een paar uurtjes later viel het kwartje ineens en heb ik alsnog de leuke oplossing geimplementeerd.

spoiler:

De oplossing waarbij je de FB en LR gewoon als 01 schrijft en een binair getal leest

Vandaag een simpele vinger oefening. Geen probleem, maar ik heb dat* wel ooit geleerd in AoC, dus zeker nuttig en niet verkeerd om op de luie zondag een kort puzzeltje te doen.

*dat =

spoiler:

sets

https://github.com/tomkooij/AdventOfCode/tree/master/aoc2020

[Dricus]

armageddon_2k1 schreef op zondag 6 december 2020 @ 08:50:
Eitje deze :-)

https://github.com/rj-cod.../rjcoding/aoc2020/Day6.kt

spoiler:

Gewoon union en intersect van sets. Even rekening houden bij de intersect dat je moet beginnen met het hele alfabet natuurlijk.

Prachtig! Geïnspireerd door jouw code en de ontdekking van de reduce functie ben ik nog een beetje aan het refactoren geslagen.

[Hydra]

Deze was wel heel simpel.

Day 6 in Kotlin

[armageddon_2k1]

MrHaas schreef op zondag 6 december 2020 @ 08:59:
[...]


Heeft Kotlin geen fold-variant waar het eerste element als de initial wordt gebruikt?

Jup reduce. Gewoon een brain fart.

[Hydra]

MrHaas schreef op zondag 6 december 2020 @ 08:45:
Had gehoopt op wat moeilijke puzzel voor mn vrije zondag .

Ja man. Was er helamaal voor gaan zitten. Op m'n werkkamertje, fles koffie, stuk sloffe amandelstaaf. Ben je in no time klaar.

Weet wel van voorgaande jaren dat de eerste week altijd vrij simpel was, maar dat de weekenden daarop vaak opdrachten kwamen die een stuk meer tijd kostten.

[Hydra]

Dricus schreef op zondag 6 december 2020 @ 08:48:
Dag 6
Oh, en jammer dat je in Kotlin bij een flatMap van sets een list van alle elementen in die sets terugkrijgt, in plaats van een set. Daar zal vast een gedachte achter zitten, maar het voelt voor mij niet intuïtief.

Normaliter als je meerde operaties achter elkaar doet, doe je dat ook op sequences. Die zijn lazy, i.p.v. map/flatMap e.d. op Lists en Sets, die zijn eager. In m'n AoC code doe ik dat alleen vrijwel nooit omdat het meer ruimte kost en toch niet uitmaakt.

[ Voor 6% gewijzigd door Hydra op 06-12-2020 10:17 ]

[veldsla]

Ja, heel simpel (oude revisie), maar toch van alle dagen veruit de traagste:

Bash:

 ./target/release/aoc2020 --all
day parse     part1     part2    total      output  
1   23.074µs  2.3µs     1.552µs  26.926µs   539851  212481360
2   213.361µs 20.987µs  61.996µs 296.344µs  465     294
3   88.782µs  1.504µs   5.389µs  95.675µs   164     5007658656
4   381.366µs 41.123µs  50.056µs 472.545µs  200/265 116/265
5   53.024µs  583ns     22.328µs 75.935µs   901     661
6   118.321µs 382.422µs 276.77µs 777.513µs  6565    3137
all                              1.898134ms         

Misschien toch nog eens naar kijken....

Kleine aanname op de data helpt al een hoop:

code:

6   119.396µs 29.524µs 29.583µs 178.503µs  6565    3137

Parser nog wat aangepast....Zo blijven we toch lekker bezig (laatse versie)

code:

6   103.112µs 17.422µs 16.923µs 137.457µs  6565    3137

[ Voor 22% gewijzigd door veldsla op 24-12-2020 11:58 ]

[Hydra]

Heb even een extra utility function gemaakt omdat we nu al 2 dagen input strings in blokken in moeten lezen. Vergeet ik ook niet meer extra newlines eraf te trimmen

[Belindo]

Link: dag 6 in PHP
Voor mijn doen relatief snel opgelost met weinig code.

Vraag voor de experts; is het aan te raden om elke stap uit te schrijven, of combineer je het gewoon in één regel?

Bijvoorbeeld dit stukje:

PHP:

    //keep only the unique answers
    $unique_answers = count_chars($answers_clean,3);

    //count unique answers
    $unique_answers_count = strlen($unique_answers);

    //add count of unique characters to the total
    $result_part1 = $result_part1 + $unique_answers_count;

kan natuurlijk ook samengevoegd worden tot één regel:

PHP:

    //add count of unique characters to the total
    $result_part1 = $result_part1 + strlen(count_chars($answers_clean,3));

Tevens doe ik voor Part 2 een foreach door het hele alfabet om te kijken hoe vaak een letter ('vraag') voorkomt, en of dit aantal overeenkomt met het aantal mensen in de groep. Omdat niet in elke groep elk van de 26 letters voorkomt, lijkt het mij nogal redundant om toch door elke letter te lopen.

(Ik kan helaas geen code in de spoiler tag doen, als de code open en bloot niet wenselijk is, laat het dan even weten, dan haal ik het weg)

[Daanoz]

Belindo schreef op zaterdag 5 december 2020 @ 12:30:
Dag 5 maar weer in Excel. Daar werk ik dagelijks mee en voelt bij sommige opdrachten toch lekkerder dan PHP. @Daanoz, misschien kun je Excel/VBA toevoegen bij mijn naam in de OP?

Done!

Pff, vandaag te lang lopen zoeken naar een linebreak die ik teveel in mijn input gekopieerd had , meteen maar even gezorgd dat die in toekomstige puzzels automatisch eruit getrimmed wordt.

[Osxy]

Belindo schreef op zondag 6 december 2020 @ 10:43:
Link: dag 6 in PHP
Voor mijn doen relatief snel opgelost met weinig code.

Vraag voor de experts; is het aan te raden om elke stap uit te schrijven, of combineer je het gewoon in één regel?

Bijvoorbeeld dit stukje:

PHP:

    //keep only the unique answers
    $unique_answers = count_chars($answers_clean,3);

    //count unique answers
    $unique_answers_count = strlen($unique_answers);

    //add count of unique characters to the total
    $result_part1 = $result_part1 + $unique_answers_count;

kan natuurlijk ook samengevoegd worden tot één regel:

PHP:

    //add count of unique characters to the total
    $result_part1 = $result_part1 + strlen(count_chars($answers_clean,3));

Tevens doe ik voor Part 2 een foreach door het hele alfabet om te kijken hoe vaak een letter ('vraag') voorkomt, en of dit aantal overeenkomt met het aantal mensen in de groep. Omdat niet in elke groep elk van de 26 letters voorkomt, lijkt het mij nogal redundant om toch door elke letter te lopen.

(Ik kan helaas geen code in de spoiler tag doen, als de code open en bloot niet wenselijk is, laat het dan even weten, dan haal ik het weg)

spoiler:

Wbt Part 2. Kijk of je alle unieke characters uit de groep kan ophalen, dan hoef je hier alleen nog maar doorheen te loopen.

[Creepy]

Even wat inhalen nog.... net dag 4 afgerond. Ik parse regel voor regel en ga bij een lege regel controleren of de verzamelde properties goed waren. Echt te lang bezig geweest voordat ik me realiseerde dat ik dus de laatste set nooit valideer omdat je dan tegen het einde van de file zit en er geen lege regel is....

Nu aan de slag met dag 5 en 6.

[WernerL]

Dag 6 ook weer afgerond.

https://github.com/Werner...blob/main/src/06/index.ts

[Soultaker]

veldsla schreef op zondag 6 december 2020 @ 10:34:
Parser nog wat aangepast....Zo blijven we toch lekker bezig (laatse versie)

code:

6   103.112µs 17.422µs 16.923µs 137.457µs  6565    3137

Hoewel de meeste tijd nu waarschijnlijk in de I/O zit, denk ik dat je het geheel nog net iets sneller kan maken

spoiler:

door sets als bitmasks te representeren

(voorbeeld code).

[jelknab]

Best snel klaar vandaag, ben benieuwd of er dit jaar weer zo'n uitdaging in zit die zich over meerdere dagen verspreid (int code).

Oplossing in C#: https://github.com/jelkna...0Code%202020/Day6/Day6.cs

[Creepy]

Dag 5 was wel weer simpel als je door hebt hoe de ID's werken.

spoiler:

Zoeken en vervangen met 1'en en 0'en, string als binary parsen en gaan.. Voor part 2 de boel sorteren en het missende ID er tussenuit halen..

Tijd voor lunch en dan dag 6, het lijkt bijna werk

[ Voor 11% gewijzigd door Creepy op 06-12-2020 12:42 ]

[Camulos]

jelknab schreef op zondag 6 december 2020 @ 12:30:
Best snel klaar vandaag, ben benieuwd of er dit jaar weer zo'n uitdaging in zit die zich over meerdere dagen verspreid (int code).

Oplossing in C#: https://github.com/jelkna...0Code%202020/Day6/Day6.cs

Mooi gebruik van LINQ!
Je zou trouwens de FindUniqueAnswers-methode kunnen vervangen door een HashSet<char> te gebruiken. Deze heeft alleen unique waarden, zie voorbeeld

[DRaakje]

Mijn C# oplossing. Ook voornamelijk in Linq.
https://pastebin.com/qfZTrWHm

[MaNDaRK]

Ik doe ook weer mee in Python.

Ik vond day 3 wel leuk, dus ik heb een animatie er van gemaakt:

( voor het eerst dat ik zoiets probeer )

[Soultaker]

MaNDaRK schreef op zondag 6 december 2020 @ 13:14:
Ik vond day 3 wel leuk, dus ik heb een animatie er van gemaakt:
[Afbeelding]
( voor het eerst dat ik zoiets probeer )

Werkt misschien beter in 2D? Ik vind het persoonlijk niet heel duidelijk wat er gebeurt.

[Creepy]

En ook dag 6 weer af. Ook weer een eitje inderdaad.

spoiler:

(Hash)Set gebruiken en gaan. Alle chars toevoegen en totaal tellen voor deel 1, deel 2 simpelweg .retainAll() gebruiken en weer tellen....

Deze keer niet vergeten de laatste set ook mee te nemen

[Hydra]

@Creepy vind het met dit soort opdrachten altijd wel opvallend hoe beperkt de Java API is t.o.v. Kotlin. Vind het wel jammer dat m'n huidige project nu weer Java gaat zijn na 2 jaar Kotlin.

[Creepy]

Ik snap wat je bedoeld gezien je oplossing ja. Java heeft wat dat betreft een hoop legacy waardoor je niet alles zomaar in een stream kan gooien. Ik zie aan de hand van jou code nog wel mogelijkheden om de mijne nog wat meer gebruik te kunnen laten maken van Streams.reduce()

Eigenlijk toch eens kijken of ik m'n code weer ergens online kan zeten...

[MaNDaRK]

Soultaker schreef op zondag 6 december 2020 @ 13:29:
[...]

Werkt misschien beter in 2D? Ik vind het persoonlijk niet heel duidelijk wat er gebeurt.

Leuk idee, maar ik vond dit al een ding, haha.


Maar voor de verduidelijking, de skiër, gaat over de sneeuw en als hij een boom raakt, dan wordt het een taai-taai mannetje

[MrHaas]

Soultaker schreef op zondag 6 december 2020 @ 12:24:
[...]

Hoewel de meeste tijd nu waarschijnlijk in de I/O zit, denk ik dat je het geheel nog net iets sneller kan maken

spoiler:

door sets als bitmasks te representeren

(voorbeeld code).

Ah, leuke approach inderdaad. Heb een vergelijking gedaan tussen de oplossing met

spoiler:

sets en bitmasks:

test tests::benchmark_bitmask ... bench: 300,159 ns/iter (+/- 17,152)
test tests::benchmark_set ... bench: 3,048,573 ns/iter (+/- 203,680)

[ Voor 3% gewijzigd door MrHaas op 06-12-2020 15:49 ]

[com2,1ghz]

Dag 6 ook weer opgelost: https://github.com/com2gh...lin/nl/orhun/day6/Day6.kt

Had met part 2 wel wat moeite mee

[ Voor 14% gewijzigd door com2,1ghz op 06-12-2020 16:06 ]