Advent of Code 2017

[Bolukan]

Ok, die uitdaging ga ik aan: met kleine aanpassing is Excel (2 sec) sneller dan Python (9 sec).

spoiler:

[code=vba]
Public Sub FindMaze()
Dim row, myValue, teller As Long
Dim inputarray(1 To 1097) As Long
For row = 1 To 1097
inputarray(row) = ThisWorkbook.Worksheets(1).Cells(row, 1).Value
Next row
Debug.Print Time
row = 1
While row < 1098
myValue = inputarray(row)
If myValue >= 3 Then inputarray(row) = myValue - 1 Else inputarray(row) = myValue + 1
row = row + myValue: teller = teller + 1
Wend
Debug.Print "Escaped. Count=" & teller
Debug.Print Time
End Sub
[/code]

[Anoniem: 420461]

Anoniem: 159174 schreef op dinsdag 5 december 2017 @ 12:18:Looptijd is nu nog 2 seconden.

Hier ook - met bijna 14K iteraties per milliseconde is daar niet veel aan te doen...

[Marcj]

Ik heb zojuist met Haskell een oplossing gemaakt met een STUArray, omdat met immutables dit volgens mij niet efficient te doen is. Toch doet de implementatie er nog 9 seconden over, wat dan toch lang lijkt.

https://github.com/marcde...7/blob/master/src/Day5.hs

Iemand een idee of dit sneller te krijgen is in Haskell?

[Edwin88]

Kraay89 schreef op dinsdag 5 december 2017 @ 11:46:
[...]

spoiler:

Ik loop gewoon door de array heen aan de hand van de instructies, d.m.v. een while True loop. Ik vang de onvermijdelijke (en gewenste) IndexError af en breek dan de loop.

spoiler:

Je kan natuurlijk ook een do-while loop gebruiken en hiermee voorkomen dat je een index error maakt.
DoWhile was overigens ook handig bij dag 3-2, je moet eigenlijk 1 stap er overheen voordat je stopt.

[Edwin88]

Kraay89 schreef op dinsdag 5 december 2017 @ 11:26:
Deel 2 gaat ook een bruteforce worden lijkt me, maar ik ben er nog niet over uit hoe.

Hint:

spoiler:

Hier heb ik ook lang over gedaan, tot ik door had dat je simpelweg kan kijken of je al 'de bocht om kan' bij de volgende stap.

Update: volgende keer zal ik mijn post editen

[ Voor 6% gewijzigd door Edwin88 op 05-12-2017 13:09 ]

[Brandts]

Bolukan schreef op dinsdag 5 december 2017 @ 12:28:
Ok, die uitdaging ga ik aan: met kleine aanpassing is Excel (2 sec) sneller dan Python (9 sec).

spoiler:

[code=vba]
Public Sub FindMaze()
Dim row, myValue, teller As Long
Dim inputarray(1 To 1097) As Long
For row = 1 To 1097
inputarray(row) = ThisWorkbook.Worksheets(1).Cells(row, 1).Value
Next row
Debug.Print Time
row = 1
While row < 1098
myValue = inputarray(row)
If myValue >= 3 Then inputarray(row) = myValue - 1 Else inputarray(row) = myValue + 1
row = row + myValue: teller = teller + 1
Wend
Debug.Print "Escaped. Count=" & teller
Debug.Print Time
End Sub
[/code]

Ondanks dat dit meestal (en waarschijnlijk ook in jouw geval) tot het goede antwoord leidt, zit er toch een klein foutje in je code:

spoiler:

Je bent vergeten dat hij in theorie ook links de array kan verlaten, dus bij row<0

[Hydra]

M'n Kotlin implementatie doet er 187ms over (Dag 5). Je kunt ze helaas niet direct vergelijken; andere input zal ook een andere runtime betekenen.

[kruimel0]

