Advent of Code 2020

[P_Tingen]

Ligt het nou aan mij of klopt het tweede voorbeeld niet?

In this larger example, in a chain that uses all of the adapters, there are 22 differences of 1 jolt and 10 differences of 3 jolts.

Dus 22 + 10 = 32, maar ik tel er toch echt maar 31:

code:

1 2 3 4 7 8 9 10 11 14 17 18 19 20 23 24 25 28 31 32 33 34 35 38 39 42 45 46 47 48 49 | 31
--------------------------------------------------------------------------------------+----
1 1 1 1   1 1  1  1        1  1  1     1  1        1  1  1  1     1        1  1  1  1 | 22
        3            3  3           3        3  3              3     3  3             |  9

Of mis ik nu wat?

[PTBoy]

Vergeet je de adapter in het device zelf niet, die 3 jolts omhoog kan?

[ Voor 3% gewijzigd door PTBoy op 10-12-2020 08:49 ]

[P_Tingen]

Oef, als laatste stap....

[Dricus]

Dag 10 (Kotlin)

Deze vond ik lastig. Deel 1 maakte ik veel moeilijker dan nodig, en bij deel 2 duurde het even voor ik überhaupt een efficiënte manier van oplossen vond en tot ik die helemaal goed werkend had. De code zou een stuk mooier kunnen, maar ik vind het wel even goed zo .

Edit: Toch nog maar een beetje cleanup gedaan. Het is toch nog verrassend compact geworden!

[ Voor 10% gewijzigd door Dricus op 10-12-2020 10:19 ]

[veldsla]

Leuke probleempjes, van mij mag het zo blijven tot dag 25.

Een kleine 14µs kan ook prima bij het totaal (code).

[jelknab]

Best lang over deel 2 gedaan vandaag, toen ik uiteindelijk de oplossing had, duurde het te lang voor mijn arme laptopje (die klonk als een stoommachine). Dus ook maar memorization gaan gebruiken.

Dit is wel de eerste dag waar ik echt even flink heb moeten nadenken over de oplossing en echt gigantisch veel dingen heb geprobeerd. Vind het wel tof .

Mijn C# oplossing: https://github.com/jelkna...ode%202020/Day10/Day10.cs

[Moofnor]

Deel 1 was een makkelijke (afhankelijk van wanneer het kwartje valt), paar regels met Streams en dat kan vast nog korter.

Deel 2 was lastiger, blijk uiteindelijk voor 1 sequence teveel de mogelijkheden te hebben uitgerekend. Wel door een eigen fout al van te voren de overflow verholpen

Java:
https://github.com/Moofnor/AoC2020/tree/main/day10

[Dricus]

Grappic, de moeilijkheidsgraad van part 2 is aan de stats ook wel af te lezen: https://adventofcode.com/2020/stats. Ongeveer 11.000 hebben 2 sterren en ongeveer 10.000 hebben 1 ster. Dat heb ik bij de vorige dagen nog niet gezien gebeuren.

[Dido]

Ik heb het gevoel dat deel twee van vandaag door veel programmeurs enorm technisch wordt ingestoken, terwijl het eigenlijk uiteindelijk niets anders hoeft te zijn dan de getallen 2, 4 en 7 te verheffen tot drie machten in de orde van 2, 3 en 12 (afhankelijk van je input-data), en de drie uitkomsten met elkaar te vermenigvuldigen.

De tweede set voorbeelddata kan op een papiertje worden uitgewerkt, en levert een heel simpel algoritme op dat razendsnel draait. (ik ga twee keer door een lijst heen, dus dat is dan O(2n) of zo?)

[MrHaas]

Dido schreef op donderdag 10 december 2020 @ 11:58:
Ik heb het gevoel dat deel twee van vandaag door veel programmeurs enorm technisch wordt ingestoken, terwijl het eigenlijk uiteindelijk niets anders hoeft te zijn dan de getallen 2, 4 en 7 te verheffen tot drie machten in de orde van 2, 3 en 12 (afhankelijk van je input-data), en de drie uitkomsten met elkaar te vermenigvuldigen.

De tweede set voorbeelddata kan op een papiertje worden uitgewerkt, en levert een heel simpel algoritme op dat razendsnel draait. (ik ga twee keer door een lijst heen, dus dat is dan O(2n) of zo?)

Interessant, kan je dit iets uitgebreider toelichten?

O(2n) = O(n) btw

[evanraalte]

Vandaag vond ik erg leuk! Vooral omdat je even moet nadenken over een efficiente mogelijkheid bij part 2

Hier mijn code in python: https://github.com/evanraalte/aoc2020/tree/master/day10

spoiler:

Mijn methode, op basis van voorbeeld 1:

[ Voor 53% gewijzigd door evanraalte op 10-12-2020 12:15 ]

[Luqq]

day10 in python, beide in 0.07ms. https://gitlab.luqq.nl/ao...aster/day10/test_day10.py

[ Voor 9% gewijzigd door Luqq op 10-12-2020 13:19 ]

[DataGhost]

Dido schreef op donderdag 10 december 2020 @ 11:58:
Ik heb het gevoel dat deel twee van vandaag door veel programmeurs enorm technisch wordt ingestoken, terwijl het eigenlijk uiteindelijk niets anders hoeft te zijn dan de getallen 2, 4 en 7 te verheffen tot drie machten in de orde van 2, 3 en 12 (afhankelijk van je input-data), en de drie uitkomsten met elkaar te vermenigvuldigen.

De tweede set voorbeelddata kan op een papiertje worden uitgewerkt, en levert een heel simpel algoritme op dat razendsnel draait. (ik ga twee keer door een lijst heen, dus dat is dan O(2n) of zo?)

spoiler:

Ik heb er een graaf van gemaakt om daarna gewoon alle opties van achter naar voren op te tellen. Dat is ook O(n).

[dcm360]

Het hangt er maar net van af of je Dynamic Programming ingewikkeld vind of niet. Een slimme implementatie die daar gebruik van maakt is ook O(n) (al vereist het bij mij wel weer een gesorteerde lijst, en daarmee is het sorteren complexer dan het verdere algoritme, met O(n log(n))), een minder optimale O(n log(n)). De oplossingen die ik tot zover heb nagelopen zijn allemaal O(n log(n)), inclusief die van @Dido (vanwege de lijst die gesorteerd moet worden).

[Dido]

dcm360 schreef op donderdag 10 december 2020 @ 12:12:
inclusief die van @Dido (vanwege de lijst die gesorteerd moet worden).

Oh, ja, die vergat ik voor het gemak even. Dat was immers al gebeurd voor stap 1, dus die doe ik voor stap 2 niet nog eens

