Advent of Code 2017

[Soultaker]

Hydra schreef op woensdag 20 december 2017 @ 08:24:

spoiler:

Hoewel ik de juiste antwoorden direct kreeg gaat dit niet werken voor alle inputs omdat ik niet detecteer of particles elkaar nog kunnen raken. Ik itereer gewoon 'dom' 500 keer en ga er dan maar vanuit dat het wel gelukt is.

Mja, voor deel 1

spoiler:

hoef je maar één tijdpunt ver in de toekomst te kiezen (e.g. t=1000000000), en kun je alle posities op dat tijdstip uitrekenen. Een taal met variable-length integers helpt omdat je je dan geen zorgen hoeft te maken over overflow.

. Voor deel 2

spoiler:

moet je eigenlijk wel itereren

.

Ik heb wel wat ideeën voor hoe je het netter op kunt lossen, maar het format van Advent of Code nodigt daar niet echt toe uit (zeker niet als je voor de score speelt: dan is een quick and dirty oplossing bijna altijd beter).

[Peelee]

Vandaag bracht herinneringen boven aan menige fysica en mechanica cursus, niet zo moeilijk maar wel leuk

spoiler:

Als alternatieve, niet-itererende oplossing heb ik voor deel 1 enkel gecheckt welke van de particles de laagste versnellingsvector heeft.
In de 'long run' zal die uiteindelijk het traagste van punt (0,0,0) weggaan, ongeacht z'n initiële snelheid en positie.

[EnnaN]

Peelee schreef op woensdag 20 december 2017 @ 10:57:
Vandaag bracht herinneringen boven aan menige fysica en mechanica cursus, niet zo moeilijk maar wel leuk

spoiler:

Als alternatieve, niet-itererende oplossing heb ik voor deel 1 enkel gecheckt welke van de particles de laagste versnellingsvector heeft.
In de 'long run' zal die uiteindelijk het traagste van punt (0,0,0) weggaan, ongeacht z'n initiële snelheid en positie.

Ja, die had ik ook, maar het klopt niet helemaal tenzij je goed je best doet bij de tie-breaker. Ik had de mazzel dat het voor mijn input goed gaat, maar het is wel tricky .

spoiler:

Als je versnelling gelijk is, dan is degene die het dichtste bij blijft degene met de laagste (absolute) snelheid. Dus je kan de absolute snelheid als tie-breaker gebruiken.

Dat kan ook goed gaan, behalve als je (voorbeeld van reddit gejat) deze input had ergens:

p=<0,0,0>, v=<0,0,0>, a=<1,0,0>
p=<0,0,0>, v=<-1,0,0>, a=<1,0,0>

pixel 0 lijkt dichterbij want is dichter bij nulpunt in de tie-breaker, maar pixel 1 gaat eerst 'de andere kant op', en komt dus vervolgens dichter bij te liggen.

[Peelee]

Goed gezien inderdaad!

spoiler:

Dan speelt de initiele snelheid ook een rol, of als die ook nog eens gelijk is de beginpositie

[EnnaN]

Peelee schreef op woensdag 20 december 2017 @ 11:27:
Goed gezien inderdaad!

spoiler:

Dan speelt de initiele snelheid ook een rol, of als die ook nog eens gelijk is de beginpositie

spoiler:

ja, maar je kan dus niet alleen de absoulte beginsnelheid nemen! een simpele tweede check op snelheid (en positie) is dus in dat voorbeeld ook niet genoeg!

[veldsla]

Het antwoord vinden bij dag 20 door te kijken naar de output leidde vlotjes tot de juiste oplossing. Het vinden van de juiste condities om de loop te breken vond ik nog het lastigst. Misschien kan het ook wel efficienter...

Nu nog tijd vinden voor dag19...

[Anoniem: 1004565]

Heel FromStr implementaties! Staat wel heel netjes naar mijn idee...
een conditie om de loop te breaken heb ik niet, ik laat m gewoon runnen en de getallen blijven vanzelf hetzelfde... ^^

https://github.com/DutchG...ree/master/Rust/day20/src

[The Fox NL]

veldsla schreef op woensdag 20 december 2017 @ 13:43:
Het antwoord vinden bij dag 20 door te kijken naar de output leidde vlotjes tot de juiste oplossing. Het vinden van de juiste condities om de loop te breken vond ik nog het lastigst. Misschien kan het ook wel efficienter...

