Advent of Code 2020

[ThoNohT]

Dag 6 is wel erg kort, gewoon een aantal set operaties na elkaar. De code is wat abstract, maar in mijn ogen wel goed leesbaar als je weet hoe sets werken.

[eamelink]

Ik had bij part 1 al de gedachte; eigenlijk moet ik van elke regel even los een set maken en dan union'en, maar dat werkte niet direct omdat ik nog geen koffie op had, dus heb ik de losse stringetjes aan elkaar geplakt en er daarna een set van gemaakt.

En ja hoor, in part 2 moeten we intersecten . Dus toen toch maar de oorspronkelijke aanpak genomen.

Bij zulke puzzeltjes loont het typisch wel om het 'netjes' te doen, met de juiste tussenstapjes, dan is part 2 vaak een kwestie van één ding anders parametriseren.

[indexample]

ben pas op 4 december begonnen, maar intussen netjes ingelopen en dag 6 afgerond

https://github.com/indexample/AOC2020

ik ben slechts een python amateur die wat MOOCs heeft gedaan, maar daarom voor mij des te uitdagender om met 'een' oplossing te komen, en daarna bij anderen te kijken hoe het beter en sneller had gekund

[veldsla]

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

IO inderdaad veruit het meeste. Door de bitmask kreeg ik deel1 naar 9us. Maar voor part2 heb ik dan de separator weer nodig wat alles weer langzamer maakte.

Jouw c-oplossing loopt hier iets langzamer, maar dat komt waarschijnlijk door het lezen van stdin.

[Down]

Deze was inderdaad wel makkelijker dan verwacht. Dag 6 (één en twee), nu maar weer in C#. Laten we lekker Linq gaan doen.

Woy schreef op zondag 6 december 2020 @ 06:59:
Day 6 was ook weer goed te doen: https://github.com/rverst...de2020/blob/main/Day06.cs

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

Lijkt wel aardig op wat ik heb gedaan. Voor deel 2 had ik beter de lengte van de answer gewoon kunnen checken. En ToLookup is wel handig tijdens debuggen omdat het niet deferred is, maar op de één of andere manier zit GroupBy in m'n mentale muscle memory.

ThoNohT schreef op zondag 6 december 2020 @ 16:15:
Dag 6 is wel erg kort, gewoon een aantal set operaties na elkaar. De code is wat abstract, maar in mijn ogen wel goed leesbaar als je weet hoe sets werken.

Mijn eerste gedachte voor deel 2 was dat ik gewoon een doorsnede wilde van alle antwoorden, zo van "was er maar een IntersectMany". Wat grappig dat F# die gewoon heeft.

[ Voor 21% gewijzigd door Down op 06-12-2020 19:13 ]

[ThoNohT]

Down schreef op zondag 6 december 2020 @ 18:55:
Mijn eerste gedachte voor deel 2 was dat ik gewoon een doorsnede wilde van alle antwoorden, zo van "was er maar een IntersectMany". Wat grappig dat F# die gewoon heeft.

Hehe, ik wist ook niet of hij er zou zijn, maar ik was er wel heel blij mee toen ik hem vond. Jij hebt nog geen dag 5 trouwens?

Ondertussen even wat refactoring gedaan, nu kan ik ook mijn problemen profilen (alhoewel ik mooie code belangrijker vind dan snelle code tot nu toe, maar wie weet kan ik er wat mee gaan spelen), hoef ik geen hele lijst aan problemen in Program.fs te bewaren (beetje reflection kan nooit kwaad), en is de code bij de problemen zelf nog cleaner/compacter ook. Helemaal goed, en klaar voor volgende week

[Down]

ThoNohT schreef op zondag 6 december 2020 @ 19:48:
[...]

Hehe, ik wist ook niet of hij er zou zijn, maar ik was er wel heel blij mee toen ik hem vond. Jij hebt nog geen dag 5 trouwens?

Ondertussen even wat refactoring gedaan, nu kan ik ook mijn problemen profilen (alhoewel ik mooie code belangrijker vind dan snelle code tot nu toe, maar wie weet kan ik er wat mee gaan spelen), hoef ik geen hele lijst aan problemen in Program.fs te bewaren (beetje reflection kan nooit kwaad), en is de code bij de problemen zelf nog cleaner/compacter ook. Helemaal goed, en klaar voor volgende week

Ik wissel een beetje tussen C# en JS (dag 5 in js)

Ik zie overigens dat veel mensen allerlei utils en helpers hebben gemaakt voor terugkerende taken. Ergens snap ik het nut en de noodzaak wel (wie wordt er nou echt blij van dat geparse elke keer), maar ik vind het ook wel fijn dat de oplossing een beetje standalone is ofzo.

Ik zie ook regelmatig Kotlin voorbij komen. Ik ben niet zo bekend met het JVM-landschap, maar is Kotlin een pak moderner qua features dan Java? Of heeft Java geen pattern matching en dergelijke?

Ik gebruik veel C# en ben wel blij met de modernisering die de taal doormaakt (pattern matching, tuples, null coalescing/propagation etc). Voor wat betreft .NET heb ik nooit de noodzaak gevoeld uit te wijken naar een andere taal. Nu is de keuze ook niet reuze, daar niet van.

[ydderf]

Dag 6 is ook gelukt. Ik zie wel dat ik (door gebrek aan kennis) wel een andere oplossing heb gekozen dan de c# oplossingen die hier voorbij komen.

[Mawlana]

MaNDaRK schreef op zondag 6 december 2020 @ 13:14:
Ik doe ook weer mee in Python.

Ik vond day 3 wel leuk, dus ik heb een animatie er van gemaakt:
[Afbeelding]
( voor het eerst dat ik zoiets probeer )

set.intersection()... Ik kende die method niet, dat had m'n code wel kunnen vereenvoudigen.

Ik heb het opgelost met functools.reduce() & operator.and_().

[Varienaja]

Dag 7. Ik wou met regexen beginnen, maar het lukte niet direct. Dan maar String splitten en zelf parsen, nu heb ik m'n beide antwoorden. Code fatsoeneren komt later wel. :-)

Op zich was de opdracht niet moeilijk, maar je moet (zoals altijd) wel secuur te werk gaan.

[Dido]

Varienaja schreef op maandag 7 december 2020 @ 06:47:
je moet (zoals altijd) wel secuur te werk gaan.

spoiler:

Zoals niet je kleuren parsen als "magenta light" of een vermenigvuldiging vergeten

Maar inderdaad maar even code fatsoeneren, want hoewel part2 vrij rap gaat is part 1 veel te traag - die moet te optimaliseren zijn

[heuveltje]

Varienaja schreef op maandag 7 december 2020 @ 06:47:
Dag 7. Ik wou met regexen beginnen, maar het lukte niet direct. Dan maar String splitten en zelf parsen, nu heb ik m'n beide antwoorden. Code fatsoeneren komt later wel. :-)

Op zich was de opdracht niet moeilijk, maar je moet (zoals altijd) wel secuur te werk gaan.

MMM ik vind hem anders nog vrij lastig. zie de methodiek nog niet
Moet nog even goed denken hoe ik dit ga oplossen

[ZieglerNichols]

Varienaja schreef op maandag 7 december 2020 @ 06:47:
Dag 7. Ik wou met regexen beginnen, maar het lukte niet direct. Dan maar String splitten en zelf parsen, nu heb ik m'n beide antwoorden. Code fatsoeneren komt later wel. :-)

Op zich was de opdracht niet moeilijk, maar je moet (zoals altijd) wel secuur te werk gaan.

Inderdaad, het parsen netjes doen kost vaak teveel tijd, dus dan maar slordig en hopen dat het werkt ;-)
Ik neem bijvoorbeeld aan dat het aantal bags in een bag nooit meer dan 1 cijfer bevat. Dat werkte dit keer goed, maar is niet zo netjes.

Code (Matlab): https://pastebin.com/hXRvAK2q

[ThoNohT]

Als je het een beetje opsplitst, dan zijn de kleine regexes nog best behapbaar. Een van de items in de lijst met bags die hij kan containen kan bijvoorbeeld zo:

spoiler:

\A(\d+) (\w+ \w+) bags?\z

Dit is ook de enige regex die ik heb gebruikt hier overigens, dan hoef je die aanname niet eens te maken.

[Rips10]

Het parsen van dag 7 was voor mij ook het moeilijkste gedeelte, even wat geprobeerd met Regex, zonder resultaat. Ook maar over gegaan op de string.split. Na het parsen ging het vrij gemakkelijk.
Day 07 C#

[heuveltje]

Belindo schreef op zondag 6 december 2020 @ 10:43:
Link: dag 6 in PHP

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)

Blijkbaar zijn er iig in python slimmere manieren waardoor je daar niet eens door heen hoeft te loopen.

Maar die wist ik toen nog niet
Dus wat ik in ieder geval deed was in plaats van heel het alfabet heen te loopen, alleen door de karakters in het laatste antwoord heen te loopen. Als die maar 5 karakters is heb je bv al 21 pogingen bespaard

Ik was nog aan het overwegen bij te houden wat het kortste antwoord per groep was, en dat te checken. Maar te veel werk zolang alles binenn een seconde parst

[Hydra]

Dag 7 in Kotlin

Deze was leuk!

spoiler:

Wel grappig dat je door dit soort dingen vaak te doen er wel echt beter in wordt. Da's meteen zo'n "oh okay, tree traversal" momentje. Vind dit soort opdrachten het leukst eigenlijk; je moet er echt wel even bij nadenken zonder dat je een uur bezig bent requirements over te typen.

[Hydra]

heuveltje schreef op maandag 7 december 2020 @ 07:25:
MMM ik vind hem anders nog vrij lastig. zie de methodiek nog niet
Moet nog even goed denken hoe ik dit ga oplossen

Dit soort opdrachten is echt een kwestie van oefenen. Als je dit vaker gedaan hebt herken je het zo. Zo niet, dan ben je er wel ff mee bezig. Is heel normaal dus

[ThoNohT]

Dag 7 in F#

Eigenlijk moet ik er nog staartrecursie van maken bij part 2. Maar, misschien later. Het is nu nog niet heel belangrijk, want ik krijg het antwoord gewoon snel zonder overflows.

[Dricus]

Dag 7
Deze vond ik heel leuk!

spoiler:

Input een beetje sanitizen voordat je gaat parsen maakt het werken met de input veel makkelijker. Hierdoor heb ik minimaal van regexes gebruik hoeven maken.

[Hydra]

En deel 1 gerefactored!

spoiler:

Ik was voor stack-based gegaan omdat ik dacht dat het nogal een diepe recursie zou zijn, maar dat was helemaal niet nodig. Flink wat regels code bespaard door ook deel 1 recursief te doen.

[ElkeBxl]

Op dag 7 in TS heb ik echt te lang zitten prutsen aan die input... Heel de input parsen in regex wou echt niet lukken, tot ik ook overschakelde op string.split, met beetje regex erbij dan om maar een deel zo te parsen.

[coop]

Dag 7 was inderdaad leuk.

spoiler:

Wel foutje gemaakt bij deel 2. De recursie ging goed, maar als je 4 tassen A hebt, waar ieder 3 tassen B in zitten, dan heb je niet 3 tassen B maar 12 Dus mijn eerste antwoord was een factor X te laag.

[heuveltje]

Hydra schreef op maandag 7 december 2020 @ 08:34:
[...]


Dit soort opdrachten is echt een kwestie van oefenen. Als je dit vaker gedaan hebt herken je het zo. Zo niet, dan ben je er wel ff mee bezig. Is heel normaal dus

thanks voor de bemoedigende woorden !
Zal inderdaad gevalletje ervaring en kennis zijn, waar ik NOG niet ben


Zit nu op het werk, en kan dus niks coden / testenI
Maar ik kan het nog niet helemaal loslaten, dus zit wat op papier te krabbelen.

Ik denk het idee nu door te hebben, Dus voor degene die hem al opgelost hebben :

spoiler:

-Zit ik goed met het idee, dat ik 1 keer die lijst ga inlezen als een array met [moeder kleur,[dochterkleur1,dochterkleur2,etc...] ]
En daar met een soort functie doorheen ga jitteren die bij elke dochter kleur kijkt of het ook een moederkleur is, en zo ja daar de dochterkleuren weer bij uitzoek tot ik bij goud-of niks uitkom ?

-Kom ik dan niet ergens in een eindeloze loop terecht (blauwe zak, bevat, bevat bruine zak, bevat blauwe zak, bevat bruine zak,..........) ?

[ Voor 3% gewijzigd door heuveltje op 07-12-2020 09:45 ]

