Advent of Code 2017

[Anoniem: 420461]

Typisch gevalletje voor PHP's list() - uiteindelijk 1/3e van de regels kwijt aan een switch statement. Kan nog compacter met een eval, maar ja...eval, he?

[Camulos]

ThaStealth schreef op vrijdag 8 december 2017 @ 10:01:

[...]

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

Dat klopt! Ik had verwacht dat part 2 zou bestaan uit meerdere operaties voor het eerste register, dus meer dan alleen inc/dec (bijv multiply/divsion).. en dan kwam de 2e swtich wel goed uit

[kenneth]

Camulos schreef op vrijdag 8 december 2017 @ 11:06:
[...]

Dat klopt! Ik had verwacht dat part 2 zou bestaan uit meerdere operaties voor het eerste register, dus meer dan alleen inc/dec (bijv multiply/divsion).. en dan kwam de 2e swtich wel goed uit

En daarom houden we er altijd rekening mee dat code gaat veranderen maar doen we geen voorspellingen over hoe die veranderingen eruit zullen zien

[ThaStealth]

Camulos schreef op vrijdag 8 december 2017 @ 11:06:
[...]

Dat klopt! Ik had verwacht dat part 2 zou bestaan uit meerdere operaties voor het eerste register, dus meer dan alleen inc/dec (bijv multiply/divsion).. en dan kwam de 2e swtich wel goed uit

Ja, deel 2 viel inderdaad wat tegen, was uiteindelijk 3 regels code toevoegen

Mijn C# oplossing

[DRaakje]

Day 8 c#

makkelijk, part 2 was door de opzet van de aparte class voor bijhouden van de registers erg makkelijk.

https://pastebin.com/aM5AmixV

[ Voor 61% gewijzigd door DRaakje op 08-12-2017 11:20 ]

[Hydra]

Ben in 2016 bij dag 2 part 2 opgehouden omdat dat een drukke periode was en ik er ff geen zin meer in had. Maar ben nu maar begonnen met 2016; leuke besteding van je vrije dag. Met je dochter en een vriendin naar Ballorig en zelf lekker aan 't puzzelen in Kotlin

[kenneth]

Nou, van mutable naar immutable. Een leuke en leerzame oefening maar:
• Volgens mij is Map trager dan Dictionary<TKey, TValue>. Dat is nu gelukkig niet te merken. Gemiddeld 5ms voor beide delen.
• De state (registers) wordt nu aan bijna alle functies meegegeven. De functies zelf zijn nu wel mooi pure maar de aanroepen worden daardoor m.i. wel wat rommeliger.

Commentaar is natuurlijk welkom

[Anoniem: 1004565]

Mijn implementatie in Rust:
https://github.com/DutchG...tree/master/Rust/day8/src

Vond het vrij overzichtelijk om er structs van te parsen,
1 voor het groter dan, kleiner dan, gelijk aan (Operator)...en een struct voor de hele statement (Statement)

[veldsla]

Dan moet er ook nog wel een struct (of een newtype) voor de registers af kunnen of niet? Is het helemaal mooi abstract.

En dit

Rust:

let part1 = map.iter().max_by_key(|&(_, n)| n).map(|(_, n)| n).unwrap();

Is gewoon

Rust:

let part1 = map.values().max().unwrap();

Maar dan lastiger

[Hydra]

Whoooo

[Anoniem: 1004565]

veldsla schreef op vrijdag 8 december 2017 @ 12:40:
Dan moet er ook nog wel een struct (of een newtype) voor de registers af kunnen of niet? Is het helemaal mooi abstract.

En dit

Rust:

let part1 = map.iter().max_by_key(|&(_, n)| n).map(|(_, n)| n).unwrap();

Is gewoon

Rust:

let part1 = map.values().max().unwrap();

Maar dan lastiger

Yupp, kwam ik ook net achter...al aangepast!!

[Edwin88]

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

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

Same story here. Dag 7 part 1 opgelost in een paar regels, maar bij part 2 heb ik al 5 x al mijn code herschreven om het netjes te maken. Ik heb nog steeds geen boom kunnen maken (had ik gelukkig niet nodig voor deel 1). Uiteindelijk ga ik er dit weekeind maar eens goed voor zitten

[Anoniem: 1004565]

veldsla schreef op vrijdag 8 december 2017 @ 12:40:
Dan moet er ook nog wel een struct (of een newtype) voor de registers af kunnen of niet? Is het helemaal mooi abstract.

En dit

Rust:

let part1 = map.iter().max_by_key(|&(_, n)| n).map(|(_, n)| n).unwrap();

Is gewoon

Rust:

let part1 = map.values().max().unwrap();

Maar dan lastiger

dus....Is dit een beetje mooi? https://github.com/DutchG...ust/day8/src/statement.rs

[veldsla]

Haha, zo blijf je bezig Misschien nog een paar FromStr implementaties om de boel nog wat verder uit elkaar te halen? Ik krijg alweer visioenen van 2016 dag 23 en 25

[Lye]

veldsla schreef op vrijdag 8 december 2017 @ 14:24:
Ik krijg alweer visioenen van 2016 dag 23 en 25

Daar hoopte ik ook op, helaas mocht het niet zo zijn... Ik vond vandaag wel erg simpel, het is letterlijk instructies parsen waarbij je 0,0 aan slimme trucjes hoeft te doen. Zoals dag 12, 23 en 25 van 2016 waar, als je niet een beetje optimaliseert je gewoon minuten lang naar je scherm aan het kijken bent..
Maar goed, op zich wel blij met mijn oplossing, helemaal immutable wat natuurlijk wel een win is.