Nu nog tijd vinden voor dag19...

spoiler:

Ik heb voor deel 2 de loop op 10.000 iteraties gezet. Duurde nogal lang met met gebruik van Linq, dus breekpunt gezet en gekeken hoeveel deeltjes er nog over waren. Dat veranderde niet meer, dus dat getal als antwoord ingevuld en het was goed. Later bleek dat 100 iteraties al ruim voldoende was.

Deel 1:

spoiler:

Gewoon het deeltje met de laagste versnelling gezocht en dat was er gelukkig maar 1. Waren het er meer, dan had je met Velocity en Position rekening moeten gaan houden.

[Reptile209]

Teeeeering zeg... echt anderhalf uur zitten worstelen met dag 20 deel 2.

spoiler:

Tests gingen prima, maar op de input waren er maar 6 particles weg na 1e6 iteraties. Voorbeelden uit github kwamen voor mijn input op ~500 survivors in <1000 cycles. Bleek ik bij het for-loopje dat over de x, y en z-coordinaat loopt de z over te slaan (< 2 in plaats van < 3, off-by-one).

#fuckmylife, opgelost .

Deel 1:

spoiler:

Voor ieder deeltje in 1 stap de positie op t = 1e7 berekend met x = x0 + v0 *t + a0 * t^2, en dan kijken welke de kleinste afstand oplevert. Appeltje-eitje.

[rnark]

Leuke opdracht weer vandaag, was even puzzelen.

spoiler:

Het woordje 'otherwise' had ik even gemist bij het proces dat het programma volgt. Ik checkte dus of de grootte deelbaar was door 3 en baseerde daar de rest op. Oeps...

[ThaStealth]

Leuke opdracht, vooral het roteren en flippen was even nadenken. Zie dat veel mensen er moeite mee hebben, ben dus best wel trots op mezelf dat ik als 1 van de eerste Tweakers hem opgelost heb

[veldsla]

Meh...geen zin om lang over na te denken en al helemaal niet om rotaties op string representaties van matrices the gaan implementeren.....Dus R

[Soultaker]

Damn, ik dacht dat Dag 21 niet te brute-forcen zou zijn, maar dat bleek wel het geval. Had me een hoop programmeertijd kunnen besparen door een paar seconden geduld te hebben.

Ik heb uiteindelijk een oplossing geschreven die in O(N) tijd runt (waarbij N het aantal iteraties is). Ik denk dat de meeste anderen een exponentiëel algoritme geïmplementeerd hebben. Code: https://github.com/maksve...de/blob/master/2017/21.py

Pro tip: het kan ook nóg sneller: in O(log N) tijd (als je het aantal patronen in de invoer als constante beschouwt, en integer operaties in O(1) uitvoert).

De truc is als volgt:

spoiler:

als je begint met een 3x3 tegel, heb je na 3 stappen een 9x9 tegel (3x3 -> 4x4 -> 6x6 -> 9x9). Die 9x9 tegel kun je zien als vier 3x3 tegels die zich onafhankelijk ontwikkelen; dat wil zeggen: het patroon na nog N stappen is gelijk aan het patroon dat je krijgt als je ieder kwadrant los transformeert en vervolgens de resultaten aan elkaar plakt.

Dit werkt niet met stappen van 1 omdat bij de stap van 6x6 -> 9x9 de de grenzen van de invoertegels niet overeenkomen met die van de vorige stap.)

Het gevolg hiervan is dat je per iteratie niet het hele grid hoeft bij te houden, maar alleen per 3x3 tegel in de invoer, het aantal van die tegels in het grid. Zo kun je dus in constante tijd drie iteraties vooruit berekenen. Als het totale aantal iteraties niet deelbaar is door 3, moet je op het eind nog 1 of 2 losse stappen doen.

Om dit naar O(log N) te optimaliseren (wat ik dus niet gedaan heb)

spoiler:

kun je de transformatiestap van 3x3 tegels naar 3x3 tegels schrijven als een vierkante matrix en die in logaritmische tijd tot de macht N/3 verheffen

[Hydra]

Lang mee bezig geweest door een stomme bug. Dag 21, Kotlin