[ThoNohT]

heuveltje schreef op maandag 7 december 2020 @ 09:44:
[...]

Eindeloze loop zou kunnen ja. Maar dan zouden de zakken ook oneindig groot zijn, dus het lijkt mij dat je er redelijk veilig vanuit kunt gaan dat ze geen cycles in de input hebben gestopt, en dat je dus gewoon rustig door kunt gaan.

[DRaakje]

Mijn code in c#
https://pastebin.com/DE6h6TbB

Regex spoiler:

spoiler:

Voor de regex, gewoon splitsen in 2 aparte.Ik geloof best dat het in 1 regel kan, maar ik vind dit een stuk beter te begrijpen.

[Gimmeabrake]

Dit jaar voor het eerst mee aan het doen met AoC. Twijfelde eerst tussen Kotlin en Python. Uiteindelijk voor PHP gegaan, even kijken water allemaal nieuw is in de net gereleaste versie 8.

De repo staat hier, dit zijn de oplossingen van vandaag: #1 #2. Ben niet heel trots op die van vandaag, maar mijn tijd is op en het werkt.

spoiler:

Pas bij deel 2 moet je de hele zooi parsen, deel 1 kun je ook met simpele stringoperaties oplossen.

[evanraalte]

Vandaag was erg leuk vond ik!

spoiler:

Goed nadenken over het format waar je je input naar parsed helpt een hoop!

. Code: https://github.com/evanra.../blob/master/day7/day7.py

[evanraalte]

DRaakje schreef op maandag 7 december 2020 @ 10:01:
Mijn code in c#
https://pastebin.com/DE6h6TbB

Regex spoiler:

spoiler:

Voor de regex, gewoon splitsen in 2 aparte.Ik geloof best dat het in 1 regel kan, maar ik vind dit een stuk beter te begrijpen.

spoiler:

Ik had dezelfde struggles. Het schijnt dat je een groep wel vaker kan parsen, maar de resulterende data structuur die daaruit kwam vond ik minder fijn dan gewoon 2 regex expressies gebruiken

[Moofnor]

Leuke puzzle inderdaad, even nadenken voor te beginnen met tikken.

spoiler:

Deel twee is wel net fout met de "-1" om de shiny gold bag zelf er weer vanaf te trekken.
Verder is de search vrij goed te doen met recursie

Mijn oplossing in Java: [github]

[evanraalte]

Moofnor schreef op maandag 7 december 2020 @ 10:46:
Leuke puzzle inderdaad, even nadenken voor te beginnen met tikken.

spoiler:

Deel twee is wel net fout met de "-1" om de shiny gold bag zelf er weer vanaf te trekken.
Verder is de search vrij goed te doen met recursie

Mijn oplossing in Java: [github]

spoiler:

How many individual bags are required INSIDE your single shiny gold bag?

Wel correct toch? Het gaat er om hoeveel er in je single shiny gold bag passen, dus je hoeft de bag zelf niet mee te rekenen.

[Woy]

Hier zat het meeste werk in het parsen van de input, verder weer niet super moeilijk.

https://github.com/rverst.../blob/main/Y2020/Day07.cs

Ik heb wel de naive implementatie gedaan zonder optimalisaties en checks voor infinite recursion e.d. Voor productie code had ik het waarschijnlijk wel wat anders aangepakt

[eamelink]

Inmiddels snap ik de progressies van part 1 naar part 2 wel een beetje, dus bij Part 2 had ik alles wat ik nodig had. Dit was het extraatje:

Scala:

lazy val containedBags: Long =
      contains.toList.map { case (count, bag) => count * (1L + bag.containedBags) }.sum

Toch een uur over gedaan , want ik had een lastig bugje: die `contains` value is een set, dus ik deed `map` op de set, waardoor de som niet klopte. Als ik bijvoorbeeld een tas had met 28, 6, 1 en 1 tassen erin, dan was mijn set dus 28, 6, 1 en de som 35 ipv 36... Maar dat probleem zat niet in beide voorbeeld-inputs.

Manmanman wat duurde dat lang om uit te vogelen

[jelknab]

Leuke dag ja!
Het is mij wel gelukt om redelijk overzichtelijk 1 regex te gebruiken.

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

[armageddon_2k1]

Easy peasy in Kotlin.

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

spoiler:

Zal vast met regex kunnen, maar die haat ik. Dus gewoon string parsing.
Daarnaast een lookupTable opbouwen en klaar.

[Hydra]

@armageddon_2k1 waarom 'haat' je regexes? Ik vind ze juist voor het parsen van tekst vaak veel leesbaarder dan stukjes code die splitten. Daarbij heb je ook nog eens parsen en valideren in 1; heb vaak met regexes dat ik zie dat bepaalde regels input net anders zijn, en "hey chef, deze regel matched niet met '[0-9]+' vind ik dan duidelijker dan een IndexOutOfBoundsException.

[armageddon_2k1]

@Hydra Ik 'haat' ze omdat ik ze niet goed ken en dus moet leren
Is gewoon projectie van mijn eigen tekortkomingen.

Maar, uitgelezen kans het eens goed te leren. Dus ik zal spoedig wel refactoren.

[ Voor 52% gewijzigd door armageddon_2k1 op 07-12-2020 15:19 ]

[MueR]

Gimmeabrake schreef op maandag 7 december 2020 @ 10:28:
De repo staat hier, dit zijn de oplossingen van vandaag: #1 #2. Ben niet heel trots op die van vandaag, maar mijn tijd is op en het werkt.

spoiler:

Pas bij deel 2 moet je de hele zooi parsen, deel 1 kun je ook met simpele stringoperaties oplossen.

spoiler:

Ach, je kunt het gros ook al parsen bij input.. mijn versie voor vandaag.

[Hydra]

armageddon_2k1 schreef op maandag 7 december 2020 @ 15:17:
@Hydra Ik 'haat' ze omdat ik ze niet goed ken en dus moet leren
Is gewoon projectie van mijn eigen tekortkomingen.

Maar, uitgelezen kans het eens goed te leren. Dus ik zal spoedig wel refactoren.

Sowieso! En die voor AoC zijn niet zo complex over het algemeen (gelukkig) dus vrij goed leesbaar.

[DataGhost]

armageddon_2k1 schreef op maandag 7 december 2020 @ 15:17:
@Hydra Ik 'haat' ze omdat ik ze niet goed ken en dus moet leren
Is gewoon projectie van mijn eigen tekortkomingen.