Morgen weer weekend! Dus dan zal de moeilijkheidsgraad wel weer wat stijgen.

[kenneth]

[quote]kenneth schreef op vrijdag 8 december 2017 @ 12:24:
• De state (registers) wordt nu aan bijna alle functies meegegeven. De functies zelf zijn nu wel mooi pure maar de aanroepen worden daardoor m.i. wel wat rommeliger.
Natuurlijk de functies verplaatsen binnen de scope van processLine, dan hoeft de state niet heen en weer geschoven te worden. Kleine optimalisatie erbij en nu ben ik er wel tevreden mee! De commit.

Vanavond misschien eindelijk dag 3 doen. En hopelijk morgen een ingewikkelde uitdaging!

[vliegnerd]

Dag 8 in python, met eval() en andere evil trics.

Ik vind het uitvoeren van de instructions op deze manier wel grappig.

[Daedalus]

vliegnerd schreef op vrijdag 8 december 2017 @ 15:24:
Dag 8 in python, met eval() en andere evil trics.

Ik vind het uitvoeren van de instructions op deze manier wel grappig.

Dat kan eenvoudiger _{maar minder evil}

[ Voor 3% gewijzigd door Daedalus op 08-12-2017 16:30 ]

[Marcj]

Nou, ik ben nu weer bij Dag 8 is in Haskell wel leuk omdat je ook functies gewoon kunt bewaren.

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

[Anoniem: 1004565]

veldsla schreef op vrijdag 8 december 2017 @ 14:24:
Haha, zo blijf je bezig Misschien nog een paar FromStr implementaties om de boel nog wat verder uit elkaar te halen? Ik krijg alweer visioenen van 2016 dag 23 en 25

mmhhh FromStr voor 't uitprinten van Statements ofzo? XD lol, met debugger option waarbij de statements worden uitgeprint.... hehehe.
Wat was er vorig jaar dag 23 en 25 gebeurd? ;o Ik deed vorig jaar een beetje mee, maar toen kende ik nog geen Rust, en was mijn niveau 'n stukje lager

[Lye]

Anoniem: 1004565 schreef op vrijdag 8 december 2017 @ 19:19:
[...]


mmhhh FromStr voor 't uitprinten van Statements ofzo? XD lol, met debugger option waarbij de statements worden uitgeprint.... hehehe.
Wat was er vorig jaar dag 23 en 25 gebeurd? ;o Ik deed vorig jaar een beetje mee, maar toen kende ik nog geen Rust, en was mijn niveau 'n stukje lager

Vorig jaar was er een uitgebreidere instructieset die mateloos inefficient is, zo waren er bijvoorbeeld geen add- en mul-instructies, maar zat de input vol met constructies die het emuleerden met increment-instructies. Als je dat zo'n 250000 (uit mijn hoofd) deed werd het aardig traag enzo. Je moest dus wel optimalisaties doen anders werd het echt gewoon verschrikkelijk traag.

[veldsla]

Anoniem: 1004565 schreef op vrijdag 8 december 2017 @ 19:19:
mmhhh FromStr voor 't uitprinten van Statements ofzo?

Ik bedoelde de FromStr trait. Als je die implementeert voor een struct kan je de .parse() methode op een string gebruiken om een instance van die struct te maken.

Voor het printen heb je dan weer de Display trait

[ydderf]

Na lang pasief meekijken op dit forum ook maar eens aangemeld.
Naast het PLC programmeren en zo nu en dan een basis vb-scriptje in Excel, leek me dit wel een mooie gelegenheid om wat te leren over python. Met de opdrachten heb je toch iets meer een doel...

Dag 1 is opgelost, wel anders als de meeste oplossingen die ik gezien heb. Maar hij werkt.

spoiler:

#Read file
f = open('D:\AdventOfCode2017\Day 1\PuzzleInput.txt','r')

Values = f.read()
print("Input is: ",Values)

#Determine length
Length = len(Values)
print("Lenght is: ",Length)

#Offset for first part = 1
#Offset for second part = Half Lengt of the string
#Offset = 1
Offset = Length/2

#init total counter
TotalCount = 0
#init j
j = int(Offset-1)

#loop Input
for i in range(Length):
j +=1

if j >= Length:
j = 0

#if this number is equal to previous value
if Values[i] == Values[j]:
TotalCount+=int(Values[i])

print("Totalcount = ", TotalCount)

Ik heb nul komma nul ervaring met python, dus alle opbouwende kritiek is welkom ;-)

[vliegnerd]

ydderf schreef op vrijdag 8 december 2017 @ 19:55:

Dag 1 is opgelost, wel anders als de meeste oplossingen die ik gezien heb. Maar hij werkt.

Ik heb nul komma nul ervaring met python, dus alle opbouwende kritiek is welkom ;-)

Gefeliciteerd met het oplossen van dag 1!

Wat betreft opbouwende kritiek: Probeer

code:

for index in range(len(lijst)):

te vermijden. Python heeft daar veel makkelijker gereedschap voor. Lees "for" als "foreach": "voor elk item uit de lijst".

Als je een lijst met namen hebt krijg je zoiets:

code:

for name in names:

in plaats van

code:

for index in range(len(names)):
     name = names[i]

In dit soort puzzels maak je veel gebruik van `zip(), set()` enz. Tip Peter Norvig's oplossingen van de 2016 editie.

[Anoniem: 1004565]

veldsla schreef op vrijdag 8 december 2017 @ 19:53:
[...]