Stomme fout gemaakt:

spoiler:

val size = if (field.size % 3 == 0) 3 else 2

in plaats van:

val size = if (field.size % 2 == 0) 2 else 3

[Reynouts]

Dit vond ik een pittige opdracht!

Het duurde al even voordat ik door had wat er precies moest gebeuren en dan nog knutselen met de rotaties/flips. Numpy is dan handig

[Anoniem: 420461]

Aan het GoT-leaderboard en de stats te zien vonden meer mensen het een lastige - zo te zien de lastigste tot nu toe...

[EagleTitan]

Dag 21 en dag 22 in Go.

Vond ze wel weer meevallen. Ben daarentegen nog steeds aan het worstelen met deel 2 van dag 20

[Hydra]

22 in Kotlin

Leuke opdracht. Vrij simpel en leverde mooie code op IMHO.

Edit: Damn, net te laat!

EagleTitan schreef op vrijdag 22 december 2017 @ 09:19:
dag 22 in Go.

Da's een hoop code...

[ Voor 39% gewijzigd door Hydra op 22-12-2017 09:21 ]

[EagleTitan]

Hydra schreef op vrijdag 22 december 2017 @ 09:20:

[...]


Da's een hoop code...

Go is best verbose inderdaad.

[Hydra]

EagleTitan schreef op vrijdag 22 december 2017 @ 09:25:
Go is best verbose inderdaad.

Ja, niks ten nadele van jou hoor, maar we hebben nogal eens discussies waarbij sommigen claimen dat Go zoveel makkelijker is dan Java. Heb er zelf redelijk veel mee gedaan (simpele REST service en wat commandline tooltjes) maar ik word eigenlijk gek van hoe omslachtig 't allemaal is. Simplistic != easy. Java is van zichzelf al erg verbose (nu ik veel in Kotlin bezig ben is het vaak best wel 'meh') maar ik zie vrijwel alleen maar AoC code in Go waarbij de Java versie gewoon minder code bevat.

[veldsla]

De kracht van verbose code, en ja Rust is ook nogal verbose, is denk ik niet het verbose zijn tijdens de initiele ontwikkeling, maar vooral het vertrouwen wat je kunt hebben tijdens het refactoren en optimaliseren. Ik doe zelf niks met Go, maar ik hoop dat het daar ook geldt. Hoe meer expliciete types des te beter de compiler kan assisteren als je in de code gaat spitten.

Rust newtypes zoals dit (uit mijn dag 22) bestaan alleen tijdens het compileren en worden helemaal weg geoptimaliseerd. Ze dragen wel bij tot de leesbaarheid en zorgen dat de type checker explicieter kan controleren.

[Hydra]

veldsla schreef op vrijdag 22 december 2017 @ 10:11:
De kracht van verbose code, en ja Rust is ook nogal verbose, is denk ik niet het verbose zijn tijdens de initiele ontwikkeling, maar vooral het vertrouwen wat je kunt hebben tijdens het refactoren en optimaliseren. Ik doe zelf niks met Go, maar ik hoop dat het daar ook geldt. Hoe meer expliciete types des te beter de compiler kan assisteren als je in de code gaat spitten.

Da's een beetje het punt. Een type-system; top. Ik ben Java dev en in AoC met Kotlin bezig en beiden zijn strongly typed. Maar Go heeft daarbovenop een hoop 'busywork' dat niks toevoegt IMHO.

Ik ben overigens wel helemaal over als het op Kotlin aankomt. M'n dagelijks werk is Java en ik vind Kotlin gewoon 100% een betere taal. Er is niks waar ik zo iets van heb dat Java beter is, en dat zegt nogal wat

[Lye]

Hydra schreef op vrijdag 22 december 2017 @ 10:38:
[...]


Da's een beetje het punt. Een type-system; top. Ik ben Java dev en in AoC met Kotlin bezig en beiden zijn strongly typed. Maar Go heeft daarbovenop een hoop 'busywork' dat niks toevoegt IMHO.

Ik ben overigens wel helemaal over als het op Kotlin aankomt. M'n dagelijks werk is Java en ik vind Kotlin gewoon 100% een betere taal. Er is niks waar ik zo iets van heb dat Java beter is, en dat zegt nogal wat