Maar, uitgelezen kans het eens goed te leren. Dus ik zal spoedig wel refactoren.

Een belangrijke valkuil is dat niet alles met 1 regex hoeft. Je kan prima regexes combineren met string-operaties. Voor vandaag heb ik toevallig helemaal geen regexes gebruikt, nergens voor nodig.

spoiler:

Het zijn namelijk twee woorden, twee overbodige woorden en daarna een aantal delen gescheiden door een komma met een spatie, bestaande uit een getal, twee woorden en een woord wat je kan negeren, of "no other bags.". Ik vond de oplossingen geinig waarbij gematcht werd op meervoud/enkelvoud, komma's en punten maar nodig was het niet.

Dit kan je trouwens nog steeds prima met een of meerdere regexes doen waardoor je juist weer andere processing-stappen kan skippen.

[dcm360]

Bij mij is de insteek altijd: het parsen gaat op de manier die ik als eerste bedenk. In dit geval is dat eerst een regex die de vorm 'a -> restant' aanpakt, gevolgd door een check op een 'leeg' restant of een stukje dat het restant eerst splitst en vervolgens weer met een regex opbreekt. Beide delen heb ik vervolgens opgelost met een stack (vermomd als recursieve oplossing, waar ik blijkbaar nogal naar neig). Hier mijn oplossing, zeker deel twee is wat rommelig doordat ik die tuple daar in geprutst heb om op het juiste antwoord uit te komen.

[Wraldpyk]

Net deze thread gevonden! Erg leuk, ik heb me ook in de leaderboard aangemeld, al zal ik nooit de eerste zijn (en er ook niet voor gaan). Tot nu toe alle dagen vrij gemakkelijk weten af te ronden.

Mijn code (JavaScript): https://github.com/Topener/adventofcode2020

[Creepy]

Ik heb de boel ook ff op github gezet: https://github.com/CodeEngineerNL/AdventOfCode2020/ . Alles in Java dus voor zover dat nog niet duidelijk was. Dag 7 straks nog even gaan starten, daar heb ik nog geen tijd voor gehad.

[WernerL]

Dag 7 ook weer afgerond. https://github.com/Werner...blob/main/src/07/index.ts
Meeste werk zat hem in het parsen van de input. De functies die de oplossing zoeken voor part 1 en 2 zijn relatief eenvoudige recursieve functies geworden.

[Down]

Dag 7 (deel 1 en deel 2). Toch maar waar in JS, omdat ik alleen een laptop bij me had met VS code .

Ik was te lui om het fatsoenlijk te parsen (en geen objectstructuur opgebouwd), dus dan maar string.startsWith. .

Verder wel meteen herkenbaar als zijn op te lossen met:

spoiler:

Recursie. Bij deel 1 ook nog een cache toegevoegd om van een bag bij te houden of deze de te vinden bag ergens in de objectstructuur heeft, zodat hij deze bij volgende aanroepen meteen kan resolven. Of hebben jullie de luxe van ingebouwde memoization?

[indexample]

dag 7 oef, dat was wel even een tandje ingewikkelder dan voorgaande week.
in eerste instantie ging ik in deel 2 de parents tellen ipv de childs, dus eigenlijk de verkeerde kant op. Goed lezen is een vak

spoiler:

uiteindelijk wel gelukt, maar wel met 100 regels code
ach ja, het werkt. niet recursive maar met een todo list en een while loop.

https://github.com/indexample/AOC2020/tree/main/day07

[ Voor 10% gewijzigd door indexample op 08-12-2020 09:05 ]

[Wesley]

Vandaag pas wat later tijd, net deel 1 op kunnen lossen in niet al te lang, maar begin spijt te krijgen van m'n ambitie om dit in Excel te doen eens zien hoe ver ik kom met deel 2.

[Varienaja]

Code gefatsoeneerd. Jammer dat de Matcher geen streaming methode heeft voor find.

Bij het fatsoeneren nog gepoogd met mooie regexen te werken, waarbij ik tot mijn grote verontrusting heb moeten vaststellen dat

code:

\s*(\d+)\s+(.*?)\s+(bag)

keurig "1 posh salmon bag" matched, maar alleen een group teruggeeft voor het tweede haakjespaar (de kleur) als ik ook nog haakjes om (bag) schrijf. Die haakjes rondom "bag" moeten toch niet nodig zijn?? WTF Java. Of ben ik niet compatibel met regexen??

En anno 2020 is het toch werkelijk triest dat Java nog altijd standaard geen Tuple-klasse aan boord heeft. Ik heb nu van ellende de klasse SimpleEntry misbruikt, omdat ik alleen standaard JVM boordmiddellen wou gebruiken. WTF2 Java.

[ Voor 51% gewijzigd door Varienaja op 07-12-2020 21:48 ]

[MaNDaRK]

Ik heb nu een best mooie named dictonary in Python, waarvan de key de kleur is, maar heb nog nooit wat gedaan met recursieve functies.

Ik snap het principe, nu alleen nog het toepassen op de juiste manier
Maar we geven niet op!

[Alain]

Ik heb het gevoel dat het dit jaar wel erg makkelijk is. Maar even een slag om de arm, want soms kan je behoorlijk vast komen te zitten.

[Hydra]

Varienaja schreef op maandag 7 december 2020 @ 21:40:
Jammer dat de WTF2 Java.

*kuch* Kotlin *kuch*

[Hydra]

Varienaja schreef op maandag 7 december 2020 @ 21:40:
Code gefatsoeneerd.

Jezus knip dat eens op in aparte classes man

[Hydra]

Alain schreef op maandag 7 december 2020 @ 22:00:
Ik heb het gevoel dat het dit jaar wel erg makkelijk is.

Famous last words. Eerste week begint vrijwel altijd simpel.

[coop]

[Verwijderd]

[ Voor 174% gewijzigd door coop op 06-12-2021 13:49 ]

[Wesley]

Wesley schreef op maandag 7 december 2020 @ 20:48:
Vandaag pas wat later tijd, net deel 1 op kunnen lossen in niet al te lang, maar begin spijt te krijgen van m'n ambitie om dit in Excel te doen eens zien hoe ver ik kom met deel 2.

Deel 2 niet gelukt in Excel, als iemand dat wel gelukt is ben ik benieuwd! Dan maar opgelost met een relatief simpele recursieve functie in PHP.