Ik bedoelde de FromStr trait. Als je die implementeert voor een struct kan je de .parse() methode op een string gebruiken om een instance van die struct te maken.

Voor het printen heb je dan weer de Display trait

Owhhh jaaa hahaha, handig :3

[Anoniem: 1004565]

Anoniem: 1004565 schreef op vrijdag 8 december 2017 @ 22:09:
[...]


Owhhh jaaa hahaha, handig :3

oh, mhh...nu heb ik wel een HashMap nodig voor het aanmaken van een Statement, en dat is natuurlijk niet toegestaan bij FromStr....

[ZieglerNichols]

Dag 9 in MATLAB. Was niet al te lastig vandaag.

[Quadro!]

Dag 9 in Haskell, ideale opdracht voor pattern matching

[ZieglerNichols]

Quadro! schreef op zaterdag 9 december 2017 @ 07:06:
Dag 9 in Haskell, ideale opdracht voor pattern matching

Dat is een stuk eleganter dan al mijn for en while loops

[Hydra]

Dag 9 in Kotlin

Leuke opdracht!

spoiler:

Had het geluk dat ik al het cleanen en het scoren afgesplitst had. Het cleanen is hoe dan ook een state-machine. Dus voor deel twee hoefde ik alleen maar een counter toe te voegen. Voor het scoren van deel 1 heb ik gewoon een recursieve score functie gemaakt die op basis van een queue van karakters de depth van de onderliggende tree optelt tot 1 score.

[ThaStealth]

Dag 9 in C#

spoiler:

Had wat moeite met alle regels goed te lezen en ze toe te passen (het ! teken had ik verkeerd geimplementeerd, waardoor de unit tests wel slaagde maar de echte input niet).
Bij deel 2 was ik vergeten de , weg te filteren....

[Daanoz]

spoiler:

Het is eerste dat ik vanochtend dacht, dat wordt oplossen met regex... Hoewel het prima werkt vraag ik me nu wel af of het de snelste weg was gezien de oplossingen hierboven... Gelukkig had ik net al @Hydra het cleanen al afgesplitst dus dat was zo geregeld.

[P.O. Box]

wat zie ik over het hoofd bij dag 8? Ik heb hem wel opgelost hoor, maar:

code:

b inc 5 if a > 1
a inc 1 if b < 5
c dec -10 if a >= 1
c inc -20 if c == 10
These instructions would be processed as follows:

Because a starts at 0, it is not greater than 1, and so b is not modified.
a is increased by 1 (to 1) because b is less than 5 (it is 0).
c is decreased by -10 (to 10) because a is now greater than or equal to 1 (it is 1).
c is increased by -20 (to -10) because c is equal to 10.

Waarom is c decreased TO 10 (regel 9)? moet dat niet to -10 zijn?
Doordat ik er vanuit ging dat c daar -10 moest zijn (ik had de aanwijzing niet zo aandachtig gelezen) dacht ik dat opdracht twee een absoluut maximum zocht. Wat ik ook logischer zou vinden, want waarom zou +10 meer geheugenruimte innemen dan -10?

Wat zie ik over het hoofd?

[ZieglerNichols]

P.O. Box schreef op zaterdag 9 december 2017 @ 10:34:
wat zie ik over het hoofd bij dag 8? Ik heb hem wel opgelost hoor, maar:

code:

b inc 5 if a > 1
a inc 1 if b < 5
c dec -10 if a >= 1
c inc -20 if c == 10
These instructions would be processed as follows:

Because a starts at 0, it is not greater than 1, and so b is not modified.
a is increased by 1 (to 1) because b is less than 5 (it is 0).
c is decreased by -10 (to 10) because a is now greater than or equal to 1 (it is 1).
c is increased by -20 (to -10) because c is equal to 10.

Waarom is c decreased TO 10 (regel 9)? moet dat niet to -10 zijn?
...

Wat zie ik over het hoofd?

c wordt gedecreased met -10, dus 0 - -10 = +10

[P.O. Box]

ZieglerNichols schreef op zaterdag 9 december 2017 @ 10:41:
[...]


c wordt gedecreased met -10, dus 0 - -10 = +10

aaaah... jezus hoe heb ik dat over het hoofd kunnen zien haha... thanks !

[Bee.nl]

Ondanks dat dag 9 er lastig uit lijkt te zien, was de oplossing eigenlijk simpel.

spoiler:

Net zoals hierboven genoemd heb ik gebruik gemaakt van regexes. Het voelt bijna als valsspelen. Gelukkig heeft php een preg_replace_callback die wel handig bleek te zijn voor deel 2. De score uitrekenen is een kwestie van door de stream lopen en bij iederen open-tag het huidige nesting level bij je score op te tellen.

[Hopscotch]

Grappig dat in veel van jullie oplossingen ook characters na een ! buiten de garbage worden genegeerd. Blijkbaar komt het niet voor, maar als ik het goed lees geldt de regel alleen binnen een garbage gedeelte.

"inside garbage, any character that comes after ! should be ignored, including <, >, and even another !"

[Anoniem: 159174]

Wat wel opvalt: het tweede deel is veel simpeler dan het eerste deel (vooral als je een half uur lang *c ipv **c over het hoofd ziet).

[Anoniem: 420461]

Ik wilde het eerst leuk recursief oplossen, maar liep direct tegen de limiet van 256 calls aan - dan maar alternatief.

Hopscotch schreef op zaterdag 9 december 2017 @ 11:47:
Blijkbaar komt het niet voor, maar als ik het goed lees geldt de regel alleen binnen een garbage gedeelte.