MrHaas schreef op donderdag 10 december 2020 @ 12:02:
Interessant, kan je dit iets uitgebreider toelichten?

spoiler:

Stel dat je adapters (inclusief outlet en jouw device) de volgende waardes hebben:
0, 3, 4, 7, 8, 9, 12, 13, 14, 15, 18, 19, 20, 21, 22, 25

Dan zijn de jumps dus 3, 1, 3, 1, 1, 3, 1, 1, 1, 3, 1, 1, 1, 1, 3.
Tot en met adapter met waarde 7 is er maar 1 pad (ik kan niets overslaan).
Van 7 naar 12 heb ik 2 mogelijkeden: ik gan 8 overslaan, of niet.
Van 12 naar 18 heb ik vier mogelijkheden: niets overslaan, alles overslaan, 13 overslaan of 14 overslaan.
Van 18 naar 25 heb ik 7 mogelijkheden.

Ik ga dus tellen hoeveel groepjes van 2, 3 en 4 enen ik heb (5 of meer kwam niet voor). Elke groep kan elk van n paden hebben, dus in het totaal moet ik al die mogelijkheden met elkaar vermeningvuldigen.
Hence, 2^(aantal groepjes van 2) * 4^(aantal groepjes van 3) * 7^(aantal groepjes van 4)

Het is vast niet optimaal, maar ik had in ieder geval geen enkel moment dat mijn geheugen vol lipe, mijn pc warm werd of ik zat te wachten op een berekening

[ Voor 0% gewijzigd door RobIII op 10-12-2020 13:20 ]

[ThoNohT]

Dag 10 in F#

Deel 2 draait in ~50µs, deel 1 in 5. Heb ik dan zo'n kleine input misschien?

[MueR]

Soms.. is PHP echt een drama.. bij deel 2:
PHP Fatal error: Uncaught Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '256' frames

Gelukkig kunnen we dat overrulen. Dag 10 in PHP

[diabolofan]

Heb het ook met grafen opgelost. Eerst duurde de uitvoer te lang (niet op gewacht zelfs) omdat voor elk path alles opnieuw werd uitgerekend. Toen dus gezorgd dat bij elk pathdeel onthouden wordt of daarvoor het aantal mogelijkheden tot het eind al berekend is (en dan dus de al berekende waarde gebruiken van dat pathdeel). Is dit bij iedereen nodig of ligt dit aan mijn node child-process die niet zo rap is...?

[ Voor 5% gewijzigd door diabolofan op 10-12-2020 13:14 ]

[dcm360]

@diabolofan Dat 'probleem' heeft iedereen. Het antwoord is het aantal paden dat je zou moeten aflopen als je tussenwaarden niet onthoudt, dus als jouw antwoord bijvoorbeeld 1 biljoen is, en je rekent een miljoen paden per seconde door, duurt het uitvoeren een miljoen seconden.

[coop]

De lange manier van deel 2 berekenen had ik snel bedacht, mijn laptop had er alleen heel lang voor nodig om het te berekenen (uiteraard).

Deel 1 draait in 12.5 µs per loop, deel 2 in 438 µs per loop.

[ Voor 38% gewijzigd door coop op 06-12-2021 13:48 ]

[Gimmeabrake]