[Swedish Clown]

Ik begin spijt te krijgen dat ik naast the usual Erlang, de AoC dit jaar ook in plain SQL wil doen... Zit al de hele avond te worstelen met dag 7 in SQL

_{Lang geleden dat ik weer op Tweakers zat}

[P1nGu1n]

Varienaja schreef op maandag 7 december 2020 @ 21:40:
Jammer dat de Matcher geen streaming methode heeft voor find.

Die zit er sinds Java 9 gewoon in hoor

Matcher.results()

[Reptile209]

Wesley schreef op maandag 7 december 2020 @ 22:29:
[...]


Deel 2 niet gelukt in Excel, als iemand dat wel gelukt is ben ik benieuwd! Dan maar opgelost met een relatief simpele recursieve functie in PHP.

Ja, dat was met een kleine aanpassing op deel 1 prima te doen. Wel Excel met VBA trouwens

[Varienaja]

Dag 8. Erg geinige puzzle. Ik moest wel 3x lezen voor ik onderdeel b snapte. Maar toen ik het eenmaal doorhad was het niet ingewikkeld meer. Enig debugwerk had ik wel nodig om tot de goede resultaten te komen.

[Dido]

Heel geinig. Jammer dat dit zo vroeg is, veel tijd verloren met een hele domme fout

spoiler:

Deel twee gewoon brute-forcen, alle kopieen van het programma proberen met 1 aangepaste regel. En geen oplossing vinden. En er pas na 10 minuten achter komen dat ik steeds het originele programma runde, en niet de kopie

Wel leuk dat we weer aan een compilertje beginnen. Vandaag maar vast wat tijd stoppen in het diepgaand sanatizen van mijn code en implementeren van unit tests op mijn computer. Ervaring leert dat dat handig kan zijn in de nabije toekomst

[Belindo]

Dag 7, ik kom er niet uit 🙁 Heb wat voorbeeldcode in PHP (en wat andere talen) bekeken, maar ook daar wordt het niet veel duidelijker van. Is mijn aanpak verkeerd? Begrijp ik de opdracht verkeerd?

Mijn aanpak:
Split de input naar de 'Outer bag' en de 'Inner Bags'.
Kijk welke Outer Bag een 'shiny gold' bag bevat (dat zijn er 10).
Kijk welke andere Outer Bags een Inner Bag bevatten die eerder als Outer Bag een shiny gold konden bevatten.

Mijn totaal is 56, maar die is niet goed. Andere oplossingen hebben ook veel hogere getallen.

[MerijnB]

Belindo schreef op dinsdag 8 december 2020 @ 07:32:
Dag 7, ik kom er niet uit 🙁 Heb wat voorbeeldcode in PHP (en wat andere talen) bekeken, maar ook daar wordt het niet veel duidelijker van. Is mijn aanpak verkeerd? Begrijp ik de opdracht verkeerd?

Mijn aanpak:
Split de input naar de 'Outer bag' en de 'Inner Bags'.
Kijk welke Outer Bag een 'shiny gold' bag bevat (dat zijn er 10).
Kijk welke andere Outer Bags een Inner Bag bevatten die eerder als Outer Bag een shiny gold konden bevatten.

Mijn totaal is 56, maar die is niet goed. Andere oplossingen hebben ook veel hogere getallen.

Bij het voorbeeld kun je nog zelf uitrekenen wat het antwoord zou moeten zijn. Volg je code en kijk waar het uit de pas loopt. Als dat niet lukt, maar dan zelf een nog eenvoudiger test. Altijd zo klein mogelijk een fout reproduceren.

[Belindo]

Oh, vergeten te vermelden in mijn post. Het voorbeeld komt in mijn code gewoon uit op 4, wat klopt met het voorbeeld. Maar zodra ik mijn input gebruik kom ik uit op 56.

[Hydra]

Day 8 in Kotlin

Heb IntCode flashbacks Niet erg moeilijk alleen zat ik vast op een denkfoutje dat ik gelukkig aan de hand van een inputvoorbeeld kon debuggen. Er zullen wel mensen zijn met veel slimmere oplossingen, maar deze vind ik wel helemaal best verder.

[dcm360]

De opdracht waar ik toch wel op aan het wachten was Met het idee dat er toch nog wel uitbreidingen gaan volgen, is mijn code van vandaag misschien wat overengineered, maar wel een mooie basis voor een vervolg.

[Woy]

https://github.com/rverst.../blob/main/Y2020/Day08.cs

Ik heb het nu nog een beetje snel in elkaar gezet, want kan het wel te veel overengineeren, maar je weet toch niet exact wat er gaat komen.

[MerijnB]

Belindo schreef op dinsdag 8 december 2020 @ 08:00:
Oh, vergeten te vermelden in mijn post. Het voorbeeld komt in mijn code gewoon uit op 4, wat klopt met het voorbeeld. Maar zodra ik mijn input gebruik kom ik uit op 56.

Dan het kleine voorbeeld langzaam complexer maken, totdat het niet meer goed gaat.

[Mschamp]

Vandaag vond ik goed te doen.
Ben ook nog bezig puzzels van vorig jaar op te lossen, waardoor ik gelijkenissen zag.
Later vandaag code nog wat verbeteren.
https://github.com/mscham.../blob/master/2020/Day8.cs

[Dido]

Belindo schreef op dinsdag 8 december 2020 @ 08:00:
Oh, vergeten te vermelden in mijn post. Het voorbeeld komt in mijn code gewoon uit op 4, wat klopt met het voorbeeld. Maar zodra ik mijn input gebruik kom ik uit op 56.

Door eerst je bags op te splitsen mis je de mogelijkheid dat bijvoorbeeld een rode tas een blauwe kan bevatten, terwijl die blauwe een gouden tas kan hebben.Dan moet je rood dus meetellen, ook al staat er niet dat rood goud kan bevatten.

Je gaat niet "diep" genoeg, en het voorbeeld dat ze geven ook niet

[ydderf]