Ik ben ook Java dev waarbij ik sinds vorig jaar zoveel mogelijk overzet naar Kotlin. Is inderdaad een prachtige taal al zijn er nog wel een aantal kleine zaken die in Java net iets robuuster danwel volwassener Nou staat Kotlin nog in zijn kinderschoenen en elke update maakt het echt een stuk beter, maar simpele dingen zijn soms echt nog heel erg raar.

[Hydra]

Lye schreef op vrijdag 22 december 2017 @ 10:53:
Ik ben ook Java dev waarbij ik sinds vorig jaar zoveel mogelijk overzet naar Kotlin. Is inderdaad een prachtige taal al zijn er nog wel een aantal kleine zaken die in Java net iets robuuster danwel volwassener Nou staat Kotlin nog in zijn kinderschoenen en elke update maakt het echt een stuk beter, maar simpele dingen zijn soms echt nog heel erg raar.

Ik heb nog niet professioneel met Kotlin gewerkt. Puur uit interesse; kun je voorbeelden noemen?

[Lye]

Hydra schreef op vrijdag 22 december 2017 @ 10:58:
[...]


Ik heb nog niet professioneel met Kotlin gewerkt. Puur uit interesse; kun je voorbeelden noemen?

Type inference is niet in alle gevallen perfect. Bijvoorbeeld het volgende:

code:

charArrayOf('a', 'b', 'c').let(::String) // Werkt niet
charArrayOf('a', 'b', 'c').let { String(it) } // Gaat prima

In Java zou zo'n constructie gewoon werken, niet dat dit een veel voorkomende situatie is (normaal gesproken zou je snel terugvallen op joinToString of iets dergelijks, maar ik kwam het toevallig afgelopen week tegen.

Ook is er in Kotlin nog geen makkelijke manier om Sequences parallel uit te voeren zonder je eigen boilerplate code er omheen te gooien. Natuurlijk is ook dit geen groot probleem, maar ten opzichte van de eenvoudigheid van Java's parallelStream is het toch wel een groot gelag.

Kotlin heeft geen static variabelen, behalve via companion objects of top level variabelen, dit zijn prima oplossingen maar maken het -naar mijn mening- net iets onduidelijker. Dit geldt helemaal voor companion objects, die zowel een virtue als een vice zijn. Neem de volgende situatie:

code:

class SomeClass {
    companion object {
        const val SOME_CONSTANT = 5
    }

    fun a() = SOME_CONSTANT
}

const val SOME_CONSTANT = 3

Het is voor mij nu niet duidelijk welke constante gebruikt wordt in a(). Vanuit Java's perspectief zou de top level constante gebruikt moeten worden (immers worden deze functies/variabelen/constanten onderdeel van de class), echter blijkt de constante uit het companion object gebruikt te worden.

Het zijn van die kleine dingen, maar die zijn -wat mij betreft- toch net iets duidelijker en consistenter in Java. Maar zoals ik al zei, Kotlin staat nog in zijn kinderschoenen en elke update maakt het beter. Jetbrains zet grote stappen met de taal en het is naar mijn mening ook zeker een taal die in de toekomst meer marktaandeel inpikt van Java, wat je nu al ziet op het gebied van ontwikkeling van Android apps.

Overigens heb ook ik nog niet heel veel professioneel met Kotlin gedaan, het zijn vooral kleine projectjes. Ik ben echter wel benieuwd hoe Kotlin zich houdt in grotere projecten.

[ Voor 4% gewijzigd door Lye op 22-12-2017 11:17 ]

[Anoniem: 1004565]

part 1... Erg vaag waar je nou begon in de Grid, of dat nou op (0, 0) was, of exact in het midden...
Kwam er ook pas na veel frustratie achter dat het om een infinite Grid ging.... GRR

https://github.com/DutchG...ree/master/Rust/day22/src

[Soultaker]

Anoniem: 1004565 schreef op vrijdag 22 december 2017 @ 11:17:
part 1... Erg vaag waar je nou begon in de Grid, of dat nou op (0, 0) was, of exact in het midden...
Kwam er ook pas na veel frustratie achter dat het om een infinite Grid ging.... GRR

Dat wordt toch allebei direct duidelijk bij het eerste voorbeeld?