Ik wist niet dat dit bestond! Leuk idee! Heb zojuist een paar uur gespendeerd om alles werkend te krijgen in MATLAB (de enige taal die ik voor m'n werk gebruik).

[Lye]

Hydra schreef op dinsdag 5 december 2017 @ 14:48:
M'n Kotlin implementatie doet er 187ms over (Dag 5). Je kunt ze helaas niet direct vergelijken; andere input zal ook een andere runtime betekenen.

Klopt, echter zorgt Eric Wastl (de bedenker van AoC) er wel voor dat alle inputs een vergelijkbare output hebben. Het zou heel vervelend zijn als jij je leaderboard plaats kwijt raakt omdat jouw input een executietijd van 10 seconden veroorzaakt tov 83ms van een andere input.

[Hydra]

Lye schreef op dinsdag 5 december 2017 @ 15:03:
Klopt, echter zorgt Eric Wastl (de bedenker van AoC) er wel voor dat alle inputs een vergelijkbare output hebben. Het zou heel vervelend zijn als jij je leaderboard plaats kwijt raakt omdat jouw input een executietijd van 10 seconden veroorzaakt tov 83ms van een andere input.

Ja, ongeveer wel. Maar aangezien in deze oplossing het aantal stappen letterlijk de oplossing was zal er vast wel een bepaalde marge (zegmaar 10-25% ofzo) inzitten.

[vliegnerd]

Edwin88 schreef op dinsdag 5 december 2017 @ 09:30:
[...]

Een typescript/node omgeving doet er net niet 1 second over... Hoe kan Python zo langzaam zijn? Gebruik je een raar algoritme?

Ik gebruik precies dat algoritme, maar wel met een lijst van getallen (objecten) in plaats van een array. Dat kan wel in python met numpy, maar eigenlijk niet in standaard python...

Maar vergeet niet dat node een zeer goede optimising compiler heeft (V8) t.o.v. python. Python heeft dan weer veel beter leesbare code, hoewel dat typescript er best leesbaar uitziet.

[Daedalus]

vliegnerd schreef op dinsdag 5 december 2017 @ 16:05:
[...]


Ik gebruik precies dat algoritme, maar wel met een lijst van getallen (objecten) in plaats van een array. Dat kan wel in python met numpy, maar eigenlijk niet in standaard python...

Maar vergeet niet dat node een zeer goede optimising compiler heeft (V8) t.o.v. python. Python heeft dan weer veel beter leesbare code, hoewel dat typescript er best leesbaar uitziet.

Dag 5 deel 2 met python duurt hier ook ongeveer 7 seconden. Vervangen van de list met een array of een NumPy array maakt het alleen maar trager. Als ik daarentegen PyPy gebruikt (met exact hetzelfde script), dan is het binnen 0.2 seconden klaar

[Ryada]

Ik begrijp dat jullie met dag 5 aan het kijken zijn hoe snel dat kan? Weet niet of het alleen binnen python is of dat andere talen ook mee mogen doen. Mijn eigen solution in C# voor dag 5 deel 1 en 2 samen heeft de volgende execution time:

Time taken: 00:00:00.1054301

real 0m0.153s
user 0m0.000s
sys 0m0.000s

Had voor de grap ook Deel 1 compleet parallel gemaakt, maar dat is even snel als dat ik een gewone for loop gebruik. Soms zit het niet mee als je probeerd om iets op de leuke manier te doen.

[P.O. Box]

Kraay89 schreef op dinsdag 5 december 2017 @ 11:46:
[...]


Dat ben ik zeker met je eens, maar ik zou zo 1-2-3 even niet weten waar ik kan schaven. (Ik ben maar hobbyist)

spoiler:

Ik loop gewoon door de array heen aan de hand van de instructies, d.m.v. een while True loop. Ik vang de onvermijdelijke (en gewenste) IndexError af en breek dan de loop.

spoiler:

waarom dan while true, waarom niet "gewoon" while index niet te groot?

[Camulos]

Dag 5 was zeer goed te doen, had geen last van de executie tijden.
Binnen C# (.net core) blijft hij binnen de 250ms, door gewoon gebruik te maken van een normale array (nooit list).

Wel beetje lelijk om een if-statement te moeten gebruiken in part 2

spoiler: part2

if (instructions[lastPosition] >= 3) { instructions[lastPosition]--; }
else { instructions[lastPosition]++; }

complete oplossing
C# oplossing dag 5

[Ryada]

Camulos schreef op dinsdag 5 december 2017 @ 20:24:
Dag 5 was zeer goed te doen, had geen last van de executie tijden.
Binnen C# (.net core) blijft hij binnen de 250ms, door gewoon gebruik te maken van een normale array (nooit list).

Wel beetje lelijk om een if-statement te moeten gebruiken in part 2

spoiler: part2

if (instructions[lastPosition] >= 3) { instructions[lastPosition]--; }
else { instructions[lastPosition]++; }

complete oplossing
C# oplossing dag 5

Haha, ik heb zo'n beetje precies dezelfde if statement gebruikt op de benaming na

[Daedalus]

Kraay89 schreef op dinsdag 5 december 2017 @ 11:46:
[...]


Dat ben ik zeker met je eens, maar ik zou zo 1-2-3 even niet weten waar ik kan schaven. (Ik ben maar hobbyist)

spoiler:

Ik loop gewoon door de array heen aan de hand van de instructies, d.m.v. een while True loop. Ik vang de onvermijdelijke (en gewenste) IndexError af en breek dan de loop.

spoiler:

Waarschijnlijk kwam je er mee weg, maar je kunt ook op een negatieve index uitkomen. Zolang die kleiner is dan de lengte van de list, krijg je geen IndexError.

Camulos schreef op dinsdag 5 december 2017 @ 20:24:
Wel beetje lelijk om een if-statement te moeten gebruiken in part 2

spoiler: part2

if (instructions[lastPosition] >= 3) { instructions[lastPosition]--; }
else { instructions[lastPosition]++; }

spoiler:

M'n C# is niet zo scherp, maar how about:
instructions[lastPosition] += instructions[lastPosition] < 3 ? 1 : -1;

[ Voor 27% gewijzigd door Daedalus op 05-12-2017 20:38 ]

[Ryada]

ook maar een beetje plezier gaan beleven met dag 1 vandaag, was van mening dat ik hem toch wat sneller kon maken dan hij was maar helaas niet gelukt. Span<T> was zelfs langzamer dan T[] met index based lookups.

Dag 1 Parallel oplossing

Helaas is hij ongeveer even snel dus het heeft niet mogen baten, beetje jammer van de Parallel.For overhead.

[Camulos]

Ryada schreef op dinsdag 5 december 2017 @ 20:34:
...Helaas is hij ongeveer even snel dus het heeft niet mogen baten, beetje jammer van de Parallel.For overhead.

Dag 1 is niet zo handig voor Parallel.. maar Dag4 (passphrases) dan juist wel!
Helaas zijn er maar ~500 regels om te processen.. als het er nu 50K ofzo waren, dan had je de ware power van Parallel.For gezien

PS: Moest ook ff wennen dat je beide solutions in 1 main stopt

[Ryada]

Camulos schreef op dinsdag 5 december 2017 @ 20:38:
[...]


Dag 1 is niet zo handig voor Parallel.. maar Dag4 (passphrases) dan juist wel!
Helaas zijn er maar ~500 regels om te processen.. als het er nu 50K ofzo waren, dan had je de ware power van Parallel.For gezien

PS: Moest ook ff wennen dat je beide solutions in 1 main stopt

Haha ja heb je gelijk in, had alleen de gedachte dat ik dag 1 nog ff iets sneller kon maken om een vriend zijn C++ versie te verslaan, scheelt echt 0,001 seconde. Maar helaas was dat niet gelukt.

Ik probeer zoveel mogelijk in 1 loop te doen als ik een loop nodig heb. (is me aardig gelukt met elke optie vind ik toch) Ik had het waarschijnlijk heel simpel in 2 verschillende methods kunnen doen nu ik erover nadenk, maakt het misschien iets leesbaarder denk ik zo.

[Camulos]

@Daedalus: Worked like a charm thnx!

@Ryada Heb net voor dag4 parallel gebruikt.. en pas als ik de input tot 14K vergrootte kwam parallel sneller uit de bus. De input/work is te klein bij deze opdrachten om de overhead van parallel.for te overbruggen.

[Raynman]

Marcj schreef op dinsdag 5 december 2017 @ 12:59:
Ik heb zojuist met Haskell een oplossing gemaakt met een STUArray, omdat met immutables dit volgens mij niet efficient te doen is. Toch doet de implementatie er nog 9 seconden over, wat dan toch lang lijkt.

https://github.com/marcde...7/blob/master/src/Day5.hs

Iemand een idee of dit sneller te krijgen is in Haskell?

Hoe compile je dat? Ik heb even een paar varianten geprobeerd. Daarvoor heb ik wel eerst 'run' veranderd in 'main' (met print i.p.v. return) en 'splitOn "\n"' vervangen door de standaard 'lines' om geen extra packages te hoeven installeren.

Zonder optimalisatie zit ik op 31s met mijn input. Met -O1 wordt dat zo'n 4s en met -O2 0,35s (vergelijkbaar met mijn C++ oplossing). Bij de tragere versies zie ik ook het geheugengebruik toenemen. Met de volgende aanpassing om hem strict te maken in de accumulator (wat GHC waarschijnlijk ook doet met -O2) worden de tijden resp. 27s en 0,44s met constant geheugengebruik.

Haskell:

                     step update (ix + curr) array length $! accum + 1

[kenneth]

Wat ontzettend vaag dat overal (ook op reddit) de python-oplossing van vandaag zoveel trager dan alle andere talen. Iemand had hem op reddit nog wel naar ~5s gekregen maar dat is natuurlijk nog steeds absurd traag.

[Hydra]

Dag 6 in Kotlin

Zit nog te broeden op een mooie meer functional approach. Het werkt maar imho een letterlijke 1:1 overzetting van het algorithme levert lelijke code op.

[ZieglerNichols]

Dag 6 in MATLAB

spoiler: Dag 6

Wilde eerst voor deel 2 de loop weer runnen met als start het antwoord van deel 1, maar toen bedacht ik dat je het antwoord voor deel 2 gewoon kan opzoeken in de lijst met reeds opgeslagen memory bank configuraties!

[Anoniem: 159174]

Begonnen met een simpele full table scan in C. Voordeel bleek dat daardoor opdracht 2 triviaal was. Runtijd 560ms.

Daarna toch een basic hashing uitgeschreven. Programmeren duurde wat langer, maar runtijd nu onder de 50ms. Ik vind het prima!

[Ryada]

Dag 6 in C#

Niet mijn beste creatie ooit en zeer zeker niet de snelste. Verder maar even proberen deze dag een stuk sneller te maken, ben niet echt tevreden met de snelheid. Duurt 1 seconde ongeveer om bij de oplossing te komen. Van mij mag er weer een opdracht 3 komen kwa difficulty, daar leer je nog wat van en het is leuker om de lastigere te doen.

[Hydra]

@Ryada probeer eens een hash-set te gebruiken i.p.v. een list. Die 'contains' is O(n) voor een list en O(1) voor een hash-set. Mijn Kotlin oplossing voor vandaag doet er 36ms over.

[ Voor 17% gewijzigd door Hydra op 06-12-2017 09:44 ]

[Ryada]

@Hydra dan zou ik met een loop moeten kijken wat de index is om deel2 te berekenen.
Wat nou ook weer niet bepaald ideaal is naar mijn mening.
Het liefst gebruik ik een array maar je kan mits je het niet alleen voor de specifieke input maakt niet echt een size binden aan je array. En een array resizen is nou niet echt snel.

[Hydra]

Ryada schreef op woensdag 6 december 2017 @ 09:48:
@Hydra dan zou ik met een loop moeten kijken wat de index is om deel2 te berekenen.

Gewoon een teller bijhouden, doe ik ook

[Marcj]

Raynman schreef op dinsdag 5 december 2017 @ 22:00:
[...]

Hoe compile je dat? Ik heb even een paar varianten geprobeerd. Daarvoor heb ik wel eerst 'run' veranderd in 'main' (met print i.p.v. return) en 'splitOn "\n"' vervangen door de standaard 'lines' om geen extra packages te hoeven installeren.

Zonder optimalisatie zit ik op 31s met mijn input. Met -O1 wordt dat zo'n 4s en met -O2 0,35s (vergelijkbaar met mijn C++ oplossing). Bij de tragere versies zie ik ook het geheugengebruik toenemen. Met de volgende aanpassing om hem strict te maken in de accumulator (wat GHC waarschijnlijk ook doet met -O2) worden de tijden resp. 27s en 0,44s met constant geheugengebruik.

Haskell:

                     step update (ix + curr) array length $! accum + 1

Ik gebruik Haskell Stack om te compilen en running. Zelf ontwikkel ik nu in VS Code en daarvoor zit er ook een build task in (gewoon op ctrl-shift-b drukken). Ik zal eens kijken of ik wat optimalisaties aan kan zetten in het build script. Dank!

edit: Gevonden! In de .cabal file voeg je gewoon

code:

ghc-options:         -O2

toe en alles loopt nu inderdaad in 0.3s

[ Voor 5% gewijzigd door Marcj op 06-12-2017 10:12 ]

[ThaStealth]

Ik had de opdracht verkeerd gelezen, maar toch de goede uitkomst

spoiler:

Gegeven de volgende set met iteraties:
------*----------------*----------------*
(* is de eerste herhaling)
Opdracht 1 vraagt om de afstand van het begin tot de 2e * te berekenen, opdracht 2 vraagt om de afstand tussen * 2 en 3 te berekenen. Ik heb echter de opdracht verkeerd gelezen en de afstand tussen * 1 en 2 gegeven.
Maar omdat het een oneindige loop is met iteraties is de afstand natuurlijk iedere keer hetzelfde....

[Ryada]

ThaStealth schreef op woensdag 6 december 2017 @ 10:34:
Ik had de opdracht verkeerd gelezen, maar toch de goede uitkomst

spoiler:

Gegeven de volgende set met iteraties:
------*----------------*----------------*
(* is de eerste herhaling)
Opdracht 1 vraagt om de afstand van het begin tot de 2e * te berekenen, opdracht 2 vraagt om de afstand tussen * 2 en 3 te berekenen. Ik heb echter de opdracht verkeerd gelezen en de afstand tussen * 1 en 2 gegeven.
Maar omdat het een oneindige loop is met iteraties is de afstand natuurlijk iedere keer hetzelfde....

spoiler:

Volgens mij vragen ze ook om de afstand van * 1 tot * 2. Ik kan iig niet achterhalen waarom het tussen * 2 en * 3 moet zijn of waar dat gespecificeerd word.

[ThaStealth]

Ryada schreef op woensdag 6 december 2017 @ 10:36:
[...]

spoiler:

Volgens mij vragen ze ook om de afstand van * 1 tot * 2. Ik kan iig niet achterhalen waarom het tussen * 2 en * 3 moet zijn of waar dat gespecificeerd word.

spoiler:

starting from a state that has already been seen, how many block redistribution cycles must be performed before that same state is seen again?

Already been seen = dus de 2e keer dat hij gezien is.

Ryada schreef op woensdag 6 december 2017 @ 09:48:
@Hydra dan zou ik met een loop moeten kijken wat de index is om deel2 te berekenen.
Wat nou ook weer niet bepaald ideaal is naar mijn mening.
Het liefst gebruik ik een array maar je kan mits je het niet alleen voor de specifieke input maakt niet echt een size binden aan je array. En een array resizen is nou niet echt snel.

Wellicht van toepassing op jouw oplossing:

spoiler:

Gisteren maakte ik de fout dat ik een array by ref doorgaf en aannam dat het by val was:
https://gathering.tweaker...message/53477167#53477167 waardoor oplossing 2 langer duurde dan ik wilde voordat ik dat doorhad
Bij oplossing 2 van vandaag was het het eenvoudigste om dat gewoon wel te doen (de gemanipuleerde input doorgeven). aangezien dat dan als startpunt kon fungeren.

Ik heb een hashset gebruikt in C# en hij is bij mij <1ms (volgens de debugger)

[ Voor 21% gewijzigd door ThaStealth op 06-12-2017 10:44 ]

[Ryada]

Ah had hem nu dus 3x verkeerd begrepen haha.
Maar wel de goede oplossing gehad. Nu snap ik hem iig.

[Quadro!]

Marcj schreef op dinsdag 5 december 2017 @ 12:59:
Ik heb zojuist met Haskell een oplossing gemaakt met een STUArray, omdat met immutables dit volgens mij niet efficient te doen is. Toch doet de implementatie er nog 9 seconden over, wat dan toch lang lijkt.

https://github.com/marcde...7/blob/master/src/Day5.hs

Iemand een idee of dit sneller te krijgen is in Haskell?

Weet niet of die 9 seconden met of zonder optimalisaties is, maar in de reddit thread was iemand die met mutable vectors een implementatie had die naar eigen zeggen "instantly" draaide (bron).

[Marcj]

Quadro! schreef op woensdag 6 december 2017 @ 10:44:
[...]


Weet niet of die 9 seconden met of zonder optimalisaties is, maar in de reddit thread was iemand die met mutable vectors een implementatie had die naar eigen zeggen "instantly" draaide (bron).

Zie mijn reactie hierboven, ik was inderdaad de -O2 vergeten. Nu loopt hij in 0.3 seconden.

[Anoniem: 1006581]

Ryada schreef op woensdag 6 december 2017 @ 09:21:
Dag 6 in C#

Niet mijn beste creatie ooit en zeer zeker niet de snelste. Verder maar even proberen deze dag een stuk sneller te maken, ben niet echt tevreden met de snelheid. Duurt 1 seconde ongeveer om bij de oplossing te komen. Van mij mag er weer een opdracht 3 komen kwa difficulty, daar leer je nog wat van en het is leuker om de lastigere te doen.

Nice, lijkt heel erg op mijn oplossing. Twee kleine puntjes:

Waarom je memory block array converteren naar comma separated string? Houd gewoon een

code:

List<int[]>

bij met all configurations, kan je vervolgens met

code:

SequenceEquals

kijken of de int[] in de lijst voorkomt, deze lookup is iets sneller
• Om de index in een array "around" te laten "wrappen" (als in bijvoorbeeld: array[16] in een array van 15 items = array[0]). Dit los jij op door te checken of de `index` is groter dan de lengte van de array, en zo ja de index handmatig op 0 zetten, maar je kunt ook gebruik maken van:

code:

index = index % array.Length;

Hierbij mijn dag 1 en 2:
https://github.com/nbokma.../master/Day6/Day6Part1.cs
https://github.com/nbokma.../master/Day6/Day6Part2.cs

[Ryada]

Anoniem: 1006581 schreef op woensdag 6 december 2017 @ 10:50:
[...]


Nice, lijkt heel erg op mijn oplossing. Twee kleine puntjes:

Waarom je memory block array converteren naar comma separated string? Houd gewoon een

code:

List<int[]>

bij met all configurations, kan je vervolgens met

code:

SequenceEquals

kijken of de int[] in de lijst voorkomt, deze lookup is iets sneller
• Om de index in een array "around" te laten "wrappen" (als in bijvoorbeeld: array\[16] in een array van 15 items = array\[0]). Dit los jij op door te checken of de `index` is groter dan de lengte van de array, en zo ja de index handmatig op 0 zetten, maar je kunt ook gebruik maken van:

code:

index = index % array.Length;

Hierbij mijn dag 1 en 2:
https://github.com/nbokma.../master/Day6/Day6Part1.cs
https://github.com/nbokma.../master/Day6/Day6Part2.cs

Ik had het in eerste isntantie met een List<int[]> geprobeerd, maar daar kwam ik steeds niet uit de while loop, omdat ik niet wist dat SequenceEquals bestond. de % moet ik ook nog eens uitzoeken de ene keer snap ik hem wel de andere keer niet (niet zo heel slim ben ik af en toe). Zal mijn code aanpassen want moet hem zowieso aanpassen voor deel2

EDIT: Met de change naar List<int[]> is het niet echt `iets` sneller. Er is letterlijk 1 seconde van de hele execution time afgegaan. ipv 1.4 seconde duurt het nu nog maar 0.4 seconde. Danku ik heb weer wat geleerd vandaag Blijkbaar werkt het toch niet helemaal perfect, want die 0,4 seconde is als ik maar 1x loop door een foutje. Als ik de volledige loop doe op jou manier heb ik een execution time van 4.5 sec ipv 1.5 seconden zoals ik eerst had.

[ Voor 14% gewijzigd door Ryada op 06-12-2017 11:20 ]

[ThaStealth]

Ryada schreef op woensdag 6 december 2017 @ 10:56:
[...]

Ik had het in eerste isntantie met een List<int[]> geprobeerd, maar daar kwam ik steeds niet uit de while loop, omdat ik niet wist dat SequenceEquals bestond. de % moet ik ook nog eens uitzoeken de ene keer snap ik hem wel de andere keer niet (niet zo heel slim ben ik af en toe). Zal mijn code aanpassen want moet hem zowieso aanpassen voor deel2

EDIT: Met de change naar List<int[]> is het niet echt `iets` sneller. Er is letterlijk 1 seconde van de hele execution time afgegaan. ipv 1.4 seconde duurt het nu nog maar 0.4 seconde. Danku ik heb weer wat geleerd vandaag Blijkbaar werkt het toch niet helemaal perfect, want die 0,4 seconde is als ik maar 1x loop door een foutje. Als ik de volledige loop doe op jou manier heb ik een execution time van 4.5 sec ipv 1.5 seconden zoals ik eerst had.

Probeer eens een hashtable<string>

[Anoniem: 1006581]

Ryada schreef op woensdag 6 december 2017 @ 10:56:
[...]

Ik had het in eerste isntantie met een List<int[]> geprobeerd, maar daar kwam ik steeds niet uit de while loop, omdat ik niet wist dat SequenceEquals bestond. de % moet ik ook nog eens uitzoeken de ene keer snap ik hem wel de andere keer niet (niet zo heel slim ben ik af en toe). Zal mijn code aanpassen want moet hem zowieso aanpassen voor deel2

EDIT: Met de change naar List<int[]> is het niet echt `iets` sneller. Er is letterlijk 1 seconde van de hele execution time afgegaan. ipv 1.4 seconde duurt het nu nog maar 0.4 seconde. Danku ik heb weer wat geleerd vandaag Blijkbaar werkt het toch niet helemaal perfect, want die 0,4 seconde is als ik maar 1x loop door een foutje. Als ik de volledige loop doe op jou manier heb ik een execution time van 4.5 sec ipv 1.5 seconden zoals ik eerst had.

Vreemd, post je geüpdatete code eens?

[Ryada]

nieuwe code:
https://hastebin.com/witirinesi.cs

index = index % array.Length; heb ik er nog niet ingezet.
Reden waarom ik .Clone() as gebruik is om te kijken of dat sneller was dan .ToArray() maar het is even langzaam.

[Lye]

Mijn dag 6. Kan iets sneller als ik het imperatief uitschrijf, ik vond dit echter wel een leuke oplossing.

[ThaStealth]

Mijn oplossing Heb niet het idee dat ik hem nog sneller kan krijgen

[ Voor 94% gewijzigd door ThaStealth op 06-12-2017 13:01 ]

[Kraay89]

Daedalus schreef op dinsdag 5 december 2017 @ 20:31:

spoiler:

Waarschijnlijk kwam je er mee weg, maar je kunt ook op een negatieve index uitkomen. Zolang die kleiner is dan de lengte van de list, krijg je geen IndexError.

Oei Scherp! Dat is mijn gedachten niet eens gepasseerd.

[Anoniem: 1004565]

Mijn oplossing in Rust:

https://github.com/DutchG...ter/Rust/day6/src/main.rs

Werkt super snel!

[Lye]

Hydra schreef op woensdag 6 december 2017 @ 09:59:
[...]


Gewoon een teller bijhouden, doe ik ook

Die teller is natuurlijk gelijk aan seen.size he😉

[veldsla]

Anoniem: 1004565 schreef op woensdag 6 december 2017 @ 13:29:
Mijn oplossing in Rust:

https://github.com/DutchG...ter/Rust/day6/src/main.rs

Werkt super snel!

Netjes! Ik heb een niet gebruikte optimalisatie erin zitten. Ik verwachtte grote getallen te moeten verdelen, maar dat blijkt met mijn input niet zo te zijn. Wel veel meer iteraties voor mijn input nodig vergeleken met jouw input (13K vs 3K). Runtijd met beide programma's op mijn input zo'n ~10ms

[Radiant]

Ik vind het wel erg makkelijk allemaal tot nu toe.. In voorgaande jaren was part 1 altijd wel makkelijk te bruteforcen en ontkwam je niet aan een slimmere oplossing in part 2, maar tot nu toe zijn de meeste problemen wel in een paar minuutjes in elkaar gehackt.

Ohwell, mijn Python-kennis groeit met de dag en hopelijk wordt het later nog een slagje moeilijker.

* Radiant hoopt op een herhaling van dag 11 2016

[Edwin88]

Ik merk dat ik de array looping opdrachtjes wel leuk vind. Ben momenteel veel bezig met TypeScript en RxJS dus dan is wat brein training met arrays en loopjes wel handig.

Dag 6 redelijk simpel kunnen houden:
https://github.com/EdwinM...ob/master/src/06/index.ts

spoiler:

Ben alleen benieuwd of een 'string' comparison van de hash de snelste manier is in JS. Ik had in ieder geval bedacht dat het sneller zou zijn dan arrays vergelijken. Zou dit efficiënter kunnen? (typescript/JS)

[Hydra]

Lye schreef op woensdag 6 december 2017 @ 13:34:
Die teller is natuurlijk gelijk aan seen.size he😉

Niet in deel 2

Radiant schreef op woensdag 6 december 2017 @ 14:07:
Ik vind het wel erg makkelijk allemaal tot nu toe.. In voorgaande jaren was part 1 altijd wel makkelijk te bruteforcen en ontkwam je niet aan een slimmere oplossing in part 2, maar tot nu toe zijn de meeste problemen wel in een paar minuutjes in elkaar gehackt.

Het is ook de bedoeling dat het voor beginners redelijk te doen is het. Zeg maar de eerste tig Project Euler vragen.

[ Voor 57% gewijzigd door Hydra op 06-12-2017 14:15 ]

[Anoniem: 1004565]

veldsla schreef op woensdag 6 december 2017 @ 14:06:
[...]


Netjes! Ik heb een niet gebruikte optimalisatie erin zitten. Ik verwachtte grote getallen te moeten verdelen, maar dat blijkt met mijn input niet zo te zijn. Wel veel meer iteraties voor mijn input nodig vergeleken met jouw input (13K vs 3K). Runtijd met beide programma's op mijn input zo'n ~10ms

Ik zie dat je bij jouw oplossing een reference naar de geparste Vector geeft aan Mem::new()...en vervolgens roep je in de new functie 'v.to_vec()' aan.... Je kan volgens mij gewoon ownership van de vector aan Mem::new() geven, je gebruikt de geparste vector toch niet meer in main!,

dus dan word het 'fn new(v: Vec<usize>) -> Mem {...}', en in main roep je dan 'Mem::new(v)'

En Rust heeft een include_str() functie, waarbij op compileer tijd het bestand als een string in het programma gezet wordt...dan hoef je niet moeilijk te doen met een bestand uitlezen

[ Voor 10% gewijzigd door Anoniem: 1004565 op 06-12-2017 14:27 ]

[veldsla]

Je hebt gelijk, maar ik verwachtte (ik verwacht wel een hoop) dat we iets anders met de data voor part 2 moesten doen.

[Anoniem: 420461]

Edwin88 schreef op woensdag 6 december 2017 @ 14:07:
Dag 6 redelijk simpel kunnen houden:

spoiler:

Huh? Je zet bank[largestIndex] = 0; en daarna gebruik je hem met i <= bank[largestIndex] in de for-loop - hoe kan dat werken?

[Edwin88]

Anoniem: 420461 schreef op woensdag 6 december 2017 @ 14:26:
[...]

spoiler:

Huh? Je zet bank[largestIndex] = 0; en daarna gebruik je hem met i <= bank[largestIndex] in de for-loop - hoe kan dat werken?

Scherp!
Kennelijk voor part 2 wat dingen aangepast, geconcludeerd dat het nier werkte, nog verder aangepast, en uiteindelijk omgeschreven naar deze versie die dus niet meer werkte. Toen had ik waarschijnlijk al het antwoord voor part 1 opgestuurd.

Net even gefixt:
https://github.com/EdwinM...ob/master/src/06/index.ts

[ Voor 8% gewijzigd door Edwin88 op 06-12-2017 15:07 ]

[Kraay89]

Dag 6 ook weer opgelost.

Volgens mij hier en daar wat over-expliciet, maar het loopt allemaal ruim onder de seconde dus ik vind het wel best. Had overigens wel even wat hints uit deze thread nodig voor ik uberhaupt begreep wat men met deel 2 wilde weten.

spoiler:

En toen was het dankzij de python standard library erg snel opgelost! (index() en len())

[Soultaker]

Kraay89 schreef op woensdag 6 december 2017 @ 15:32:
Dag 6 ook weer opgelost.

Als je 'm wat sneller wil maken, kun je van found_distributions een dict maken in plaats van een list. Nu doorzoek je elke iteratie de hele lijst, wat trager wordt naarmate de lijst langer is.

De keys in een dict moeten immutable zijn. De immutable variant van list is tuple. Je moet dan elke iteratie je lijst converteren naar een tuple (tuple(new_input)) maar daar staat tegenover dat je je lijst niet steeds hoeft te kopiëren (met new_input\[::]) zoals je nu doet.

[Kraay89]

Soultaker schreef op woensdag 6 december 2017 @ 15:58:
[...]

Als je 'm wat sneller wil maken, kun je van found_distributions een dict maken in plaats van een list. Nu doorzoek je elke iteratie de hele lijst, wat trager wordt naarmate de lijst langer is.

De keys in een dict moeten immutable zijn. De immutable variant van list is tuple. Je moet dan elke iteratie je lijst converteren naar een tuple (tuple(new_input)) maar daar staat tegenover dat je je lijst niet steeds hoeft te kopiëren (met new_input\[::]) zoals je nu doet.

Wel nog over een dict nagedacht, maar het voelde onzinnig om een dict met None-values aan te maken. Aan de andere kant natuurlijk niks op tegen als het de snelheid ten goede komt.

[Daedalus]

Soultaker schreef op woensdag 6 december 2017 @ 15:58:
[...]

Als je 'm wat sneller wil maken, kun je van found_distributions een dict maken in plaats van een list. Nu doorzoek je elke iteratie de hele lijst, wat trager wordt naarmate de lijst langer is.

De keys in een dict moeten immutable zijn. De immutable variant van list is tuple. Je moet dan elke iteratie je lijst converteren naar een tuple (tuple(new_input)) maar daar staat tegenover dat je je lijst niet steeds hoeft te kopiëren (met new_input\[::]) zoals je nu doet.

Een set lijkt me meer geschikt voor deze oplossing

[Dr. Horrible]

ThaStealth schreef op woensdag 6 december 2017 @ 10:40:
[...]

spoiler:

starting from a state that has already been seen, how many block redistribution cycles must be performed before that same state is seen again?

Already been seen = dus de 2e keer dat hij gezien is.

spoiler:

Aangezien het algorithme voor het herdistribueren van de blocks elke keer hetzelfde is zou het vanaf de eerste keer dat de herhaling gezien is, hetzelfde proces gevolgd moeten worden. Dus of het nou van de 1e tot de 2e is, 2e tot de 3e of zelfs 30e tot de 31e, de uitkomst is exact hetzelfde

[herbalmart77]

User: HerbalMart 77
Repo: none
Language: C# (soms Excel)

Aantal sterren: 5

Problem with: Day 3. WTF die circular grid

[Edwin88]

herbalmart77 schreef op woensdag 6 december 2017 @ 16:24:
User: HerbalMart 77
Repo: none
Language: C# (soms Excel)

Aantal sterren: 5

Problem with: Day 3. WTF die circular grid

spoiler:

Bij mij viel het kwartje in deel 2 toen ik besefte dat je voor elke stap moet kijken of je de 'bocht al om kan'. Zodra je de bocht om kan, verander je direction en kan je verder het geheel invullen.

Ik heb wat onconventioneel een array gebruikt van waardes + x/y coordinaten, maar hierdoor kon ik die 'points' simpelweg filteren en optellen waardoor ik de uiteindelijke waarde kreeg:

value = gridValues
.filter((entry) => Math.abs(entry.x - x) <= 1 && Math.abs(entry.y - y) <= 1) // grab all fields around item
.reduce((total, {value}) => total + value, 0); // count total

en:

switch (direction) {
case directions.right:
x++;
direction = (gridValues.some((entry) => entry.y === y - 1 && entry.x === x)) ? direction : directions.up;
break;
case directions.up:
y--;
direction = (gridValues.some((entry) => entry.y === y && entry.x === x - 1)) ? direction : directions.left;
break;
case directions.left:
x--;
direction = (gridValues.some((entry) => entry.y === y + 1 && entry.x === x)) ? direction : directions.down;
break;
case directions.down:
y++;
direction = (gridValues.some((entry) => entry.y === y && entry.x === x + 1)) ? direction : directions.right;
break;
}

[upclocker]

Wat is het verschil in python eigenlijk als x = [inhoud] en je dan x[::] in plaats van x als input gebruikt? Toen ik x[::] werkte het wonderbaarlijk wel, maar heb geen idee waarom.

[Lye]

upclocker schreef op woensdag 6 december 2017 @ 18:37:
Wat is het verschil in python eigenlijk als x = [inhoud] en je dan x[::] in plaats van x als input gebruikt? Toen ik x[::] werkte het wonderbaarlijk wel, maar heb geen idee waarom.

x[::] maakt een kopie van de lijst, overigens kun je ook gewoon x[:] gebruiken.

Voorbeeld:

>>> a=[1, 2, 3]
>>> b=a
>>> b[2]=4
>>> print(a, b) # a en b verwijzen naar dezelfde lijst
([1, 2, 4], [1, 2, 4])
>>> b=a[:]
>>> b[0]=4
>>> print(a, b) #a verwijst nog naar de oorspronkelijke lijst, b naar een kopie er van
([1, 2, 4], [4, 2, 4])

[ Voor 39% gewijzigd door Lye op 06-12-2017 19:09 ]

[upclocker]

Lye schreef op woensdag 6 december 2017 @ 19:04:
[...]


x[::] maakt een kopie van de lijst, overigens kun je ook gewoon x[:] gebruiken.

Voorbeeld:

>>> a=[1, 2, 3]
>>> b=a
>>> b[2]=4
>>> print(a, b) # a en b verwijzen naar dezelfde lijst
([1, 2, 4], [1, 2, 4])
>>> b=a[:]
>>> b[0]=4
>>> print(a, b) #a verwijst nog naar de oorspronkelijke lijst, b naar een kopie er van
([1, 2, 4], [4, 2, 4])

Ah duidelijk, thanks.
Ik kreeg inderdaad dezelfde lijst de hele tijd.

[Anoniem: 420461]

Ik vond deze wel duidelijk: x[start:end:step] waarbij alledrie de parameters optioneel zijn.

[Soultaker]

Daedalus schreef op woensdag 6 december 2017 @ 16:05:
[...]
Een set lijkt me meer geschikt voor deze oplossing

Voor deel 1 voldoet een set prima.

Voor deel 2, waar je de lengte van de cycle moet printen, is het handig om op te slaan in welke iteratie je een combinatie voor het eerst gezien hebt.

[Reptile209]

Praktisch vraagje over de site van AoC: ik heb tot en met 6.1 op mijn laptop ingestuurd (en gehaald natuurlijk). Nu wilde ik op mijn mobiel vast de tekst van 6.2 gaan lezen, maar daar kan ik niet bij?! Kan wel 6.1 zien, maar 6.2 geeft hij daar nog niet vrij. Is daar een handige oplossing voor? Uit- en inloggen hielp niet.

[Lye]

Reptile209 schreef op woensdag 6 december 2017 @ 20:50:
Praktisch vraagje over de site van AoC: ik heb tot en met 6.1 op mijn laptop ingestuurd (en gehaald natuurlijk). Nu wilde ik op mijn mobiel vast de tekst van 6.2 gaan lezen, maar daar kan ik niet bij?! Kan wel 6.1 zien, maar 6.2 geeft hij daar nog niet vrij. Is daar een handige oplossing voor? Uit- en inloggen hielp niet.

Dat probleem doet zich niet bij mij voor.. Ben je wel met hetzelfde account ingelogd?

[Reptile209]

Lye schreef op woensdag 6 december 2017 @ 20:57:
[...]


Dat probleem doet zich niet bij mij voor.. Ben je wel met hetzelfde account ingelogd?

Ah, dat was het idd. Was op mijn laptop - dacht ik - met Google ingelogd, maar het bleek Twitter te zijn. Apart

[Daedalus]

Soultaker schreef op woensdag 6 december 2017 @ 20:48:
[...]
Voor deel 2, waar je de lengte van de cycle moet printen, is het handig om op te slaan in welke iteratie je een combinatie voor het eerst gezien hebt.

Daarvoor gebruik ik twee variabelen; een om aan te geven hoe vaak we de infinite doorlopen hebben, en een andere met aantal cycles wanneer we een combinatie voor het eerst de twee keer zien. Jouw oplossing met een dict is wel algemener.

[The Fox NL]

herbalmart77 schreef op woensdag 6 december 2017 @ 16:24:
User: HerbalMart 77
Repo: none
Language: C# (soms Excel)

Aantal sterren: 5

Problem with: Day 3. WTF die circular grid

Dat is inderdaad een pittige. Maar als je voor deel 1 een methode hebt om het aantal stappen te berekenen kan je die in deel 2 weer gebruiken om de x en y coördinaten uit te rekenen. Zo heb ik het in ieder geval gedaan.

[dcm360]

Zojuist ook aan de late kant dag 6 opgelost. Voor het eerste deel had ik een oplossing met een HashSet gebouwd, en voor het tweede deel was het dus een eenvoudige upgrade naar een HashMap om ook nog even het aantal iteraties bij te houden.

[Kraay89]

Edwin88 schreef op dinsdag 5 december 2017 @ 13:09:

Hint:

spoiler:

Hier heb ik ook lang over gedaan, tot ik door had dat je simpelweg kan kijken of je al 'de bocht om kan' bij de volgende stap.

Ik heb eindelijk ook 3.2 opgelost! op een best wel gave manier al zeg ik het zelf. Bedankt voor de tip, heb het uiteindelijk iets anders gedaan.

spoiler:

Als mijn spiraal (matrix) helemaal ingevuld is, draai ik hem negentig graden en voeg een rij nullen onder aan toe. Dit werkt vanaf n =1. Vervolgens reken ik de juiste waardes netjes uit en vervang de nullen daarvoor. Rinse repeat totdat de juiste waarde voorbij komt.

[ZieglerNichols]

Dag 7 was weer wat moeilijker! Die recursie gaat bij mij nooit in een keer goed, maar het is gelukt.

spoiler:

Eerst parsen in een struct (MATLAB), dan voor deel 1 voor elke entry kijken of die ook ergens aan de rechterkant van een --> voorkomt. Zo niet, dan is dat de start van de tree.
Voor deel 2 een recursieve getChildWeight() functie gemaakt en daarna semi-handmatig checken welk gewicht in onbalans is. Gelukkig maar iets van 4 lagen diep.

[Daanoz]

Inderdaad, dit was gelukkig weer even andere koek...

spoiler:

Ik heb zelf wel een zwakheid in mijn code gevonden voor deel 2 maar ik weet niet of het bij iemand een probleem is, en of het überhaupt op te lossen is. Bij mijn input is het in ieder geval geen probleem...

Bij het opzoeken van het programma met het verkeerde 'gewicht'. Indien een van de programma's onderweg 2 childs heeft (met verschillende gewichten), gooi ik maar een exceptie... Hoe is vanaf daar te bepalen welke branch fout is?

[ZieglerNichols]

Daanoz schreef op donderdag 7 december 2017 @ 08:04:
Inderdaad, dit was gelukkig weer even andere koek...

spoiler:

Ik heb zelf wel een zwakheid in mijn code gevonden voor deel 2 maar ik weet niet of het bij iemand een probleem is, en of het überhaupt op te lossen is. Bij mijn input is het in ieder geval geen probleem...

Bij het opzoeken van het programma met het verkeerde 'gewicht'. Indien een van de programma's onderweg 2 childs heeft (met verschillende gewichten), gooi ik maar een exceptie... Hoe is vanaf daar te bepalen welke branch fout is?

spoiler:

Bij mijn input kwam die situatie niet voor, er waren altijd meer dan 2 childs in de onbalans-tak. Misschien is dat zo voor iedereen?

[ThaStealth]

Ik heb ze ook weer beide,

spoiler:

De eerste kan zonder programmeren, gewoon je favoriete editor (of in browser) een random string pakken, daarop zoeken, als hij als subitem voorkomt pak je de eerste string van die rij, daar ga je weer op zoeken totdat je bij eentje uitkomt die geen "parent" meer heeft. Dit is je antwoord

[veldsla]

De eerste kan inderdaad met de hand. Dus dan doen we het met de shell. Beetje grep sed sort en diff
7b maar in Perl opgelost. Leuke opdracht!

Aargh. Wat heeft GitHub met de source highlighting uitgespookt? Ah hij denk dat het prolog is. Gefixed met een vim modeline.

[ Voor 29% gewijzigd door veldsla op 07-12-2017 10:30 ]

[Anoniem: 159174]

ZieglerNichols schreef op donderdag 7 december 2017 @ 08:19:
[...]

spoiler:

Bij mijn input kwam die situatie niet voor, er waren altijd meer dan 2 childs in de onbalans-tak. Misschien is dat zo voor iedereen?

spoiler:

Ook hier kwam het niet voor. In mijn pogramma deze situatie wel onderkend, maar afgehandeld met een noodstop... Vermoedde dat ze dit deze situatie niet zouden doen voorkomen. Je weet overigens welke subtree je in dit geval moet analyseren, dus zou wel degelijk kunnen.

Deze kostte wat meer ontwikkeltijd dan gisteren.... runtijd 1ms, zal ongetwijfeld sneller kunnen.

[ Voor 3% gewijzigd door Anoniem: 159174 op 07-12-2017 10:43 ]

[Hydra]

Kotlin dag 7

spoiler:

Deel een viel mee; een boom opbouwen en dan de naam van de root node teruggeven. Deel 2 was een stuk lastiger; had een denkfout gemaakt en daar kwam ik pas achter door het even met de voorbeeldinput te proberen. En toen ik eenmaal de traversal werkend had en het antwoord had (en gesubmit) moest ik nog zorgen dat deel 2 ook netjes alleen dat getal teruggaf.

[ Voor 2% gewijzigd door Hydra op 07-12-2017 10:56 . Reden: Kennelijk een spoiler ]

[ThaStealth]

Daanoz schreef op donderdag 7 december 2017 @ 08:04:
Inderdaad, dit was gelukkig weer even andere koek...

spoiler:

Ik heb zelf wel een zwakheid in mijn code gevonden voor deel 2 maar ik weet niet of het bij iemand een probleem is, en of het überhaupt op te lossen is. Bij mijn input is het in ieder geval geen probleem...

Bij het opzoeken van het programma met het verkeerde 'gewicht'. Indien een van de programma's onderweg 2 childs heeft (met verschillende gewichten), gooi ik maar een exceptie... Hoe is vanaf daar te bepalen welke branch fout is?

spoiler:

Mijn applicatie vertrouwd er op dat er een verschil is tussen de verschillende subnodes, en er minimaal 2 hetzelfde zijn. Werkt bij mij ook prima, dus zal wel veilig zijn als input

[Edwin88]

Hydra schreef op donderdag 7 december 2017 @ 10:49:
Kotlin dag 7

spoiler:

Deel een viel mee; een boom opbouwen en dan de naam van de root node teruggeven.

Deel 2 was een stuk lastiger; had een denkfout gemaakt en daar kwam ik pas achter door het even met de voorbeeldinput te proberen. En toen ik eenmaal de traversal werkend had en het antwoord had (en gesubmit) moest ik nog zorgen dat deel 2 ook netjes alleen dat getal teruggaf.

spoiler:

Vergeet de spoiler tag nou niet!

[Hydra]

ThaStealth schreef op donderdag 7 december 2017 @ 10:51:

spoiler:

Mijn applicatie vertrouwd er op dat er een verschil is tussen de verschillende subnodes, en er minimaal 2 hetzelfde zijn. Werkt bij mij ook prima, dus zal wel veilig zijn als input

spoiler:

Idd. Ik groepeer het lijstje nodes op gewicht. Ik ga er vanuit dat de lijst met 1 item 'fout' is en de lijst met meer dan 1 item 'goed'.

Edwin88 schreef op donderdag 7 december 2017 @ 10:53:

spoiler:

Vergeet de spoiler tag nou niet!

Wat is daar een spoiler aan dan? Daarnaast snap ik niet je je eigen reactie in een spoiler zet maar niet 't stuk dat je quote.

[ Voor 23% gewijzigd door Hydra op 07-12-2017 10:56 ]

[Hydra]

...

[ Voor 100% gewijzigd door Hydra op 07-12-2017 10:56 ]

[Soultaker]

Daanoz schreef op donderdag 7 december 2017 @ 08:04:

spoiler:

Indien een van de programma's onderweg 2 childs heeft (met verschillende gewichten), gooi ik maar een exceptie... Hoe is vanaf daar te bepalen welke branch fout is?

Kan ook niet. Maar in het verleden is wel vaker gebleken dat je bij Advent of Code aannamen moet doen die niet in de opgave staan (of die je uit de invoer kan afleiden, in plaats van uit de opgave).

[Lye]

spoiler:

Volgens deze thread is het niet mogelijk dat er maar 2 childs zijn met beiden een verschillend gewicht.

[Edwin88]

Wat is daar een spoiler aan dan? Daarnaast snap ik niet je je eigen reactie in een spoiler zet maar niet 't stuk dat je quote.

Woeps, inderdaad quote niet voorzien van de juiste spoiler.
Je opent je post met een manier om het antwoord te vinden, ook al is het vrij simpel.

spoiler:

Overigens is het hele opbouwen van de boom niet nodig. Je hoeft enkel te kijken welke node geen parents heeft en je hebt de root node gevonden.

[ Voor 23% gewijzigd door Edwin88 op 07-12-2017 11:41 ]

[Anoniem: 159174]

Lye schreef op donderdag 7 december 2017 @ 11:31:

spoiler:

Volgens deze thread is het niet mogelijk dat er maar 2 childs zijn met beiden een verschillend gewicht.

spoiler:

Als de allerlaagste base van de tree (die dus op geen enkele andere staat) exact twee subtrees heeft, weet je het niet. Bij alle andere situaties wel. Je weet immers wat het totale gewicht van de subtree moet zijn. Als er twee stapels boven liggen met gelijk gewicht -> pas de basis van de subtree aan. Is er verschillend gewicht: moet er gewicht bij dan is de lichtste van de subtree de boosdoener, moet er gewicht af, dan de zwaarste. Daarna recursen naar boven toe.

Uitgangspunt is dat er maar één moet worden aangepast, en dat hoef je niet te controleren in de input. Dit constraint zorgt ervoor dat het gewoon oplosbaar is (m.u.v. de situatie van slechts twee subtrees boven de laagste base).

[Lye]

Ook mijn code staat eindelijk online.

[ZieglerNichols]

Het leukste deel van AoC moet nog komen, aangezien het moeilijkheidsniveau van de vragen nog verder zal toenemen. Echter vertrek ik over een paar dagen op vakantie, dus dan kan ik mijn plek in het leaderbord niet meer vasthouden . Was wel leuk om na de 1e week bovenaan te staan (gelukkig wordt ik altijd al vroeg wakker ).

Ik ga als ik terug ben nog wel een keertje alle dagen inhalen. Veel succes aan iedereen met de competitie!

[Anoniem: 159174]

. Echter vertrek ik over een paar dagen op vakantie

Prettige vakantie! Je kan natuurlijk ook daar vroeg wakker worden....

[Peelee]

Wat me telkens opvalt is dat het opkuisen en optimaliseren al bijna even leuk is als het vinden van het juiste resultaat zelf Hopelijk komen er nog zo aan!

[Hydra]

Kotlin Day 8

Vond dit een leuke om te doen

Peelee schreef op donderdag 7 december 2017 @ 20:37:
Wat me telkens opvalt is dat het opkuisen en optimaliseren al bijna even leuk is als het vinden van het juiste resultaat zelf Hopelijk komen er nog zo aan!

Doe ik ook Eerst code submitten en daarna de code opschonen en mooier / meer FP maken

[ Voor 51% gewijzigd door Hydra op 08-12-2017 07:54 ]

[veldsla]

FP, och ik ga gewoon lekker ongevalideerde regels evallen...WCPGW? Misschien moet ik de regexp iets explicieter maken ........done

Ook maar de Rust versie. Ook leuk. Alles leuk (behalve het weer)

[ Voor 40% gewijzigd door veldsla op 08-12-2017 10:57 ]

[kenneth]

Inderdaad allemaal erg leuk maar wat een verschrikkelijke mutable en soms imperatieve code poep ik eruit deze week. Zelfs de syntax highlighting van VS wrijft het in mijn gezicht met opvallende kleuren.

Het echte FP leren begint nu eigenlijk. Komend weekend de code van de afgelopen dagen maar eens onder de loep nemen.

[Camulos]

Dag 8 is erg leuk.. heb hem straightforward geimplementeerd met twee good ol' switch statements
Gelukkig zijn er ook niet zoveel operators

C# dag 8

Dag 7 daarentegen heb ik uiteindelijk in part2 op basis van de output in de console opgelost.. en vanmiddag eens de logica schrijven zodat het programma de juiste output geeft in plaats van een blurp aan console-writelines van partial trees

[ Voor 32% gewijzigd door Camulos op 08-12-2017 09:58 ]

[Hydra]

FF een refactoring slag gedaan. Iets meer functioneel en van 54 naar 44 42 regels.

[ Voor 7% gewijzigd door Hydra op 08-12-2017 10:10 ]

[ThaStealth]

Dag 8 was een makkie tov gisteren, gewoon loopje doorlopen en bewerkingen uitvoeren, was meer regels code/tijd kwijt aan het interpreten van de input dan de daadwerkelijke bewerkingen

Camulos schreef op vrijdag 8 december 2017 @ 09:56:
Dag 8 is erg leuk.. heb hem straightforward geimplementeerd met twee good ol' switch statements
Gelukkig zijn er ook niet zoveel operators

C# dag 8

spoiler:

Je kan een grote if maken waar je alle situaties checket (op2 == "<" && registers[reg2] < num2) || ....

De 2e switch kun je met 1 if oplossen

[ Voor 14% gewijzigd door ThaStealth op 08-12-2017 11:16 ]

[Hydra]

ThaStealth schreef op vrijdag 8 december 2017 @ 10:01:
Dag 8 was een makkie tov gisteren, gewoon loopje doorlopen en bewerkingen uitvoeren, was meer regels code/tijd kwijt aan het interpreten van de input dan de daadwerkelijke bewerkingen

Heb nu ook een helper functie gemaakt die de input meteen tegen een regex aanhoudt en de groepen splitst; gaat vast vaker nodig zijn.