Gisteren liep ik ff vast op dag 7, deel 2. Maar na wat kijken naar de oplossingen van de andere, weer wat inspiratie gekregen (en meteen weer gezien dat C# programmeren ook een vak is ;-)).
Dag 7 zonder opruimen en netter maken.

Deel 2 uiteindelijk recursive kunnen oplossen.

[Dricus]

Dag 8 (Kotlin)

Erg leuke opdracht weer! Tot nu toe zijn de opdrachten erg geschikt om wat mentale ochtengymnastiek mee te doen .

spoiler:

Dit was een hele leuke gelegenheid om de support voor tail recursion in Kotlin eens te gebruiken om zo een functional style oplossing te maken voor een probleem dat lijkt te schreeuwen om een imperatieve oplossing.

[jelknab]

Heel benieuwd of ze hier mee verder gaan in de volgende dagen.
C# dag 8: https://github.com/jelkna...0Code%202020/Day8/Day8.cs

[Hydra]

Dricus schreef op dinsdag 8 december 2020 @ 08:53:

spoiler:

Dit was een hele leuke gelegenheid om de support voor tail recursion in Kotlin eens te gebruiken om zo een functional style oplossing te maken voor een probleem dat lijkt te schreeuwen om een imperatieve oplossing.

Cool. By the way:

code:

    private fun parseProgram(code: List<String>) = code.map {
        val tokens = it.split(" ")
        tokens[0] to tokens[1].toInt()
    }

Kan je ook zo doen:

code:

    private fun parseProgram(code: List<String>) = code
        .map { it.split(" ").let { (a,b) -> a to b.toInt() }

[Dricus]

Hydra schreef op dinsdag 8 december 2020 @ 09:06:
Kan je ook zo doen:

code:

    private fun parseProgram(code: List<String>) = code
        .map { it.split(" ").let { (a,b) -> a to b.toInt() }

Ah, nice! Die let in Kotlin zit nog niet in mijn systeem. Waar ik in dit specifieke geval wel een beetje aan twijfel is of het extra niveau van nesting dat je hierdoor krijgt de moeite waard is.

Op deze manier destructuren vind ik persoonlijk toch net iets duidelijker denk ik:

code:

    private fun parseProgram(code: List<String>) = code.map {
        val (instruction, argument) = it.split(" ")
        instruction to argument.toInt()
    }

[Hydra]

Dricus schreef op dinsdag 8 december 2020 @ 09:13:
Ah, nice! Die let in Kotlin zit nog niet in mijn systeem. Waar ik in dit specifieke geval wel een beetje aan twijfel is of het extra niveau van nesting dat je hierdoor krijgt de moeite waard is.

Zie hier. Dat is hoe ik de instructies inlees en in 1 go meteen map naar pairs. M.i. prima leesbaar Ik heb dus niet een aparte functie hiervoor.

.let is ideaal voor 'destructuring' van kleine lists of pairs. Als je al weet dat je sowieso een lijst van drie elementen terugkrijgt en een pair wil maken van de 2e en 3e kun je gewoon ".let {(_,a,b) -> a to b }" doen en je list is nu een pair. Dan kun je ook .toMap() op de collection of sequence aanroepen.

Kotlin is vet

[DRaakje]

https://pastebin.com/z8fY8uSQ

Mijn oplossing voor vandaag in C#, hopelijk voorbereid op de toekomst >_<

[Belindo]

MerijnB schreef op dinsdag 8 december 2020 @ 07:52:
[...]


Bij het voorbeeld kun je nog zelf uitrekenen wat het antwoord zou moeten zijn. Volg je code en kijk waar het uit de pas loopt. Als dat niet lukt, maar dan zelf een nog eenvoudiger test. Altijd zo klein mogelijk een fout reproduceren.

MerijnB schreef op dinsdag 8 december 2020 @ 08:24:
[...]


Dan het kleine voorbeeld langzaam complexer maken, totdat het niet meer goed gaat.

Dido schreef op dinsdag 8 december 2020 @ 08:29:
[...]

Door eerst je bags op te splitsen mis je de mogelijkheid dat bijvoorbeeld een rode tas een blauwe kan bevatten, terwijl die blauwe een gouden tas kan hebben.Dan moet je rood dus meetellen, ook al staat er niet dat rood goud kan bevatten.

Je gaat niet "diep" genoeg, en het voorbeeld dat ze geven ook niet

Bedankt voor de tips. Ik heb er nog eens naar gekeken, en ik heb een vermoeden dat ik per 'inner bag' moet tellen. Dus als een outer bag 5 inner bags bevat, moet ik 5 keer m'n loop doen.

Ik heb dit nu in de code verwerkt door het aantal komma's te tellen en daar één twee bij op te tellen (één voor de outer bag, en één voor de laatste inner bag).

Nu geeft mijn code bij zowel het voorbeeld als mijn eigen input de goede code.

Flow:
- Split de Bag Rule in een Outer en Inner bag.
- Loop door de Inner Bag om te kijken of deze 'shiny gold' bevat, indien ja; zet de Outer Bag in een array.
-- Tevens, kijk hoeveel komma's er voorkomen in het Inner Bag deel, doe daar één bij om het aantal inner bags te vinden
- Loop opnieuw door de regels, dit keer om te kijken of de Inner Bag de kleur van de eerder vastgestelde Outer Bag bevat
-- Doe deze loop maal het aantal keer dat er een Inner Bag is, om élke inner bag te checken

Code loopt snel, na F5 staat het antwoord direct in beeld (op localhost)

Vraag:
- Klopt mijn aanname dat ik de 2e loop zo vaak moet doen als er inner bags zijn
- Kan dit ook in één keer, door bijvoorbeeld niet per Outer Bag kleur te kijken, maar direct te kijken of één van de Outer Bag kleuren voorkomt in de (meerdere) inner bags
- Zou iemand zijn/haar input via PM willen delen, dit omdat ik graag mijn code nog eens wil valideren zonder dat ik naar het voorbeeld antwoord of naar mijn antwoord probeer toe te werken?

Tevens op advies van @DataGhost ook even de PHP errors/notices aangezet om een code te schrijven die géén errors/notices heeft. En dat is bij dag 7 part 1 dus gelukt 😀

[Dricus]

Hydra schreef op dinsdag 8 december 2020 @ 09:24:
Zie hier. Dat is hoe ik de instructies inlees en in 1 go meteen map naar pairs. M.i. prima leesbaar Ik heb dus niet een aparte functie hiervoor.

Ja inderdaad, mee eens, zo is het prima leesbaar.

.let is ideaal voor 'destructuring' van kleine lists of pairs. Als je al weet dat je sowieso een lijst van drie elementen terugkrijgt en een pair wil maken van de 2e en 3e kun je gewoon ".let {(_,a,b) -> a to b }" doen en je list is nu een pair. Dan kun je ook .toMap() op de collection of sequence aanroepen.

Kotlin is vet

Inderdaad, echt een genot om mee te werken!

[Dricus]

Nog een klein beetje cleanup gedaan, naar aanleiding van de tip van @Hydra: https://github.com/Dricus...tofcode/year2020/Day08.kt

[armageddon_2k1]

Voor het werk part 1 gedaan en nu eventjes part 2.
Ik vind m'n oplossing niet echt klein, maarja.....

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

Heb wel 2x zoveel code als @Hydra....

[ Voor 9% gewijzigd door armageddon_2k1 op 08-12-2020 10:20 ]

[Hydra]

armageddon_2k1 schreef op dinsdag 8 december 2020 @ 10:17:
Heb wel 2x zoveel code als @Hydra....

2.5x

Ik heb wel geleerd in de afgelopen jaren geen aannames te doen wat betreft hoe ik de code opzet. Ik zorg gewoon dat ik op de meest simpele manier part 1 doe, en dan wel zie wat part 2 inhoudt. Als ik beide antwoorden heb, refactor ik de code nog om het niet meer te laten doen dan nodig is. Ik maak bijv. alleen een data class voor input regels als een Pair niet voldoet.

[P_Tingen]

Hydra schreef op dinsdag 8 december 2020 @ 10:31:
[...]
Ik heb wel geleerd in de afgelopen jaren geen aannames te doen wat betreft hoe ik de code opzet. Ik zorg gewoon dat ik op de meest simpele manier part 1 doe, en dan wel zie wat part 2 inhoudt. Als ik beide antwoorden heb, refactor ik de code nog om het niet meer te laten doen dan nodig is. Ik maak bijv. alleen een data class voor input regels als een Pair niet voldoet.

Hier net zo. Vaak is deel 2 toch nét weer anders zodat je niks aan je "optimalisaties" hebt, dus programmeer voor wat op dat moment nodig is. In deel 2 zie je wel weer wat er verbouwd moet worden.

Wat ik nog wel eens doe is deel 1 nog een keer oplossen, maar dan met de geoptimaliseerde code van deel 2. Dit is wel handig als een soort extra testcase; als hetzelfde antwoord eruit komt, ben je op de goede weg.

[Mawlana]

Dag 8 was goed te doen. Bij deel 2 ging het heel even mis bij het kopiëren van de list (.copy() vergeten).

[MrHaas]

Iemand deel 2 al opgelost zonder te bruteforcen?

[evanraalte]

MrHaas schreef op dinsdag 8 december 2020 @ 11:51:
Iemand deel 2 al opgelost zonder te bruteforcen?

spoiler:

Nee, vind het wel een interessant probleem. Je zou correcte positities kunnen aangeven door van achter (programma klaar, is correcte positie) naar voren te lezen. Wanneer je dan op een correcte positie komt, weet je dat je het programma uit zal schrijven. Het probleem is echter dat je een instructie veranderd tijdens itereren. Dus je zal vanaf daar opnieuw je correcte posities moeten definieren.

[Wesley]

Reptile209 schreef op dinsdag 8 december 2020 @ 00:07:
[...]

Ja, dat was met een kleine aanpassing op deel 1 prima te doen. Wel Excel met VBA trouwens

Ah, ik was zonder VBA (Google Apps script) bezig, puur met formules, toch maar opgegeven. Straks eens zien of dat voor dag 8 wel weer gaat lukken.

[MrHaas]

evanraalte schreef op dinsdag 8 december 2020 @ 12:02:
[...]

spoiler:

Nee, vind het wel een interessant probleem. Je zou correcte positities kunnen aangeven door van achter (programma klaar, is correcte positie) naar voren te lezen. Wanneer je dan op een correcte positie komt, weet je dat je het programma uit zal schrijven. Het probleem is echter dat je een instructie veranderd tijdens itereren. Dus je zal vanaf daar opnieuw je correcte posities moeten definieren.

spoiler:

Volgens mij kan het programma gewoon representeren als een directed graph en kan je er daarna doorheen lopen om te kijken of een swap een path geeft naar de end node. Uiteindelijk komt het er op neer dat je de graph acyclisch moet maken.

Zo eens kijken of dat makkelijk gaat.

[Reptile209]

evanraalte schreef op dinsdag 8 december 2020 @ 12:02:
[...]

spoiler:

Nee, vind het wel een interessant probleem. Je zou correcte positities kunnen aangeven door van achter (programma klaar, is correcte positie) naar voren te lezen. Wanneer je dan op een correcte positie komt, weet je dat je het programma uit zal schrijven. Het probleem is echter dat je een instructie veranderd tijdens itereren. Dus je zal vanaf daar opnieuw je correcte posities moeten definieren.

Volgens mij zit je dan wel met het probleem dat je niet weet op welke positie na het einde je uitkomt (op +1 of +500 na het laatste commando). Dus moet je toch alle jmp's en nop's nalopen of ze een argument hebben dat groter is dan de positie van het commando t.o.v. het eind van de lijst. Maar dat zal allicht sneller gaan dan brute-force (7 seconden in Excel VBA ).

[DataGhost]

MrHaas schreef op dinsdag 8 december 2020 @ 12:13:
[...]

spoiler:

Volgens mij kan het programma gewoon representeren als een directed graph en kan je er daarna doorheen lopen om te kijken of een swap een path geeft naar de end node. Uiteindelijk komt het er op neer dat je de graph acyclisch moet maken.

Zo eens kijken of dat makkelijk gaat.

Dat lijkt me nog steeds dezelfde bruteforce die iedereen doet, je kijkt er alleen op een andere manier naar.

[dcm360]

MrHaas schreef op dinsdag 8 december 2020 @ 11:51:
Iemand deel 2 al opgelost zonder te bruteforcen?

De vraag is dan wel of een dergelijke optie daadwerkelijk winst oplevert ten opzichte van brute force. De complexiteit van brute force is slechts n², want in het slechtste geval wissel je n keer een instructie en duurt het uitvoeren telkens n instructies. Waarmee deze opdracht (bij mij) minder complexiteit had dan deel 2 van dag 1, die kwam uit op n³, en dat is te merken in de tijd die het uitvoeren kost (de oplossing van vandaag is significant sneller dan die van dag 1).

[MrHaas]

DataGhost schreef op dinsdag 8 december 2020 @ 12:27:
[...]

Dat lijkt me nog steeds dezelfde bruteforce die iedereen doet, je kijkt er alleen op een andere manier naar.

spoiler:

Je hebt gelijk . Ik moet er achteruit door heen lopen.

[ydderf]

Vandaag vond ik makkelijker te doen dan dag 7.
Dag 8 in C#

En als niet programmeur ben ik wel blij met mijn oplossing. Alleen ik ben aan het stoeien geweest om de input in te lezen en deze als struct array te returnen, maar daar was de compiler het niet mee eens... Dus nu dit maar in mijn hoofdaanroep uitgeprogrammeerd.

[bakkerjangert]

Kleine optimalisatie die ik zie om de brute force iets in te korten is om de enkel de instructies mee te nemen die in de intiele run worden aangesproken; ik had de brute force over de vlledige instructie set gedaan.

[diabolofan]

Dag 8 was weer goed te doen! Zou wel eens de intcode van vorig jaar kunnen worden, zoals hierboven al aangegeven..

bakkerjangert schreef op dinsdag 8 december 2020 @ 12:31:
Kleine optimalisatie die ik zie om de brute force iets in te korten is om de enkel de instructies mee te nemen die in de intiele run worden aangesproken; ik had de brute force over de vlledige instructie set gedaan.

Wat bedoel je met 'initiele run'? De set aan instructies die in de eerste run wordt uitgevoerd? Wanneer je dat bedoelt: Dat kan volgens mij niet, want bij elke iteratie (waar dus op een andere positie je een nop naar jmp verandert, of andersom) worden andere instructies aangeroepen dan in de initiele/eerste run/path.

Mijn 'grootste' optimalisaties was om de state van de operaties te resetten ipv de array met operatiestates te deepclonen (wat In JavaScript het makkelijkst kan met JSON.stringify(JSON.parse()), maar dit performed nogal slecht).

[ Voor 20% gewijzigd door diabolofan op 08-12-2020 12:58 ]

[dcm360]

diabolofan schreef op dinsdag 8 december 2020 @ 12:56:
[...]


Wat bedoel je met 'initiele run'? De set aan instructies die in de eerste run wordt uitgevoerd? Wanneer je dat bedoelt: Dat kan volgens mij niet, want bij elke iteratie (waar dus op een andere positie je een nop naar jmp verandert, of andersom) worden andere instructies aangeroepen dan in de initiele/eerste run/path.

Dat dacht ik eerst ook, maar het werkt wel. Je moet namelijk ontsnappen uit de loop van de initiële run, en dat kan enkel door een instructie te veranderen die je in de initiële run tegenkomt. Worst case kom je in de initiële run overigens nog steeds alle instructies tegen, dus het hoeft niet per se winst op te leveren.

[diabolofan]

dcm360 schreef op dinsdag 8 december 2020 @ 12:58:
[...]

Dat dacht ik eerst ook, maar het werkt wel. Je moet namelijk ontsnappen uit de loop van de initiële run, en dat kan enkel door een instructie te veranderen die je in de initiële run tegenkomt. Worst case kom je in de initiële run overigens nog steeds alle instructies tegen, dus het hoeft niet per se winst op te leveren.

Ja precies, maar dat gebeurd toch automatisch? Je probeert op positie X een jmp naar nop te veranderen of visa versa. Wanneer dat geen resultaat oplevert (dus een operatie komt voor tweede keer tegen), ga je naar positie X + 1 (tot je de volgende nop of jmp tegenkomt) en dus loop je dus een stukje verder op het 'initiele pad'.

[ Voor 5% gewijzigd door diabolofan op 08-12-2020 13:02 ]

[dcm360]

diabolofan schreef op dinsdag 8 december 2020 @ 13:01:
[...]


Ja precies, maar dat gebeurd toch automatisch? Je probeert op positie X een jmp naar nop te veranderen of visa versa. Wanneer dat geen resultaat oplevert (dus iemand kom je twee keer tegen), ga je naar positie X + 1 (dus loop je een stukje verder op het 'initiele pad') enz.

Ja, maar je kan op deze manier dus de instructies overslaan die niet op het initiële pad zaten. Als je namelijk een instructie buiten het initiële pad aanpast, verandert het pad niet en zit je weer in dezelfde loop.

[CTVirus]

I probeer ze op te lossen met ruby in zo min mogelijk code (zonder compressie), input via de stdin, output moet exact het antwoord zijn.

I heb de eerste drie de afgelopen dagen gedaan:

spoiler: dag 1.1 (58 chars)

i=$<.map &:to_i;i.map{|j|c=2020-j;i.any?(c)&&p(j*c)&&exit}

spoiler: dag 1.2 (69 chars)

$<.map(&:to_i).permutation(3).map{|j|j.sum==2020&&p(eval j*?*)&&exit}

spoiler: dag 2.1 (80 chars)

p$<.count{|l|a,b,c=l.split;e=b[0];c=~/^[^#{e}]*(#{e}[^#{e}]*){#{a.tr'-',','}}$/}

spoiler: dag 2.2 (121 chars)

p$<.count{|l|f,g,e,_,c=l.split /\W/;t=f.to_i-1;x=".{#{t}}%s.{#{g.to_i-t-2}}%s";y="[^#{e}]";c=~/^(#{x%[y,e]}|#{x%[e,y]})/}

spoiler: dag 3.1 (46 chars)

i=0;p$<.count{|l|t=(l.strip*99)[i]==?#;i+=3;t}

spoiler: dag 3.2 (120 chars)

m=$<.map &:strip;f=->(x,y){i=0;m.count{|l|t=(l*99)[i*x.to_f/y]==?#&&i%y==0;i+=1;t}};p f[1,1]*f[3,1]*f[5,1]*f[7,1]*f[1,2]

[bakkerjangert]

In de opdracht staat duidelijk aangegeven dat je uit de loop moet ontsnappen door een enkel instructie te wijzigen. Als je een instructie wijzigt buiten je originele loop zal dat geen effect hebben (want die roep je nooit aan) en kun je dus direct overslaan. Wel mee eens dat de optimalisatie niet groot en zelfs 0 zou kunnen zijn.

[Wesley]

Dag 8 snel tussen de middag kunnen doen, deel 1 in de sheet, deel 2 toch maar gebruteforced met PHP