Volgens mij is het dit jaar voor het eerst dat er consequent voorbeeldinvoer en -uitvoer gegeven wordt. Dat kan een hoop onduidelijkheden voorkomen, mits de lezer ze niet compleet negeert

[Reynouts]

Ik moet de opdrachten ook vaak een aantal keer doorlezen. Soms denk je dat je het hebt begrepen, snap je niet waarom je uitkomst niet klopt en lees je daarna de opdracht maar nog een keer en mistte je iets.

Hier was het mij gelukkig wel meteen duidelijk. Eerste alinea noemen ze de infinite grid en later dat je in het midden van je input map begint.

Op naar de laatste dagen!

[Anoniem: 1004565]

https://github.com/DutchG...ree/master/Rust/day22/src

Heel veel duplicate code, ben er nog niet tevreden mee...maar 't werkt... straks even refactoren

[veldsla]

Zo dan maar, kleine tweak en het is weer sneller dan de Go versie 0.5s tegen 1s. Kan nog 100ms af als ik een andere hasher kies.

Ik zie dat @Anoniem: 1004565 Rust versie een stuk harder gaat (maar het verkeerde antwoord geeft? Misschien een extra newline in de input...). Ik gok dat het aan de Vec ligt ipv de hashmap. Scheelt wel flink 130ms voor jouw oplossing

De mem::replace variant is exact even snel.

Ik heb het nog even zonder newline op de laatste regel geprobeerd, maar krijg nog steeds niet het juiste antwoord. Ik heb mijn input gecommit, dus check het zelf. Voor de zekerheid hieronder het antwoord

spoiler:

5322 en 2512079

[ Voor 75% gewijzigd door veldsla op 22-12-2017 13:29 ]

[Anoniem: 1004565]

veldsla schreef op vrijdag 22 december 2017 @ 12:45:
Zo dan maar, kleine tweak en het is weer sneller dan de Go versie 0.5s tegen 1s. Kan nog 100ms af als ik een andere hasher kies.

Voor enums is het in Rust volgens mij erg snel om mem::replace te gebruiken om 'm aan te passen!
EDIT:
Fout antwoord?
wellicht ligt het aan de manier waarop ik de richting initialiseer in het begin...En in mijn input in VScode plakte VScode er idd een newline achter in eerste instantie, die moest ik nog even weghalen. (en de startpositie bij mij is 12/12...mss verschilt dat nog per persoon??)

[ Voor 30% gewijzigd door Anoniem: 1004565 op 22-12-2017 13:15 ]

[Hydra]

Anoniem: 1004565 schreef op vrijdag 22 december 2017 @ 11:17:
part 1... Erg vaag waar je nou begon in de Grid, of dat nou op (0, 0) was, of exact in het midden...
Kwam er ook pas na veel frustratie achter dat het om een infinite Grid ging.... GRR

Als AoC je iets leert, is het het goed lezen van de instructies

En waardevolle input @Lye, thanks!

[ Voor 5% gewijzigd door Hydra op 22-12-2017 13:25 ]

[veldsla]

Anoniem: 1004565 schreef op vrijdag 22 december 2017 @ 12:53:
wellicht ligt het aan de manier waarop ik de richting initialiseer in het begin...

Check. That's it

[Anoniem: 1004565]

veldsla schreef op vrijdag 22 december 2017 @ 12:45:
Zo dan maar, kleine tweak en het is weer sneller dan de Go versie 0.5s tegen 1s. Kan nog 100ms af als ik een andere hasher kies.

Ik zie dat @Anoniem: 1004565 Rust versie een stuk harder gaat (maar het verkeerde antwoord geeft? Misschien een extra newline in de input...). Ik gok dat het aan de Vec ligt ipv de hashmap. Scheelt wel flink 130ms voor jouw oplossing

De mem::replace variant is exact even snel.

Ik heb het nog even zonder newline op de laatste regel geprobeerd, maar krijg nog steeds niet het juiste antwoord. Ik heb mijn input gecommit, dus check het zelf. Voor de zekerheid hieronder het antwoord

spoiler:

5322 en 2512079

Heb mn oplossing herschreven, werkt nu ook voor jouw input zonder dat er dingen aangepast hoeven te worden! https://github.com/DutchG.../Rust/day22/src/walker.rs