"Within a group, there are zero or more other things, separated by commas: either another group or garbage." - een ! kan dus alleen binnen garbage voorkomen.

[ Voor 51% gewijzigd door Anoniem: 420461 op 09-12-2017 13:18 ]

[Lye]

State machines en tail recursion, yay

Vandaag was weer leuk, niet moeilijk maar wel eventjes goed recursief nadenken.

[ Voor 32% gewijzigd door Lye op 09-12-2017 14:02 ]

[Anoniem: 1004565]

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

Vraag me af HOE 't werkt, maar voor mijn input gaf het de goede antwoorden... :3

[ Voor 35% gewijzigd door Anoniem: 1004565 op 11-12-2017 17:16 ]

[Anoniem: 420461]

Ha! Vandaag ben ik eens de eerste!

Welterusten...

[rnark]

Deel 2 is pittiger dan verwacht vandaag, de examples geven de juiste output, alleen met de puzzle input komt er niet het juiste antwoord uit. Argh!

Het lijkt ook dat niet iedereen dezelfde input krijgt. Op Reddit wordt er met andere inputs gewerkt. Mijn input is:

code:

225,171,131,2,35,5,0,13,1,246,54,97,255,98,254,110

Edit Ik weet niet wat het was, maar ineens wordt mijn antwoord wel geaccepteerd. Vreemd, maar goed. Op naar morgen!

[ Voor 53% gewijzigd door rnark op 10-12-2017 09:48 ]

[Daanoz]

Als het goed is krijgt iedereen onderling elke dag een random input, alleen die input komt uit een lijst met een x aantal verschillende inputs (bijvoorbeeld 20 verschillende). Elke input heeft een vaste uitkomst zodat de website niet elke dag eerst 1000'en antwoorden moet calculeren. Maar het zou dus heel goed kunnen dat er nog iemand is met jou input...

Vandaag was vooral een kwestie van goed lezen, en uitvoeren .

[rnark]

Daanoz schreef op zondag 10 december 2017 @ 09:55:
Als het goed is krijgt iedereen onderling elke dag een random input, alleen die input komt uit een lijst met een x aantal verschillende inputs (bijvoorbeeld 20 verschillende). Elke input heeft een vaste uitkomst zodat de website niet elke dag eerst 1000'en antwoorden moet calculeren. Maar het zou dus heel goed kunnen dat er nog iemand is met jou input...

Vandaag was vooral een kwestie van goed lezen, en uitvoeren .

Zo'n vermoeden had ik al inderdaad. Het eerste antwoord uit mijn code was ook direct het antwoord dat uiteindelijk geaccepteerd werd, ik zal wel ergens verkeerd gekopieerd en geplakt hebben. Toen ik uiteindelijk een andere oplossing probeerde met mijn input kwam daar hetzelfde uit, toen nog maar een keer (of toch de eerste keer?) geprobeerd: bingo

[ThaStealth]

Vandaag was inderdaad goed lezen, vooral deel 2 waar een flinke uitbreiding gevraagt word voor de verandering.

Hij zit bij mij ook er weer in Dag 10

[ZieglerNichols]

Dag 10 in MATLAB.

Het was me niet helemaal duidelijk of de input-file al ASCII codes waren of dat ze nog omgezet moesten worden. Uiteindelijk wel gelukt.

[veldsla]

Goed lezen....Deed ik niet.

spoiler:

add the following lengths to the end of the sequence:...

Mooie hash functie hoor zo'n knot hash . Vorig jaar zaten we flink in de md5, dus we hebben kans deze nog eens nodig te hebben!

[ Voor 23% gewijzigd door veldsla op 10-12-2017 11:41 ]

[Peelee]

Ik had eerst niet door dat

spoiler:

de komma's in deel 2 ook als ASCII in rekening gebracht moesten worden

[Soultaker]

Mja, dag 10 is niet mijn favoriete soort opgave. Het gewenste algoritme wordt in detail beschreven, en vervolgens moet je het implementeren precies zoals beschreven. Het enige detail dat je zelf mag uitwerken is hoe je een deellijst omkeert. Niet echt creatief.

Ik zie liever dat de opgave alleen het probleem omschrijft, en je de oplossing zelf mag uitdenken. (Daar leent dit soort probleem zich natuurlijk niet voor.)

[Reptile209]

Was vandaag een groot feest van: "nee, stomme l*l, let dan ook op!". Maar fijn als het dan toch gelukt is!

spoiler:

- lopen kutten met de indexen in deel 1 om ze over het einde van de array te wrappen
- vergeten om de hex-output per block te padden met een 0 als de waarde < 16 is
- alle testcases als string litteral doen het prima, maar de echte input niet... trailing \n in de input file vergeten te trimmen

[Hydra]

Mijn Kotlin oplossing

Vond deze een beetje 'meh'. Niet zo'n fan van volledig uitgespelde instructies en te veel leeswerk.

Soultaker schreef op zondag 10 december 2017 @ 12:21:
Mja, dag 10 is niet mijn favoriete soort opgave. Het gewenste algoritme wordt in detail beschreven, en vervolgens moet je het implementeren precies zoals beschreven. Het enige detail dat je zelf mag uitwerken is hoe je een deellijst omkeert. Niet echt creatief.

Ik zie liever dat de opgave alleen het probleem omschrijft, en je de oplossing zelf mag uitdenken. (Daar leent dit soort probleem zich natuurlijk niet voor.)

100% mee eens.

[ Voor 52% gewijzigd door Hydra op 10-12-2017 12:57 ]

[Anoniem: 159174]