Done (#1, #2). Zit nu de thread door te lezen, en ik was veel te moeilijk bezig bij deel 2 Zal later vandaag eens kijken of ik 'm even ombouw naar een simpele oplossing.

[ydderf]

Deel 2 hier met beide test inputs gelukt, maar met de echte input werd het aantal mogelijkheden ff iets te groot
Daarna de oplossing van @Dido geïmplementeerd en kom tot de juiste antwoorden. Ofja, ik moet nog wel zelf de laatste berekening met de hand uitvoeren want dat ging nog niet helemaal goed qua dataformat.... (todo puntje voor van het weekend)
Dag 10

[ Voor 3% gewijzigd door ydderf op 10-12-2020 15:02 ]

[Down]

Deze heb ik weer gedaan in JS (deel 1 en deel 2).

Lekker stukje dynamic programming. Net als veel anderen hier de input ingestoken als (gerichte) graaf en recursief doorgelopen i.c.m.memoization.

evanraalte schreef op donderdag 10 december 2020 @ 12:06:
Vandaag vond ik erg leuk! Vooral omdat je even moet nadenken over een efficiente mogelijkheid bij part 2

Hier mijn code in python: https://github.com/evanraalte/aoc2020/tree/master/day10

spoiler:

Mijn methode, op basis van voorbeeld 1:

[Afbeelding]

spoiler:

Ik had ook zoiets op papier staan. Ik kan voor geen meter grafen tekenen.

--

Dido schreef op donderdag 10 december 2020 @ 12:36:
[...]

Oh, ja, die vergat ik voor het gemak even. Dat was immers al gebeurd voor stap 1, dus die doe ik voor stap 2 niet nog eens

[...]

spoiler:

Stel dat je adapters (inclusief outlet en jouw device) de volgende waardes hebben:
0, 3, 4, 7, 8, 9, 12, 13, 14, 15, 18, 19, 20, 21, 22, 25

Dan zijn de jumps dus 3, 1, 3, 1, 1, 3, 1, 1, 1, 3, 1, 1, 1, 1, 3.
Tot en met adapter met waarde 7 is er maar 1 pad (ik kan niets overslaan).
Van 7 naar 12 heb ik 2 mogelijkeden: ik gan 8 overslaan, of niet.
Van 12 naar 18 heb ik vier mogelijkheden: niets overslaan, alles overslaan, 13 overslaan of 14 overslaan.
Van 18 naar 25 heb ik 7 mogelijkheden.

Ik ga dus tellen hoeveel groepjes van 2, 3 en 4 enen ik heb (5 of meer kwam niet voor). Elke groep kan elk van n paden hebben, dus in het totaal moet ik al die mogelijkheden met elkaar vermeningvuldigen.
Hence, 2^(aantal groepjes van 2) * 4^(aantal groepjes van 3) * 7^(aantal groepjes van 4)

Het is vast niet optimaal, maar ik had in ieder geval geen enkel moment dat mijn geheugen vol lipe, mijn pc warm werd of ik zat te wachten op een berekening

Mijn discrete wiskunde is een beetje weggezakt .

[ Voor 30% gewijzigd door Down op 10-12-2020 15:43 ]

[indexample]

P_Tingen schreef op woensdag 9 december 2020 @ 21:52:
[...]


Nu deel 2 ( red: dag9 ) in 2ms (in mijn eerste aanpak 662ms)

met het Woy-algoritme toegepast naar python, in 0.5ms ( 514µs )

[jelknab]

Ik vind het wel grappig dat iedereen hier echt bizar lage executietijden probeerd te halen. In zo'n opdracht als vandaag vind ik een optimizatie van bijv memoization echt volledig nodig en goed, maar ik vind wel dat sommige mensen een beetje te ver gaan met performance Optimalisatie.

Evt een interessante google zoekopdrach is: micro optimizations

[Creepy]

Dag 10 deel 1 was een eitje, daar was ik zo mee klaar. Ik heb aleen nog niks kunnen bedenken voor deel 2 tussen het werken door

[Down]

jelknab schreef op donderdag 10 december 2020 @ 15:55:
Ik vind het wel grappig dat iedereen hier echt bizar lage executietijden probeerd te halen. In zo'n opdracht als vandaag vind ik een optimizatie van bijv memoization echt volledig nodig en goed, maar ik vind wel dat sommige mensen een beetje te ver gaan met performance Optimalisatie.

Evt een interessante google zoekopdrach is: micro optimizations

Ik spreek niet voor anderen, maar het leuke aan AoC vind ik altijd dat ik mezelf (rand)voorwaarden kan opleggen om het leuker en/of interessanter te maken. Dat zijn vaak ook dingen die ik in m'n professionele werk niet altijd wil of kan doen, zoals de keuze voor een bepaalde taal of benadering (zoals lekker mierenneuken over microseconden).

Niks mis mee toch?

[Swedish Clown]

Man ik ben gisteren uren zoet geweest om te proberen om mijn executie tijd naar beneden te brengen Helemaal mee eens dat dit af en toe het leuke is aan AoC.

Hoewel ik alles in Erlang doe elk jaar, probeer ik wel zaken te gebruiken die ik normaliter zelden/weinig gebruik

[P_Tingen]

jelknab schreef op donderdag 10 december 2020 @ 15:55:
Ik vind het wel grappig dat iedereen hier echt bizar lage executietijden probeerd te halen. In zo'n opdracht als vandaag vind ik een optimizatie van bijv memoization echt volledig nodig en goed, maar ik vind wel dat sommige mensen een beetje te ver gaan met performance Optimalisatie.

Evt een interessante google zoekopdrach is: micro optimizations

Een van de aspecten die voor mij AoC leuk maken is de vele manieren waarop iets opgelost kan worden. Vaak los ik het eerst zelf op en als dat gelukt is, kijk ik hoe anderen het opgelost hebben. Daar krijg ik soms weer inspiratie door om mijn programma aan te passen zodat het eleganter / mooier / sneller is.

Ik programmeer in een 4GL ik kan daar weer andere dingen in dan mensen in bv Python of C# kunnen. Ik lees dan ook juist oplossingen in andere talen omdat daar de problemen vaak fundamenteel anders aangepakt worden. Ik leer heel wat bij in zo'n AoC periode.

[CTVirus]

Ik loop nog steeds wat achter maar weer anderhalve dag in gehaald:

spoiler: dag 6.1 (81 chars)

p$<.read.split(/\n\n/).map{|l|l.split(/\n/).map(&:chars).flatten.uniq.length}.sum

spoiler: dag 6.2 (79 chars)

p$<.read.split(/\n\n/).map{|l|l.split(/\n/).map(&:chars).inject(:&).length}.sum

spoiler: dag 7.1 (117 chars)

l=[];i=$<.read;g=->(s){l<<s;(i.scan(/^(.*)s contain.*#{s}/)-l).map{|c|g[c[0]]}};g['shiny gold bag'];p l.uniq.length-1

[_Mithrandir]

Ik heb me hoofd wel gebroken over deel 2 van dag 10 maar ben volgens mij toch wel met een mooie oplossing gekomen vind ik

Ik bereken voor elke blok waar de stap grootte tussen adapters 1 is het aantal mogelijke paden, en daarna vermenigvuldig ik alle blokken met elkaar op het eind.

https://github.com/Gerben...2020/tree/master/Day%2010

[Sharkware]

evanraalte schreef op donderdag 10 december 2020 @ 12:06:
Vandaag vond ik erg leuk! Vooral omdat je even moet nadenken over een efficiente mogelijkheid bij part 2

Hier mijn code in python: https://github.com/evanraalte/aoc2020/tree/master/day10

spoiler:

Mijn methode, op basis van voorbeeld 1:

[Afbeelding]

Bedankt voor de hulp!

spoiler:

Ik had de Graph ook al zelf aangemaakt en getekend. Had al een recursieve functie gemaakt en ging er vanuit dat ik memoization moest gaan toepassen ivm. de grootte van de Graph. Maar ik kon me niet goed genoeg concentreren om te bedenken welke waardes de recursieve functie nou eigenlijk terug moest geven en wat ik daar dan vervolgens weer mee moest doen.

Een blik op jouw foto en het was meteen duidelijk. Jammer alleen dat ik vergat dat de eerste stap ook variabel kon zijn (om van 0 jolts naar de eerste adapter te gaan, en 0 niet in je input zit). Hierdoor maar met de hand het tweede voorbeeld uitgerekend om erachter te komen dat ik met de hand hetzelfde getal kreeg als via mijn algo. Toen viel het kwartje meteen.

[DRaakje]

Nog net even gedaan, ik lees nu een hoop mensen met performance problemen. Daar had ik gelukkig geen last van. Allebei onder de 1 ms

https://pastebin.com/7fVv46eK

[dcm360]

Ik kon het ook maar even niet laten om een poging te doen nog wat efficiënters in elkaar te zetten. Deel 1 ging origineel in O(n²) vanwege een wel erg onhandige aanpak (wel een set hebben, maar die wel n maal compleet doorlopen). Dat was zo verbeterd, maar deel 2 vereiste iets meer denkwerk om er voor te zorgen dat ik de invoer niet meer hoefde te sorteren en op O(n) uit te komen. Daar heb ik uiteindelijk twee varianten van gemaakt, waarvan 1 geheel functioneel. Performance van alles 1 keer uitvoeren is ruim niet zo vlot als wat anderen hier halen, maar dat is ook niet echt het ding van de JVM.

[Swedish Clown]

Kon het niet laten om even wat te code-golfen en in een enkele iteratie _{(afgezien van de lists:sort/1)} door de input, zowel part1 en part2 op te lossen. Geheel draait in 55 us als gemiddelde over 100.000 iteraties Misschien dit weekend eens kijken of er nog meer vanaf valt te snoepen maar leesbaarder zal het niet worden...

Erlang:

-module(day10).

-export([ run/1 ]).

run(File) ->
  {ok, Bin} = file:read_file(File),
  Input = lists:sort([ binary_to_integer(S) || S <- binary:split(Bin, <<"\n">>, [trim, global]) ]),
  FindF = fun(_F, [], _AccF, Acc) -> Acc;
             (F, [A|T], AccF, Acc) ->
              F(F, T, AccF, AccF(A, T, Acc))
          end,
  MapF = fun(Acc, I) ->
             case Acc of
               #{I := V} -> Acc#{I := V + 1};
               #{} -> Acc#{I => 1}
             end
         end,
  AccF1 = fun(A, B, {{X, Y}, {I, Acc}}) when hd(B) - A =:= 1 ->
              {{X + 1, Y}, {I + 1, Acc}};
             (A, B, {{X, Y}, {I, Acc}}) when hd(B) - A =:= 3 ->
              {{X, Y + 1}, {0, MapF(Acc, I)}};
             (_, _, {{X, Y}, {I, Acc}}) ->
              {{X, Y}, {0, MapF(Acc, I)}}
          end,
  {{X, Y}, {_, #{2 := Twos, 3 := Threes, 4:= Fours}}} = FindF(FindF, Input, AccF1, {{1, 1}, {1, #{}}}),
  A = X * Y,
  B = round(math:pow(2, Twos) * math:pow(4, Threes) * math:pow(7, Fours)),
  {A, B}.

[Dido]

Hij was weer leuk vandaag
Als ik vanmiddag tijd heb kan er wel het eens en ander geoptimaliseerd en opgeruimd worden, maar voorlopig doet een naive approach het binnen een zeer acceptabele tijd.

[Varienaja]

Leuk inderdaad. Ik heb nu 225 regels code. Daar valt vast en zeker nog een heleboel aan op te ruimen! Vanavond kijk ik er weer naar.

[Dricus]

Dag 11 (Kotlin)

Hele leuke opdracht weer! Deze keer had ik wat meer code nodig, maar ik ben blij met het resultaat met minder dan 100 regels code.

spoiler:

Is het al iemand opgevallen dat dit gewoon een variatie op Wikipedia: Conway's Game of Life is?

En om de checks op neighbors een beetje simpel te houden zonder al teveel "if"jes, is het handig om dummy floor tiles rondom de originele map toe te voegen.

[Mschamp]

Vandaag ook terug gelukt
https://github.com/mscham...blob/master/2020/Day11.cs C# op 150 regels.

[Reynouts]

spoiler:

Eigenlijk hoef je de puntjes niet op te slaan en kun je af met een sparse matrix of datastructuur waar je alleen de positie waar je "#" of "L" bij bewaard (in python is een dictionary perfect hiervoor). Kan het wellicht sneller maken.

[Dricus]

Reynouts schreef op vrijdag 11 december 2020 @ 08:52:

spoiler:

Eigenlijk hoef je de puntjes niet op te slaan en kun je af met een sparse matrix of datastructuur waar je alleen de positie waar je "#" of "L" bij bewaard (in python is een dictionary perfect hiervoor). Kan het wellicht sneller maken.

spoiler:

Dat kan nog wel eens tegenvallen. Indexed toegang tot een array (1- of 2-dimensionaal) is echt heel erg snel.

[Emiel L]

Ik heb 'm gewoon op de naïeve manier opgelost. Toegang tot 2D arrays is snel genoeg en het compleet vergelijken hiervan met '==' blijkt ook nog wel performant genoeg te zijn. Mijn oplossing is 110 regels Swift code.

https://github.com/emiela...playground/Contents.swift

Veel gebruik gemaakt van value types, want dat ontzorgt me een beetje, ten koste van performance. Runtime van deze oplossing: 3.6 seconden op 2.6Ghz i7 MacBook Pro, 1.6 seconden op m'n M1 MacBook Air.

Edit: Een release build, ipv 'm in de debugger te draaien scheelt wel:
Time elapsed for Iterations: 0.10782194137573242 s (M1, de tijd op intel is weer 2.5 keer dat).

[ Voor 14% gewijzigd door Emiel L op 11-12-2020 10:16 ]

[evanraalte]

Python: https://github.com/evanra...lob/master/day11/day11.py

92 regels inclusief helper function voor het printen van de grid.

[Hydra]

Pff. 2e dag ziek. Wil graag verder maar m'n hersenen zijn pap. Daar gaat m'n ranking

[GladstoneW]

dcm360 schreef op donderdag 10 december 2020 @ 23:46:
Ik kon het ook maar even niet laten om een poging te doen nog wat efficiënters in elkaar te zetten. Deel 1 ging origineel in O(n²) vanwege een wel erg onhandige aanpak (wel een set hebben, maar die wel n maal compleet doorlopen). Dat was zo verbeterd, maar deel 2 vereiste iets meer denkwerk om er voor te zorgen dat ik de invoer niet meer hoefde te sorteren en op O(n) uit te komen. Daar heb ik uiteindelijk twee varianten van gemaakt, waarvan 1 geheel functioneel. Performance van alles 1 keer uitvoeren is ruim niet zo vlot als wat anderen hier halen, maar dat is ook niet echt het ding van de JVM.

Ik heb geen verstand van Scala, maar ik zie een set.max voorbij komen in je code. Dat gebeurt toch (intern) door de set alsnog te sorten om het maximum te bepalen? Dus dan is je oplossing helaas toch niet O(N).

[eamelink]

Leuk puzzeltje. Ik heb de hele fysieke structuur meteen overboord gegooid. Voor deel twee alleen m'n 'neighbors' functie aanpassen (en de 4 naar 5 )

[ThoNohT]

GladstoneW schreef op vrijdag 11 december 2020 @ 10:09:
[...]


Ik heb geen verstand van Scala, maar ik zie een set.max voorbij komen in je code. Dat gebeurt toch (intern) door de set alsnog te sorten om het maximum te bepalen? Dus dan is je oplossing helaas toch niet O(N).

Om het maximum te bepalen hoef je toch niet te sorteren? Gewoon erdoorheen lopen en het maximum bijhouden, dat kan gewoon in O(n)

[GladstoneW]

ThoNohT schreef op vrijdag 11 december 2020 @ 10:48:
[...]

Om het maximum te bepalen hoef je toch niet te sorteren? Gewoon erdoorheen lopen en het maximum bijhouden, dat kan gewoon in O(n)

Je hebt natuurlijk gelijk, ik zit te slapen. Te veel met stoelen bezig geweest vanochtend .

[Reynouts]

Dricus schreef op vrijdag 11 december 2020 @ 08:55:
[...]

spoiler:

Dat kan nog wel eens tegenvallen. Indexed toegang tot een array (1- of 2-dimensionaal) is echt heel erg snel.

Heb het even getest en je hebt gelijk dat het tegenvalt, levert maar marginaal wat winst op qua uitvoertijd. Dan is het enige voordeel wat overblijft wat minder memorygebruik denk ik.

[dcm360]

GladstoneW schreef op vrijdag 11 december 2020 @ 10:09:
[...]


Ik heb geen verstand van Scala, maar ik zie een set.max voorbij komen in je code. Dat gebeurt toch (intern) door de set alsnog te sorten om het maximum te bepalen? Dus dan is je oplossing helaas toch niet O(N).

Sorteren kost meer tijd dan eenmaal door alle elementen lopen om het maximum te bepalen, dus dat lijkt onwaarschijnlijk. Bij de performance characteristics wordt max helaas niet genoemd, maar min is in principe dezelfde operatie en staat vermeld als lineaire operatie.

edit: Maar daar was je ook al achter terwijl ik dit aan het typen was

---

Met de oplossing voor vandaag vooral een tijdje beziggeweest met deel 2, ondanks dat het 2e deel al het nadenkwerk van deel 1 wel aardig kon hergebruiken. Het duurde alleen even voordat ik zag dat ik vanwege een typfoutje alleen naar 'beneden' zocht (de range voor dY was per ongeluk 1 to 1 in plaats van -1 to 1).

[ Voor 3% gewijzigd door dcm360 op 11-12-2020 11:23 ]

[coop]

Lekker lopen kloten vandaag, de regels en het selecteren van de juiste velden duurde even bij deel 1. De logica die ik bedacht heb voor deel 2 was uiteindelijk veel beter en werkt ook bij deel 1.
Het script draait wel eventjes (3,77s voor deel 1, 3,97s voor deel 2), maar nu even geen tijd om dit te verbeteren.

[ Voor 19% gewijzigd door coop op 06-12-2021 13:48 ]

[Woy]

Vandaag was ook goed te doen, over deel 1 heb ik iets te lang gedaan, want had in mijn hoofd dat ik het iteratie nummer moest invullen, in plaats van het aantal stoelen dat bezet was aan het einde

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

Verderr niet al te veel op optimalisatie gelet, buiten het feit dat ik het grid in-place aanpas in plaats van telkens een nieuwe te genereren, maar vooral een beetje leesbare code proberen te fabriceren, best redelijk gelukt IMHO.

[Woy]

Dricus schreef op vrijdag 11 december 2020 @ 08:34:
Dag 11 (Kotlin)

Hele leuke opdracht weer! Deze keer had ik wat meer code nodig, maar ik ben blij met het resultaat met minder dan 100 regels code.

spoiler:

Is het al iemand opgevallen dat dit gewoon een variatie op Wikipedia: Conway's Game of Life is?

En om de checks op neighbors een beetje simpel te houden zonder al teveel "if"jes, is het handig om dummy floor tiles rondom de originele map toe te voegen.

spoiler:

Ja Conway's Game of Life was inderdaad ook het eerste waar ik aan moest denken.

Ik had eerst ook in mijn hoofd om een dummy rand toe te voegen, maar dan moet je zeker voor part 2 ook weer een special character toevoegen om tijdig af te breken, ik heb dus maar gewoon een wat langer check statement geschreven.

[coop]

Woy schreef op vrijdag 11 december 2020 @ 11:52:
Vandaag was ook goed te doen, over deel 1 heb ik iets te lang gedaan, want had in mijn hoofd dat ik het iteratie nummer moest invullen, in plaats van het aantal stoelen dat bezet was aan het einde

https://github.com/rverst...de2020/blob/main/Day11.cs

Verderr niet al te veel op optimalisatie gelet, buiten het feit dat ik het grid in-place aanpas in plaats van telkens een nieuwe te genereren, maar vooral een beetje leesbare code proberen te fabriceren, best redelijk gelukt IMHO.

Haha, ik zat eerst L te tellen en in te vullen als antwoord ipv #. Kan je lang blijven zoeken naar de fout.

[armageddon_2k1]

Deze kostte me wat meer moeite en vooral meer tijd. Ik weet niet helemaal waarom, want echt moeilijk was het niet. Vooral veel hulpmethodes gemaakt om het probleem wat op te splitsen.

Een helper class gemaakt Seating waarin 'domein'-specifieke shit gedaan wordt en op basis daarvan lazy-sequence met updates.

Wel beperkt aantal regels gehouden.
https://github.com/rj-cod...rjcoding/aoc2020/Day11.kt

EDIT: Heb hem al wat proberen optimizen, maar ik krijg ze niet onder de ~300ms. Nouja.

EDIT2: Wow. Even als test van een CharArray naar een IntArray gegaan. Scheelt bijna 40%. Weer wat geleerd.

EDIT3: Wel interessant, door de vele microtweaks is er toch veel veranderd. Geen orde-grootte verschil, maar wel significant.

Initiele versie, 849ms en 1250ms respectievelijk.

Huidige versie, 216ms en 451ms respectievelijk.

Belangrijkste tweaks is een IntArray gebruiken en voorberekende dingen doorgeven aan de volgende update (seatList en occupied). Daarnaast occupiedSeats berekenen door de setters bij te houden.

[ Voor 52% gewijzigd door armageddon_2k1 op 11-12-2020 14:13 ]

[Moofnor]

Vandaag was weer een dag met het motto: Het werkt maar kijk niet hoe...

Ik mis het gemak van matrix en array operations van Python in Java, dus het is een grote brij van for loops. Mocht iemand hiervoor nog tips hebben, graag!

Code: https://github.com/Moofnor/AoC2020/tree/main/day11

[indexample]

oef dag 10 deel 2 viel wel tegen, kwam maar niet voorbij de testcase, omdat ik niet snapte waarom het niet gewoon met een power berekening kon 2^(aantal split opties). na wat hints viel het kwartje dat een aantal splits achter elkaar voor meerdere combinaties kan zorgen.

uiteindelijk is het lekker snel gebleven: 0.00017 s
https://github.com/indexample/AOC2020/tree/main/day10

snel door met dag 11!

[ Voor 7% gewijzigd door indexample op 11-12-2020 13:56 ]

[Varienaja]

indexample schreef op vrijdag 11 december 2020 @ 13:55:
een aantal splits achter elkaar voor meerdere combinaties

Een aantal splits achter elkaar geeft toch juist minder combinaties?
0,1,2 -> de 2 kan weg of erin -> 2 combinaties
0,1,2,3 -> de 1 kan weg, de 2 kan weg, niks kan weg, beide kunnen weg -> 4 combinaties
0,1,2,3,4 -> In tegenstelling tot je intuitie heb je hier niet 8 mogelijkheden, maar 7. (zowel 1,2 als 3 weglaten kan niet)
Voor langere rijtjes weet ik niet hoe het verder gaat; ik heb Dag 10 anders opgelost.

Vanmorgen had ik het wijzigen van het grid nog 4x dubbel in m'n code staan: 1x onderdeel A, hekjes zetten, 1x onderdeel A L-letjes zetten; en hetzelfde nog eens voor onderdeel B... Nu heb ik The Game of Life (Dag 11) gefatsoeneerd. Het ziet er nog altijd niet elegant uit, maar het moet er maar mee door.

[ Voor 16% gewijzigd door Varienaja op 11-12-2020 17:38 ]

[Woy]

Ik heb dag 11 toch nog een beetje geoptimaliseerd, en nu zijn Part1 & Part2 bijna exact hetzelfde

spoiler: c#

Voor de daadwerkelijke run selecteer ik reeds de posities welke gechecked moeten worden, gebruikt mogelijk iets meer geheugen, maar tijdens de uitvoer een hoop minder checks nodig

https://github.com/rverst...de2020/blob/main/Day11.cs

Van 134ms naar 74ms, maar nog steeds ruim mijn langzaamste oplossing helaas

[ Voor 9% gewijzigd door Woy op 11-12-2020 17:45 ]

[Woy]

En door parallelisatie toe te voegen nog ~2/3 van de tijd eraf, nu is het wel weer leuk geweest voor vandaag.

[veldsla]

Het is een behoorlijke bende geworden. Ook hier ruim de traagste dag met zo'n 8ms per deel. (90% van de tijd van alles zit in dag 11).

[Mawlana]

8ms per deel? Ik zit op ~6s per deel. 😅 Even kijken hoe ik het kan optimaliseren.

[ydderf]

Dag 11 is gelukt, maar qua performance een verkeerde keuze gemaakt. Met behulp van een list en linq, kom ik op 500sec (nee, geen msec) uit. Zo te zien was de array oplossing misschien beter geweest.

[_Mithrandir]

Dag 11 is ook weer in de pocket, vanaf dag 7 zijn ze toch wat lastiger aan het worden vind ik

[KabouterSuper]

Hydra schreef op vrijdag 11 december 2020 @ 10:05:
Pff. 2e dag ziek. Wil graag verder maar m'n hersenen zijn pap. Daar gaat m'n ranking

Dan ben je verder gekomen dan ik. Ik had me voorgenomen dit jaar mee te doen, maar een schouder uit de kom en operatie op 27 november gooiden de plannen in de war. Ach, volgend jaar weer een kans.

[Varienaja]

Ik heb dan ook maar even gepoogd wat te optimaliseren. Door een tweedimensionaal array te gebruiken ipv een Stringlist (en nog wat foefjes) van 800ms naar 120ms gegaan. De buitenste loop parallel uitvoeren helpt mij niks. Waarschijnlijk kost het creëren en starten van de threads zoveel extra tijd dat hun hulp de acherstand niet meer goed maakt.

[P_Tingen]

ydderf schreef op vrijdag 11 december 2020 @ 20:50:
Dag 11 is gelukt, maar qua performance een verkeerde keuze gemaakt. Met behulp van een list en linq, kom ik op 500sec (nee, geen msec) uit. Zo te zien was de array oplossing misschien beter geweest.

Hier idem. Ik wilde het eerst met een array oplossen maar kwam daar niet goed uit, dus uiteindelijk met een temp-table (soort DB tabel in memory) opgelost. Niet de snelste manier met ruim een minuut. Geen zin meer om alsnog om te bouwen naar een array, alhoewel dat waarschijnlijk veel sneller zou zijn

[DRaakje]

Varienaja schreef op vrijdag 11 december 2020 @ 21:23:
De buitenste loop parallel uitvoeren helpt mij niks.

Goed idee, bij maakte het wel uit, van 66ms/93ms naar 30ms/45ms. Nog steeds wel verruit de langzaamste van alle dagen.

[ Voor 52% gewijzigd door DRaakje op 11-12-2020 22:42 ]

[Down]

Dag 11 ook weer opgelost in C# (deel 1 en deel 2).

Niet zo goed gelezen en toch wel een tijdje mee zitten klooien. Code beetje afgeraffeld en geen zin om het nog verder te fixen.

EDIT:

Vooruit, de buitenste loop nog even parallel, scheelt toch een factor 2 zo te zien. Zit waarschijnlijk nog wel wat meer winst in (anders bijhouden van de previous state b.v.), maar het is goed zo.

[ Voor 20% gewijzigd door Down op 12-12-2020 01:01 ]

[Woy]

Dag 12 was weer wat eenvoudiger: https://github.com/rverst.../blob/main/Y2020/Day12.cs

spoiler:

Ik heb wel eerst even de input gechecked of er alleen maar rotaties van 90 graden in de input zaten

Toch ben ik vooral nog niet echt blij met mijn implementatie van dag 11, en heb nog een idee om een flinke verbetering te maken, dus als ik daar vandaag nog zin in heb kijk ik daar nog een keer naar

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

[Varienaja]

Deze was inderdaad eenvoudig: Dag 12. Tijdverlies had ik om me voor te stellen hoe alles verandert bij het draaien. Dat was vroeger toen ik nog dagelijk Wiskunde-B deed wel anders... toen was goniometrie mijn favoriete onderdeel.

[Mschamp]

https://github.com/mscham...blob/master/2020/Day12.cs

Dag 12 valt inderdaad zeer goed mee.

[Dricus]

Dag 12 (Kotlin)

Was inderdaad goed te doen.

spoiler:

En input checken op rotaties van 90*n heb ik ook wel even gedaan, net als @Woy .

Het aardige vind ik dat je deel 1 ook kunt zien als het volgen van een waypoint en daarmee wat regels code kunt uitsparen.

[ZieglerNichols]

Dag 12 (Part 2) in Matlab: https://pastebin.com/QiyzBT5t

Moest wel even op papier wat rotaties tekenen om te kijken hoe de tekens flippen, maar voor de rest was het makkelijk vandaag.

[Varienaja]

Dricus schreef op zaterdag 12 december 2020 @ 08:23:
Dag 12 (Kotlin)

spoiler:

Het aardige vind ik dat je deel 1 ook kunt zien als het volgen van een waypoint en daarmee wat regels code kunt uitsparen.

Toch hé? Dan heb ik vanavond als de kinderen op bed liggen nog mooi iets om naartoe te werken.

[Wesley]

ZieglerNichols schreef op zaterdag 12 december 2020 @ 09:00:
Dag 12 (Part 2) in Matlab: https://pastebin.com/QiyzBT5t

Moest wel even op papier wat rotaties tekenen om te kijken hoe de tekens flippen, maar voor de rest was het makkelijk vandaag.

Hier hetzelfde op papier gedaan inderdaad Redelijk vlot kunnen oplossen terug in een sheet na gisteren toch maar teruggevallen te zijn op code.

[heuveltje]

Ok ik hang nog op dag 11
Eerste sterretje is binnen
Maar ik snap blijkbaar de methode van deel 2 niet
Ik begrijp dat je in elk van de 8 richtingen keek, en aan de hand daarvan een stoel_bezet bepaalde.

Maar als ik naar de uitleg kijk (het standaard inputfile bij de uitleg


ARGH !@#!@# @*()
ruim een uur lopen klooien, omdat ik over it now takes five heb heen gelezen

Zucht,. nou ja. Ook een les die je moet leren blijkbaar.
Toch een beetje trots op mezelf. De eerste keer dat ik zelf een succesvol een recursie heb bedacht en geimplementeerd, en Hoewel ik het nog niet volledig mijn hoofd om heen heb, herkende ik iig mijn [python] list.append voegt variable toe ipv waarde ? prbleem deze keer

[ Voor 24% gewijzigd door heuveltje op 12-12-2020 11:20 ]

[Rips10]

Had een goed idee hoe ik part 1 wilde oplossen, maar vervolgens klopte de uitkomst niet. Kon totaal geen fout vinden en ben vervolgens gaan kijken waar mijn output afwijkt van de oplossing van anderen. Kom ik er vervolgens achter dat de %-operator geen modulo operator is maar een remainder functie.. huh?
https://stackoverflow.com...-my-brain/6400477#6400477
Vervolgens met het toevoegen van mijn eigen modulo functie werkte het wel, daarna enigszins gedemotiveerd part 2 ook nog even gemaakt. C# day 12

[ThoNohT]

In dag 12 had ik eerst per ongeluk de x en y coordinaten omgewisseld bij het bewegen. Dat gaf het juiste resultaat, maar bij dag 2 ineens niet meer, dus toen maar even voor allebei gefixt . Hij was weer goed te doen ja.

[coop]

Vandaag was wat makkelijker dan de vorige 2 dagen. Best tevreden met mijn oplossing. Beide delen in minder dan 3ms.

[ Voor 25% gewijzigd door coop op 06-12-2021 13:48 ]

[DataGhost]

Woy schreef op zaterdag 12 december 2020 @ 07:10:
Dag 12 was weer wat eenvoudiger

Ik vond 'm anders best... complex

[Moofnor]

Dag 12 was niet al te lastig. Maar wel een leuke.

Ben ik nou de enige

spoiler:

Die gewoon de "x = x cos phi + y sin phi" er maar gewoon in heeft gegooid? Beetje laf alleen tekens wisselen
Zorgde wel voor een afrondfout, double naar int dus 0.999 werd fijn 0....

[Reptile209]

Moofnor schreef op zaterdag 12 december 2020 @ 12:18:
Dag 12 was niet al te lastig. Maar wel een leuke.

Ben ik nou de enige

spoiler:

Die gewoon de "x = x cos phi + y sin phi" er maar gewoon in heeft gegooid? Beetje laf alleen tekens wisselen
Zorgde wel voor een afrondfout, double naar int dus 0.999 werd fijn 0....

Ik had zoiets, maar heb onnodig lang zitten schelden op een niet kloppende testcase. Bleek dat ik er even niet aan gedacht had dat als je x aanpast, je die niet meer kan gebruiken in je berekening voor y... temp variabele erbij (kost niks) en klaar . Moest wel weer even wat gonio oprakelen die ik lang niet meer gebruikt had!

[Varienaja]

Moofnor schreef op zaterdag 12 december 2020 @ 12:18:
Ben ik nou de enige

spoiler:

Die gewoon de "x = x cos phi + y sin phi" er maar gewoon in heeft gegooid? Beetje laf alleen tekens wisselen
Zorgde wel voor een afrondfout, double naar int dus 0.999 werd fijn 0....

Ik heb het geprobeerd, maar wist de formule niet meer exact. Dat er afrondingsfouten gingen ontstaan was me duidelijk, daarom ben ik voor de integer-only oplossing gegaan.

[armageddon_2k1]

Ik ben heel erg blij met mijn oplossing in Kotlin:
https://github.com/rj-cod...rjcoding/aoc2020/Day12.kt

Heb de twee parts mooi in 1 oplossing kunnen doen zonder ifjes.

Als je nadenkt over Lineaire Algebra dan wordt het nog gemakkelijker....

spoiler:

Als je beseft dat je de positie en de waypoints als een complex getal kan beschrijven, worden de rotaties heel erg makkelijk omdat je gewoon voor een CCW rotatie met (0, j) moet vermenigvuldigen en voor een CW met (0, -j).

Edit: Nu nog lekker opgeschoond en lekker extension functions gebruikt overal. Kotlin extension functions FTW!

[ Voor 9% gewijzigd door armageddon_2k1 op 12-12-2020 14:44 ]

[Dricus]

armageddon_2k1 schreef op zaterdag 12 december 2020 @ 13:00:
Ik ben heel erg blij met mijn oplossing in Kotlin:
https://github.com/rj-cod...rjcoding/aoc2020/Day12.kt

Nice! Creatieve oplossing met die mode parameter (wel een beetje een cheat ). Enneeh, when is feitelijk gewoon een gestileerd rijtje ifjes hè .

[ Voor 11% gewijzigd door Dricus op 12-12-2020 13:14 ]

[armageddon_2k1]

Dricus schreef op zaterdag 12 december 2020 @ 13:12:
[...]

Nice! Creatieve oplossing met die mode parameter (wel een beetje een cheat ). Enneeh, when is feitelijk gewoon een gestileerd rijtje ifjes hè .

Klopt, maar die gebruik ik niet voor de mode switching

[armageddon_2k1]

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

Ik vond 'm anders best... complex

I see what you did there

[armageddon_2k1]

Dricus schreef op zaterdag 12 december 2020 @ 08:23:
Dag 12 (Kotlin)

Was inderdaad goed te doen.

spoiler:

En input checken op rotaties van 90*n heb ik ook wel even gedaan, net als @Woy .

Het aardige vind ik dat je deel 1 ook kunt zien als het volgen van een waypoint en daarmee wat regels code kunt uitsparen.

Ook weer mooi om te zien. Ik ga mijnes nog even refactoren nu.

[ydderf]

Dag 12 in C# ook gelukt. Deel twee was ff goed lezen wat de bedoeling was, maar daarna vond ik het beter te doen dan de afgelopen paar dagen.

[Swedish Clown]

Man had er rekening mee gehouden dat deel 2 de standaard "wat was je manhattan distance tot de coordinaten die je voor het eerst al eerder hebt bezocht" zou zijn Dus in dag 1 al lekker me coordinaten bijhouden waar ik steeds geweest ben om zodoende in deel 2 snel uit me loop te kunnen knallen

Jammer maar helaas

Moet zeggen dat het voorbeeld wel erg summier is vandaag

[armageddon_2k1]

@Brakkie41 Ik snap hem niet. Je begint toch vanuit 0,0 dan hoef je toch niks bij te houden?

Of bedoel je de afgelegde weg?

[Swedish Clown]

armageddon_2k1 schreef op zaterdag 12 december 2020 @ 15:59:
@Brakkie41 Ik snap hem niet. Je begint toch vanuit 0,0 dan hoef je toch niks bij te houden?

Of bedoel je de afgelegde weg?

In voorgaande jaren bij vergelijkbare puzzels was deel 2 over het algemeen een "Waar ben je eerder al geweest" dus vandaar dat ik in deel 1 steeds me coordinaten bijhield zodat ik deel 2 in principe in 1x klaar zou hebben. Maar deel 2 is dus heel anders dan dat ik verwacht had Jammer maar helaas.

Kortgezegd, ik probeerde deel 2 te voorspellen wat ik dus niet had moeten doen

[ Voor 7% gewijzigd door Swedish Clown op 12-12-2020 16:05 ]

[eamelink]

Ha! Rotaties! Dat kan met matrixvermenigvuldigingen! Gaaf!

Oh, maar eigenlijk kan ik dat helemaal niet meer.

Dus ik heb het maar bij het 90 graden naar rechts roteren gehouden want daar was een voorbeeld van, en alle andere rotaties zijn tenslotte ook gewoon een of meer keren 90 graden naar rechts roteren:

spoiler:

def rotate(direction: String, value: Int): Waypoint = (direction, value) match {
case ("R", 90) => Waypoint(north, -east)
case ("R", x) => rotate("R", 90).rotate("R", x - 90)
case ("L", x) => rotate("R", 360 - x)
}

[ Voor 8% gewijzigd door eamelink op 12-12-2020 16:05 ]

[ydderf]

De oude trage oplossing voor dag 11 vandaag ook maar ff aangepakt. De nieuwe gaat in 180 msec i.p.v. 500000 msec....

spoiler:

2D array ipv List of structs gaat stukje sneller...

[ydderf]

Tevens na wat puzzelen, dag 10 deel twee ook aangepast. Mijn originele oplossing was met een uur nog niet klaar met rekenen. Na hier op het forum wat spoilers te bekijken, zelf een oplossing gemaakt. En deze komt <10 msec, dus voor mij meer als acceptabel genoeg.

spoiler:

De mogelijke routes berekening heb ik in delen opgesplits. Elke keer wanneer de sprong 3 is, begint een nieuw route deel. Immers elke route moet door dit punt gaan. Het totaal aantal routes is de vermenigvuldiging van alle route delen (in het voorbeeld 1*4*2*1*1).

[Verwijderd]

~1 ms dag 10 oplossing:

spoiler: title

data=load('advent_12_2020.txt');
data(end+1)=0;
data(end+1) = max(data)+3;

data=sort(data);
ddata=diff(data);
disp(sum(ddata==1)*sum(ddata==3))

% deel2
disp(sum(ddata==1))
disp(sum(ddata==2))
disp(sum(ddata==3))

% find groups of n 1 delta consequtive adapters
ddata(find(ddata == 3)) =ddata(find(ddata == 3))*0;
totals=zeros(5,1);
idx=1;
% first isfixed
while idx<length(ddata)
loop=1;
while (ddata(idx)~=0) && (idx<length(ddata))
loop=loop+1;
idx=idx+1;
end
totals(loop)=totals(loop)+1;
idx=idx+1;
end
totals(1:end-1) = totals(2:end);
% combinations
% one adapter with 3 steps between: one choice only
mul_tot(1)=1;
% two adapters:
mul_tot(2)=2;
% three adapters:
mul_tot(3)=4;
% four adapters: (1 1 1 1) (0 1 1 1) (1 0 1 1) (0 0 1 1) (1 0 0 1) (1 1 0
% 1) (0 1 0 1)
mul_tot(4)=7;

disp(sprintf('%12d',prod(mul_tot.^(totals(1:4)'))))

[ Voor 1% gewijzigd door Verwijderd op 12-12-2020 21:54 . Reden: spoiler tags toegevoegd ]

[ZieglerNichols]

Dag 13 in Matlab: https://pastebin.com/ZFbZEp9x

Code ziet er niet uit, maar het werkt! Nu eens kijken hoe het netter kan...

[ Voor 17% gewijzigd door ZieglerNichols op 13-12-2020 07:07 ]

[eamelink]

Leuk puzzeltje .

De tweede van de reeks (na die met de joltages) waar je echt even moet nadenken over de oplossing

Mijn antwoord was duizendeenbiljoenvijfhonderdnegenzestigmiljardzeshonderdnegentien miljoendriehonderddertienduizendvierhonderdnegenendertig

[vliegnerd]

Dag 13 deel 2 is voor mij de eerste puzzel waarbij ik denk... Uhh...

Omdat ik eerdere edities heb meegedaan, herken ik het getaltheorie dingetje wel. Maar vervolgens weet ik niet hoe ik het moet oplossen.

spoiler:

Bus ID zijn priemgetallen, dus het zal wel Chinese Remainder Theorem zijn...

Ik ga eerst maar eens met 3 getallen op papier proberen... Er komt de laatste jaren altijd zo'n moment dat de puzzel meer tijd kost dan ik eraan kan besteden... En vandaag is waarschijnlijk die dag ;-)

(Mijn Python oplossingen: https://github.com/tomkooij/adventofcode)

EDIT: Eehmm.. tip: als je vastzit, lees de opdracht in plaats van bovenstaande. Ik had (niet voor het eerst) een heel andere opdracht in gedachten

[ Voor 11% gewijzigd door vliegnerd op 13-12-2020 08:54 ]