[Lye]

Nou had ik vandaag al een oplossing waar ik niet blij mee was. Het duurde ongeveer 2 seconden nodig om te draaien, wat naar mijn mening veel te lang is.
Dus de boel herschreven en in plaats van een map met punten bij te houden een daadwerkelijk grid te bouwen (al gebruik ik stiekem op de achtergrond alsnog een map), dit zorgt er voor dat ik de runtime naar minder dan 700ms gaat, toch bijna 3x zo snel. Al een heel stuk blijer met deze oplossing, al is het nog niet perfect, ik wil het graag onder de 500ms houden

[Hydra]

Dag 23 in Kotlin

Niet happy mee. Deel 1 was te simpel; kopie van dag 18. Deel 2 heb ik moeten 'valsspelen' omdat ik in een compleet verkeerde denkrichting zat.

spoiler:

Als je dan leest op Reddit dat je 'gewoon' die assembly met de hand moet vertalen is het simpel,
maar eigenlijk saai.

Onbevredigend resultaat.

[ Voor 5% gewijzigd door Hydra op 23-12-2017 09:45 ]

[veldsla]

Er zijn vast mensen die het leuk vinden, maar met de hand een beetje door zo'n progsel lopen om te kijken wanneer 107900 107899 wordt is niet mijn hobby.

[Anoniem: 1004565]

Ik had nog mijn bunny-assembly code van vorig jaar...deel 1 was zo klaar...deel 2 is nog steeds aan 't rekenen ^^

https://github.com/DutchG...er/Rust/day23/src/main.rs

EDIT:

nu vooraf geen Initialisatie meer van de registers, zodra ik nu een register opvraag die nog niet in mn btreemap zit, word hij automatisch met value 0 ge-insert

[ Voor 30% gewijzigd door Anoniem: 1004565 op 23-12-2017 11:59 ]

[veldsla]

Op reddit stond iets van 10^13 operaties, dus zelfs mijn vlotte versie van vorig jaar die zo'n 180M instructies per seconde deed zou er dik 15 uur over doen.

[Peelee]

Deel 2 is nu ook niet onmiddellijk m'n meest favoriete oefening van dit jaar..
Hopelijk nog 2 mooie dagen te gaan

[Anoniem: 420461]

Deel 1 was inderdaad erg simpel - ik vertrouwde het zelfs even niet, maar het antwoord was goed, dus...

spoiler:

Deel 2 gedaan met omzetten van de assembly naar PHP-code en die steeds verder indikken tot een paar regels.

[Bee.nl]

De opdracht van vandaag vind ik maar matig. Iedereen heeft ook dezelfde input volgens mij. Deel 1 is bijna een copy paste van dag 18 en deel 2 doet me weinig.

[DRaakje]

Ik vond hem erg mooi. Ik denk dat ik 2 uur bezig ben geweest met erachter komen wat er nou aan de hand was op volledig de verkeerde manier. Uiteindelijk is de tijd om het op te lossen sneller als part 1.

hier een hint om je op weg te helpen.

Hint 1

spoiler:

Toen ik de code omzette naar c# werd het duidelijk wat het probeerde te doen.

Hint 2

spoiler:

variable g word elke keer gereset.

[ Voor 8% gewijzigd door DRaakje op 23-12-2017 20:46 ]

[The Fox NL]

Pfff, poos bezig met dag 22 deel 2. Output klopte maar niet, blijkt dat ik een copy-paste fout gemaakt had en naar rechts ging ipv omkeren

[Hydra]

Dag 24 in Kotlin

Had eerder gezegd een moeilijkere opdracht verwacht.

spoiler:

Gewoon een recursieve search door de searchspace.

[Daanoz]

Ik had inderdaad ook gedacht dat er nog wel wat optimalizaties nodig waren om sneller door de dataset te zoeken... Maar met een eerste test run op de echte dataset van 1 seconde niet echt van toepassing .

[Soultaker]

Aangezien het probleem NP-hard is kun je ook niet veel beter doen dan brute-force.

De meeste oplossingen zullen bijvoorbeeld niet werken voor een invoer die uit twintig keer 0/1 bestaat. Je kunt voor die situatie wel optimaliseren, maar dat is bij de testinvoer niet nodig (dus waarom zou je) en het maakt je algoritme niet fundamenteel sneller (het blijft exponentiële tijd kosten, in het ergste geval).