Reptile209 schreef op zondag 10 december 2017 @ 12:23:
Was vandaag een groot feest van: "nee, stomme l*l, let dan ook op!". Maar fijn als het dan toch gelukt is!

spoiler:

- lopen kutten met de indexen in deel 1 om ze over het einde van de array te wrappen
- vergeten om de hex-output per block te padden met een 0 als de waarde < 16 is
- alle testcases als string litteral doen het prima, maar de echte input niet... trailing \n in de input file vergeten te trimmen

In mijn rijtje: -1 % LENGTH is -1, niet LENGTH - 1

[Lye]

Anoniem: 159174 schreef op zondag 10 december 2017 @ 12:57:
[...]


In mijn rijtje: -1 % LENGTH is -1, niet LENGTH - 1

Dat is afhankelijk van de manier van modulus bepalen die je taal gebruikt (divisor of dividend). Python, bijvoorbeeld, gebruikt de divisor, waarbij -1 % 10 dus gelijk is aan 9. Veel andere talen (C#, Java) gebruiken echter dividend. Vaak zijn er echter ook wel manieren om de divisor te berekenen, zo heeft Java bijvoorbeeld Math.floorMod, die de divisor berekend.

[Anoniem: 159174]

Lye schreef op zondag 10 december 2017 @ 14:30:
[...]


Dat is afhankelijk van de manier van modulus bepalen die je taal gebruikt (divisor of dividend). Python, bijvoorbeeld, gebruikt de divisor, waarbij -1 % 10 dus gelijk is aan 9. Veel andere talen (C#, Java) gebruiken echter dividend. Vaak zijn er echter ook wel manieren om de divisor te berekenen, zo heeft Java bijvoorbeeld Math.floorMod, die de divisor berekend.

Daar ben ik nu ook weer achter... En eigenlijk wist ik het ook wel, maar C was al zo'n tijd geleden. Daarom gebruik ik het nu in deze AoC (met arduinotjes aan de gang gegaan, en mijn bot bij riddles.io in C geschreven). Het is natuurlijk niet de beste taal voor de meeste problemen, je moet hashmaps etc met de hand programmeren (alhoewel deze 'opgave' dan wel weer past).

[Lye]

Anoniem: 159174 schreef op zondag 10 december 2017 @ 14:38:
[...]


Daar ben ik nu ook weer achter... En eigenlijk wist ik het ook wel, maar C was al zo'n tijd geleden. Daarom gebruik ik het nu in deze AoC (met arduinotjes aan de gang gegaan, en mijn bot bij riddles.io in C geschreven). Het is natuurlijk niet de beste taal voor de meeste problemen, je moet hashmaps etc met de hand programmeren (alhoewel deze 'opgave' dan wel weer past).

In C is het helemaal een ander verhaal omdat modulo daar implementatie afhankelijk is (Al zullen de meeste implementaties voor dividend gaan).

Maar goed, Ik sta ook weer online, vond vandaag wel tegenvallen. Al ben ik wel een tijd bezig geweest om het werkend te krijgen.

spoiler:

Ik had een functie geschreven die een list met een getal kon vermenigvuldigen (list * 2 == list + list), omdat dit vrij triviale code was heb ik het ook niet getest. Iets met assumpties, moeders en fuckups.

[Anoniem: 1004565]

Deel 1 was eigenlijk veel makkelijker dan ik de hele tijd dacht....UGH, maar..hier deel 1:

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

Deel 2 is even lezen..pfew

[Soultaker]

Anoniem: 159174 schreef op zondag 10 december 2017 @ 12:57:
In mijn rijtje: -1 % LENGTH is -1, niet LENGTH - 1

Python is de enige taal die dat wel goed doet

[Camulos]

ik vond dag 10 deel 2 ellendig.. maar vooral omdat de beschrijving voor interpretatie vatbaar is.

spoiler:

Heb letterlijk een uur gekeken waarom hij het niet deed, bleek het te zijn dat 64 ROUNDS de outerloop moest zijn met de Sequence als innerloop

Gelukkig had de code van @ThaStealth me geholpen om dat in te zien

met @Soultaker eens dat het vooral zeer goed lezen en EXACT implementeren is

[ Voor 21% gewijzigd door Camulos op 10-12-2017 17:21 ]

[Anoniem: 159174]

Soultaker schreef op zondag 10 december 2017 @ 16:29:
[...]

Python is de enige taal die dat wel goed doet

En die taal gebruik ik normaal gesproken voor dit soort puzzles.. voor python!

[Matis]

Ik ga dit jaar ook een gokje wagen.
December is bij ons op de zaak altijd een rustige maand en ik heb nog wat "eigen" uren openstaan die ik hier graag aan spendeer.

Mijn gebruikersnaam op AoC is Mathijs en mijn GitHub pagina staat hier: https://github.com/toaomatis/advent-of-code-2017
Ik ontwikkel in Kotlin, voor de fun.

[Anoniem: 1004565]

kan iemand mij vertellen wat ik verkeerd doe?
https://github.com/DutchG...ust/day10/src/p2solver.rs

Het voorbeeld met de emptry String wordt goed gehashed, het voorbeeld met de teskst "AoC 2017" wordt goed gehashed, allen het voorbeeld met de nummers niet....

[Lye]

Anoniem: 1004565 schreef op zondag 10 december 2017 @ 19:09:
kan iemand mij vertellen wat ik verkeerd doe?
https://github.com/DutchG...ust/day10/src/p2solver.rs

Het voorbeeld met de emptry String wordt goed gehashed, het voorbeeld met de teskst "AoC 2017" wordt goed gehashed, allen het voorbeeld met de nummers niet....

Ik spreek nauwelijks/geen Rust, maar het lijkt mij dat je fout gaat op regels 13 en 14. Ten eerste, je moet een lijst van 256 tekens aanpassen, niet 251. En de priemgetallen (17, 31, 73, 47, 23) moeten bij de lengtes aan, niet bij de om te draaien lijst.

[Anoniem: 1004565]

Lye schreef op zondag 10 december 2017 @ 19:29:
[...]


Ik spreek nauwelijks/geen Rust, maar het lijkt mij dat je fout gaat op regels 13 en 14. Ten eerste, je moet een lijst van 256 tekens aanpassen, niet 251. En de priemgetallen (17, 31, 73, 47, 23) moeten bij de lengtes aan, niet bij de om te draaien lijst.

En mijn nums in part2 was verkeer... 256u8 bestaat niet...

[Lye]

Anoniem: 1004565 schreef op zondag 10 december 2017 @ 19:37:
[...]


En mijn nums in part2 was verkeer... 256u8 bestaat niet...

Als ik goed begrijp dat u8 8 bits is dan klopt dat inderdaad. Van 0 tot en met 255 zijn ook 256 waarden

[Anoniem: 1004565]

Lye schreef op zondag 10 december 2017 @ 19:44:
[...]


Als ik goed begrijp dat u8 8 bits is dan klopt dat inderdaad. Van 0 tot en met 255 zijn ook 256 waarden

yup, maar Rust is exclusive range...dus 0..4 is [0, 1, 2, 3].
Nu opgelost tho!

[Anoniem: 420461]

Als het in dit tempo zo doorgaat zijn we op 25 december nog met zijn 3tjes of zo: http://adventofcode.com/2017/stats

[kenneth]

Weekend -> veel tijd -> moeilijke puzzels.

Alleen zijn onze weekenden in december allemaal heksenketels Snel aan de slag met dag 9, kijken hoeveel zin ik er nog in heb ...

[Daanoz]

Anoniem: 420461 schreef op zondag 10 december 2017 @ 20:40:
Als het in dit tempo zo doorgaat zijn we op 25 december nog met zijn 3tjes of zo: http://adventofcode.com/2017/stats

Zo ging het vorig jaar en het jaar daarvoor ook... Ik gok dat het gross met veel enthousiasme begint, maar het daarna te moeilijk of niet leuk genoeg vindt... Na de eerste helft stabiliseert het zich wel.

[Lye]

Daanoz schreef op zondag 10 december 2017 @ 21:53:
[...]


Zo ging het vorig jaar en het jaar daarvoor ook... Ik gok dat het gross met veel enthousiasme begint, maar het daarna te moeilijk of niet leuk genoeg vindt... Na de eerste 2 weken stabiliseert het zich wel.

Dat leek mij ook al, echter vergeleken met afgelopen jaar/jaren vind ik het tot nu toe nog wel vrij simpel allemaal. Op dag 3 en 7, die heel iets lastiger waren, waren ze toch vrijwel allemaal zo op te lossen. Ik mis de puzzels en de opdrachten die zonder optimalisatie/slimme dingetjes minuten lang duren!

[Daanoz]

Ja, dat is waar... Ik weet nog wel een puzzel met het traveling salesmen probleem in 2015... Stond m'n pc'tje toch wel 36 mins op te ratelen

[Lye]

Daanoz schreef op zondag 10 december 2017 @ 22:16:
Ja, dat is waar... Ik weet nog wel een puzzel met het traveling salesmen probleem in 2015... Stond m'n pc'tje toch wel 36 mins op te ratelen

Precies mijn punt:

Advent Of Code 2015
Started on 2017-12-10 22:27:51
Running assignments: Day09
Day09
First:
    Output: 141
    Time taken: 77.30226ms
Second:
    Output: 736
    Time taken: 72.41706ms

Total time taken: 00:00:00.086s

Beide opdrachten draaien op hun eigen thread, voor de makkelijk enzo

[farlane]

Pff Day 8 nu, elke dag in een andere taal : Javascript, Python, Java, Kotlin, C, C++, Rust en nu Go.

Ik ben bang dat ik dat niet ga volhouden

Ik mis de puzzels en de opdrachten die zonder optimalisatie/slimme dingetjes minuten lang duren!

Die gaan later nog wel komen

[ Voor 34% gewijzigd door farlane op 10-12-2017 23:32 ]

[Down]

Dag 8 in C#

Lekker ranzig . Nooit geweten dat DataTables zo nuttig konden zijn..

[Daanoz]

Lye schreef op zondag 10 december 2017 @ 22:29:
[...]

Total time taken: 00:00:00.086s

Hmm, inderdaad. Day 9 is vrijwel instant, mogelijk dat het dan day 22 was, die komt er op mijn telefoon in ieder geval niet binnen een minuut uit..

[Anoniem: 1004565]

N cleanup van day 10 in Rust
https://github.com/DutchG...er/Rust/day10/src/main.rs

waarom usize? zo hoef ik bijna niet te wisselen tussen integertypes...alleen voor t omzetten van u8 naar usize nu...en een index is in usize, de functie .take() wil n usize...

[Quadro!]

Dag 11 in Haskell.

Weer wat geleerd vandaag! Had nog nooit iets met hexagonale grids gedaan, dus moest even wat research doen om hier een nette oplossing voor te vinden. Met die kennis eenmaal in het achterhoofd was de oplossing echter super simpel.

[EagleTitan]

Dat ziet er een stuk netter uit dan mijn oplossing

[Quadro!]

EagleTitan schreef op maandag 11 december 2017 @ 08:55:
Dat ziet er een stuk netter uit dan mijn oplossing

Wel origineel!

spoiler:

Mijn oplossing is gebaseerd op een 3D-coordinaten stelsel. Voordeel is dat daardoor alle standaard functies die we kennen om bijv. afstand te bereken gewoon werken.

[ Voor 6% gewijzigd door Quadro! op 11-12-2017 10:03 ]

[MerijnB]

Ik was van het weekend een beetje druk, dus moet dag 10 nog afmaken; ik snap alleen de omschrijving van deel 2 niet helemaal:

Second, instead of merely running one round like you did above, run a total of 64 rounds, using the same length sequence in each round. The current position and skip size should be preserved between rounds. For example, if the previous example was your first round, you would start your second round with the same length sequence (3, 4, 1, 5, 17, 31, 73, 47, 23, now assuming they came from ASCII codes and include the suffix), but start with the previous round's current position (4) and skip size (4).

Die 17, 31, 73, 47, 23 zijn duidelijk de priemgetallen die je moet toevoegen, maar uit welk "previous example" komen die 3, 4, 1, 5 die ervoor staan?

[EagleTitan]

MerijnB schreef op maandag 11 december 2017 @ 09:21:
Ik was van het weekend een beetje druk, dus moet dag 10 nog afmaken; ik snap alleen de omschrijving van deel 2 niet helemaal:


[...]


Die 17, 31, 73, 47, 23 zijn duidelijk de priemgetallen die je moet toevoegen, maar uit welk "previous example" komen die 3, 4, 1, 5 die ervoor staan?

Dat zijn de lengths uit de eerste example

[MerijnB]

EagleTitan schreef op maandag 11 december 2017 @ 09:25:
[...]


Dat zijn de lengths uit de eerste example

oh.. duh... tx

Toch nog een vraag hierover:

but start with the previous round's current position (4) and skip size (4).

positie 4 en skipsize 4 is inderdaad het geval als je uitgaat van input 3, 4, 1, 5, maar niet als je uitgaat van deze input plus de verplichte priemgetallen, wat mis ik hier?

[ Voor 46% gewijzigd door MerijnB op 11-12-2017 09:49 ]

[Hydra]

Leek aanvankelijk moeilijker dan het uiteindelijk was!

Dag 11, Kotlin

[Lye]

Dag 11, ook Kotlin

spoiler:

Ik was begonnen met een "odd-q" vertical layout, echter bleek dit niet zo handig te zijn, deze manier is niet bepaald triviaal als het gaat om afstanden. Vervolgens heb ik de x-as in een hoek van 60 graden op de y-as gezet (axial coordinates), het is dan een heel stuk makkelijker om de afstand te berekenen. Zodra ik dit systeem op gang had was deel twee natuurlijk weer een eitje.

[ Voor 8% gewijzigd door Lye op 11-12-2017 10:36 ]

[ThaStealth]

Dag 11 in C# in slechts 30 27 25 regels
Was niet zo heel lastig, maar het niveau is wel een tandje hoger dan vorige week merk ik.

spoiler:

naar boven en naar beneden gaan is -1 resp 1 bij het Y coördinaat, links en rechts is ook -1 resp 1 bij X coördinaat, en -0.5 of +0.5 bij het Y coördinaat. Daarna is het simpelweg tellen hoeveel X (en halve Y) stappen nodig zijn om terug te komen boven of onder het startpunt + het restant van Y stappen erbij te tellen.

[ Voor 52% gewijzigd door ThaStealth op 11-12-2017 12:45 ]

[Anoniem: 159174]

Typische opdracht om eerst na te denken en dan pas code te kloppen. Ik had gedacht dat de tweede opdracht een stuk lastiger zou zijn dan de eerste, maar dat is weer niet zo.

[Hydra]

Lye schreef op maandag 11 december 2017 @ 10:30:
Dag 11, ook Kotlin

Netjes!

spoiler:

Slim om gewoon de input te uppercasen. Die map van mij is helemaal niet nodig.

[veldsla]

Anoniem: 1004565 schreef op maandag 11 december 2017 @ 00:17:
N cleanup van day 10 in Rust
https://github.com/DutchG...er/Rust/day10/src/main.rs

waarom usize? zo hoef ik bijna niet te wisselen tussen integertypes...alleen voor t omzetten van u8 naar usize nu...en een index is in usize, de functie .take() wil n usize...

Tijdens het schrijven deed ik dit ook. Voor het publiceren toch maar een u8 genomen. Probeer, als je de code sneller wilt maken, het aantal allocaties tot een minimum te beperken. In de inner loop die 64*16 keer wordt gecalled maakt je meerdere nieuwe vectoren die je vervolgens weer consumeert.

Ter vergelijking een knot_hash (mijn input) met 64 iteraties duurt bij jou 1.44s. Bij mij 2.5ms (580x sneller).

[Lye]

Hydra schreef op maandag 11 december 2017 @ 12:13:
[...]


Netjes!

spoiler:

Slim om gewoon de input te uppercasen. Die map van mij is helemaal niet nodig.

spoiler:

Ik heb zitten denken over een soortgelijke oplossing als de jouwe, echter zit hier de bottleneck totaal niet dus vond deze oplossing net iets netter. Als het een groter verschil had gemaakt had ik dit alsnog anders opgelost denk ik.

[Matis]

Hydra schreef op zondag 3 december 2017 @ 12:12:
Dag 3 in Kotlin

Helaas geen tijd om te refactoren (vanwege sinterklaas); heb voor deel 2 een totaal andere richting gebruikt dan in deel 1.

Ik ben nu ook bezig met Dag 3 in Kotlin. Het eerste deel hebben we wel hetzelfde gedaan. Het tweede deel had ik wel een idee van, maar dat leek me zo complex. Ik was benieuwd naar jouw oplossing. Die is helaas hetzelfde als mijn complexe oplossing voor het tweede deel

[Hopscotch]

Lye schreef op maandag 11 december 2017 @ 10:30:
Dag 11, ook Kotlin

spoiler:

Ik was begonnen met een "odd-q" vertical layout, echter bleek dit niet zo handig te zijn, deze manier is niet bepaald triviaal als het gaat om afstanden. Vervolgens heb ik de x-as in een hoek van 60 graden op de y-as gezet (axial coordinates), het is dan een heel stuk makkelijker om de afstand te berekenen. Zodra ik dit systeem op gang had was deel twee natuurlijk weer een eitje.

spoiler:

Het verleggen van de x-as is inderdaad een goede truc, ik heb allemaal lelijke checks in mijn code om te zien of we op een even of oneven rij zijn.

[vliegnerd]

Ik vond de tussen spoiler tags gelinkte site (klik = spoiler) ook al via Google.

Ik heb toch een eigen oplossing (jupyter notebook, met schets van coordinaten stelsel) bedacht denk ik, want ik zie mijn uiteindelijke oplossing er niet tussen.

spoiler:

Maar het idee voor een extra as (z-coordinaat) heb ik dan toch echt gejat van bovenstaande site

Mijn afstand bereken gaat dan heel simpel. Het lijkt algemeen geldig. Of heb ik geluk?

[Anoniem: 1004565]

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

Vraag me af HOE 't werkt, maar voor mijn input gaf het de goede antwoorden... :3

[Anoniem: 49090]

ThaStealth schreef op maandag 11 december 2017 @ 10:59:
Dag 11 in C# in slechts 30 27 25 regels
Was niet zo heel lastig, maar het niveau is wel een tandje hoger dan vorige week merk ik.

spoiler:

naar boven en naar beneden gaan is -1 resp 1 bij het Y coördinaat, links en rechts is ook -1 resp 1 bij X coördinaat, en -0.5 of +0.5 bij het Y coördinaat. Daarna is het simpelweg tellen hoeveel X (en halve Y) stappen nodig zijn om terug te komen boven of onder het startpunt + het restant van Y stappen erbij te tellen.

Thanks eerst vast en op jouw manier opgelost, maar nu toch iets anders aangepakt.

spoiler:

Je kunt de lijnen diagonaal ook zien als een 2d grid, waarbij je alleen met de waarde 1 hoeft te werken. bv Omhoog diagonaal is dan 1 bij de x
https://codeshare.io/5z76Jr

[Camulos]

@vliegnerd THNX! de tip van die blog was een lifesaver! maar vooral erg leerzaam.

spoiler:

https://www.redblobgames.com/grids/hexagons/

Zat erg te hannessen met om via de 3-assen te werken, dit maakte het in 1 keer duidelijk.

Oplossing Dag11 in C#

[Bee.nl]

ThaStealth schreef op maandag 11 december 2017 @ 10:59:
Dag 11 in C# in slechts 30 27 25 regels
Was niet zo heel lastig, maar het niveau is wel een tandje hoger dan vorige week merk ik.

spoiler:

naar boven en naar beneden gaan is -1 resp 1 bij het Y coördinaat, links en rechts is ook -1 resp 1 bij X coördinaat, en -0.5 of +0.5 bij het Y coördinaat. Daarna is het simpelweg tellen hoeveel X (en halve Y) stappen nodig zijn om terug te komen boven of onder het startpunt + het restant van Y stappen erbij te tellen.

Grappig, zo had ik het ook ongeveer gedaan. Echter heb ik

spoiler:

ook met halve stappen gewerkt op de x-as. Dus NE is y+=0.5 en x+=0.5. Dan hoef ik slechts abs(y) + abs(x) te doen en klaar.

[Anoniem: 1004565]

veldsla schreef op maandag 11 december 2017 @ 12:59:
[...]


Tijdens het schrijven deed ik dit ook. Voor het publiceren toch maar een u8 genomen. Probeer, als je de code sneller wilt maken, het aantal allocaties tot een minimum te beperken. In de inner loop die 64*16 keer wordt gecalled maakt je meerdere nieuwe vectoren die je vervolgens weer consumeert.

Ter vergelijking een knot_hash (mijn input) met 64 iteraties duurt bij jou 1.44s. Bij mij 2.5ms (580x sneller).

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

Nu heeft de functie solve() volgens maar maar 1 vector nodig waar de 'geselecteerde' nummers, en die vector wordt continu hergebruikt!

[Hydra]

Dag 12 in Kotlin

Beetje overengineered. Deel 2 was veel simpeler dan ik verwacht had.

[veldsla]

Anoniem: 1004565 schreef op maandag 11 december 2017 @ 22:55:
Nu heeft de functie solve() volgens maar maar 1 vector nodig waar de 'geselecteerde' nummers, en die vector wordt continu hergebruikt!

Helpt zeker! zit nu op zo'n 3.5ms.

Day 12 vond ik weer tijd voor een eenvoudig perl scriptje!

[Lye]

Mijn dag 12 Kotlin oplossing.

Ik ben nog niet blij met mijn oplossing, wat een beuncode.