[veldsla]

Zo. was ik toch even een tijdje aan het zoeken wat ik fout had gedaan. En ja...het was dom.

[Hydra]

Soultaker schreef op zondag 24 december 2017 @ 12:52:
De meeste oplossingen zullen bijvoorbeeld niet werken voor een invoer die uit twintig keer 0/1 bestaat. Je kunt voor die situatie wel optimaliseren, maar dat is bij de testinvoer niet nodig (dus waarom zou je) en het maakt je algoritme niet fundamenteel sneller (het blijft exponentiële tijd kosten, in het ergste geval).

Ik had niet naar de 'echte' invoer gekeken en voor de test-invoer gewoon quick 'n dirty een 'geef me alle permutaties van de lijst' functie gebruikt. Dat werkt wel voor 8! (grofweg) maar niet echt voor 56!

[zerok]

EagleTitan schreef op maandag 18 december 2017 @ 15:44:
De halve dag besteed aan deel 2 omdat

spoiler:

de condition check voor de jump keek of niet 0 in plaats van groter dan 0

En dat maakte voor deel 1 geen verschil in de uitkomst, dus je merkt het ook niet

Ah thanks. Ik had hetzelfde probleem.

[Reynouts]

Deze dag was een leuke voor het zelfvertrouwen voor het sluitstuk van morgen. Ik ben benieuwd!

[Daanoz]

Done!

Zaten toch wel weer leuke puzzels bij dit jaar . Op naar volgend jaar!

spoiler:

Ik vraag me wel af waar de naughty / nice list op de home pagina op gebaseerd wordt...? Het lijkt te maken te hebben me wie de puzzels wel of niet voltooid heeft?

[ Voor 3% gewijzigd door Daanoz op 25-12-2017 09:12 ]

[Hydra]

Dag 25 in Kotlin

Erg simpel. Meeste werk zat in 't parsen van de input en het puur voor de lol zelf implementeren van de tape. Gelukkig maar; denk niet dat de fam 't leuk zou vinden als ik de hele dag bezig was

Fijne kerst iedereen!

Daanoz schreef op maandag 25 december 2017 @ 09:11:

spoiler:

Ik vraag me wel af waar de naughty / nice list op de home pagina op gebaseerd wordt...? Het lijkt te maken te hebben me wie de puzzels wel of niet voltooid heeft?

spoiler:

Donations? Gokje.

[ Voor 31% gewijzigd door Hydra op 25-12-2017 09:44 ]

[veldsla]

Dag 25 is altijd wel te doen. Eet-ze iedereen!

[Peelee]

Het zit er op, dat wordt afkicken de komende dagen..

Fijne kerst!

[Reptile209]

Hydra schreef op maandag 25 december 2017 @ 09:41:
Dag 25 in Kotlin

Erg simpel. Meeste werk zat in 't parsen van de input en het puur voor de lol zelf implementeren van de tape. Gelukkig maar; denk niet dat de fam 't leuk zou vinden als ik de hele dag bezig was

Fijne kerst iedereen!


[...]

spoiler:

Donations? Gokje.

Nope

spoiler:

/me stond namelijk in het Nice-rijtje, en heb zeker weten geen donatie gedaan . Andere optie: gebruik van een Twitter-account?

[Anoniem: 420461]

Beetje een anti-climax, maar goed. Erg leuk om te doen dit - ik ga het ook missen. Volgend jaar weer!

Reptile209 schreef op maandag 25 december 2017 @ 11:17:

spoiler:

/me stond namelijk in het Nice-rijtje, en heb zeker weten geen donatie gedaan . Andere optie: gebruik van een Twitter-account?

spoiler:

Nah...gewoon jij als nice en 9 random namen voor de andere slots

[Bee.nl]

Zo, het zit er weer op Traditiegetrouw was vandaag een simpele opdracht (php). Ik miste dit jaar wel een paar opdrachten die echt moeilijk zijn en brute-forcen niet mogelijk is. Desalniettemin was het weer erg leuk om te doen.

[ Voor 15% gewijzigd door Bee.nl op 25-12-2017 11:29 ]

[Anoniem: 1004565]

Jammer dat ik nog niet alles opgelost heb, en nu de bonus-ster niet krijg. Het valt me ook op dat ik nu niet meer bij de input van dag 25 kan, part 1 van dag 25 heb ik wel opgelost..., maar ik kom gewoon niet meer bij de input omdat 't knopje verdwenen is

Fijne kerst en gelukkig nieuwjaar allemaal!

[Anoniem: 420461]

Anoniem: 1004565 schreef op maandag 25 december 2017 @ 12:23:
Het valt me ook op dat ik nu niet meer bij de input van dag 25 kan...

http://adventofcode.com/2017/day/25/input

[Anoniem: 1004565]

Anoniem: 420461 schreef op maandag 25 december 2017 @ 12:31:
[...]

http://adventofcode.com/2017/day/25/input

yayy! hahaha, wilde mn oplossing namelijk iets beter maken dan alleen maar if's en else statements... hehehe

[ydderf]

Ik loop nog een beetje achter bij de meeste (wegens ontbreken tijd en kennis ;-)
Maar dag drie is ook opgelost met mijn beperkte python kennis.

https://github.com/ydderfBackwards/AdventOfCode2017

Ik ben alleen lang aan het klooien geweest om een twee dimensionale array te maken.

Dacht eerst dat de onderstaande code de truc deed, maar dit bleek een copy van lijsten te zijn.

code:

myArray = [[0]*Size]*Size

Daarna maar hardcoded, maar is beetje veel werk met grote array's

code:

myArray = [[0,0,0],[0,0,0],[0,0,0]]

Ook nog wat gevonden met "numpy", maar die kent Atom niet (niet verder gezocht waarom niet).

Uiteindelijk maar opgelost met:

code:

myArray = [[0 for j in range(Size)] for i in range(Size)]

Is dit de handigste manier of zijn er nog betere manieren?

[Anoniem: 420461]

Nog even gekeken, maar de eerste naughty = The Easter Bunny, eerste Nice ben ik, en daarna alleen maar willekeurige namen van de leaderboard, ongeacht het aantal sterren.

[Soultaker]

ydderf schreef op maandag 25 december 2017 @ 19:47:
Uiteindelijk maar opgelost met:

code:

myArray = [[0 for j in range(Size)] for i in range(Size)]

Is dit de handigste manier of zijn er nog betere manieren?

Zo doe ik het meestal ook. Je kunt nog kiezen voor de tussenvorm:

Python:

myArray = [[0]*Size for i in range(Size)]

Verder is in Python een dictionary vaak een goed alternatief voor een meerdimensionale array, zeker als je van te voren niet weet hoe groot je array moet worden.

Lezen en schrijven werkt dan zo:

Python:

d = dict()  # of: d = {}
d[1, 2] = 3
print(d[1, 2])  # 3

Als je de waarden wil initialiseren kan dat bijvoorbeeld zo:

Python:

d = dict(((i, j), 0) for i in range(10) for j in range(10))
print(myArray[1, 2])  # 0

Maar aangezien het hele voordeel van een dict juist is dat je de dimensies niet van te voren hoeft te bepalen, kun je beter niet initialiseren en een default-waarde gebruiken voor niet-bestaande keys. Daar zijn verschillende manieren voor:

Python:

d = dict()
print(d[1, 2] if (1, 2) in d else 0)  # 0
print(d.get((1, 2), 0))  # 0

Tenslotte kun je nog gebruikmaken van een defaultdict, wat een dictionary is die een functie meekrijgt om nieuwe waarden mee te generen. Dag 3 deel 2 kun je daarmee bijvoorbeeld zo oplossen: https://gist.github.com/m...a0e9df40fdc535#file-3b-py

[MerijnB]

Liep een beetje achter maar ben ook weer klaar voor dit jaar, het was weer leuk, alhoewel ik het gevoel heb dat het iets makkelijker was dan vorig jaar, hebben meer deelnemers dit?

[Soultaker]

Ik had sowieso het idee dat er vrij veel overlap is in het soort problemen tussen nu en vorig jaar, dus als je eerder hebt meegedaan, komt veel je bekend voor en zul je wellicht sneller een oplossing in elkaar kunnen draaien.