Advent of Code 2019

[BernardV]

Leuke dag vandaag!

Ben redelijk tevreden over de snelheid, Part 2, test-input-2 draait in ongeveer 70ms (mijn persoonlijke input draait sneller dan test-input-2):

code:

time php p2.php
Max: 18216
With phase: 9,7,8,5,6

real    0m0.068s
user    0m0.055s
sys     0m0.010s

[ Voor 11% gewijzigd door BernardV op 07-12-2019 11:00 ]

[armageddon_2k1]

Zo, even wat ingehaald. De IntCode Computer moeten verbeteren vanwege de Modes natuurlijk. En nu zit ik met de thrusters part 2, want ik heb natuurlijk geen rekening gehouden met het feit dat m'n IntCode computer moet kunnen wachten tot ie een input heeft in plaats van een array met inputs meegeven en een array voor de output.

[BernardV]

armageddon_2k1 schreef op zaterdag 7 december 2019 @ 11:47:
... want ik heb natuurlijk geen rekening gehouden met het feit dat m'n IntCode computer moet kunnen wachten tot ie een input heeft in plaats van een array met inputs meegeven en een array voor de output.

Dat had ik ook niet, maar viel me mee hoe snel het toch om te zetten was.

spoiler:

Ik heb er een CodeInterpreter class van gemaakt en als je er dus meerdere hebt die single threaded draaien wachten ze keurig als je een functie in een andere aanroept tot deze klaar is.

[P_Tingen]

Damn, ik heb te lang met die van 5 dec gedaan en moest deel twee daar nog van doen. Nu moet ik wel natuurlijk omdat mijn IntCode computer niet compleet is

[JeroenTheStig]

P_Tingen schreef op zaterdag 7 december 2019 @ 12:36:
Damn, ik heb te lang met die van 5 dec gedaan en moest deel twee daar nog van doen. Nu moet ik wel natuurlijk omdat mijn IntCode computer niet compleet is

Ik had die van 5 december ook nog niet gedaan, ben er nu nog mee aan het sleutelen. Het wordt wel een ingenieus systeem zo langzamerhand

[Gropah]

Opzich vind ik die Intcode machine wel leuk, maar vind het ergens toch niet helemaal eerlijk/leuk. Ik zit ook in een leaderboard met mensen die wat minder goed kunnen programmeren en die lopen er nu toch tegen aan dat hun oplossingen van de vorige keren niet goed genoeg zijn, of ze nog niet af hadden, waardoor ze weer veel tijd moeten steken in het verbeteren/oplossen daarvan in plaats van zich te kunnen focussen op een nieuwe puzzel.

[JeroenTheStig]

Gropah schreef op zaterdag 7 december 2019 @ 13:57:
Opzich vind ik die Intcode machine wel leuk, maar vind het ergens toch niet helemaal eerlijk/leuk. Ik zit ook in een leaderboard met mensen die wat minder goed kunnen programmeren en die lopen er nu toch tegen aan dat hun oplossingen van de vorige keren niet goed genoeg zijn, of ze nog niet af hadden, waardoor ze weer veel tijd moeten steken in het verbeteren/oplossen daarvan in plaats van zich te kunnen focussen op een nieuwe puzzel.

Daar ben ik het wel mee eens. Ik heb nog even wat rondgekeken bij oplossingen van andere deelnemers (met name dag 2, de eerste intcode machine opdracht) en had toen wel het idee dat ik mijn oplossingen erg aan het over-engineeren ben, want ik zag voornamelijk oplossingen met een hoop loopjes, cases en ifjes in een relatief kort stukje code gepropt. Ik kan me voorstellen dat die nu tegen beperkingen aan gaan lopen en eigenlijk weer opnieuw kunnen beginnen.

[veldsla]

Ik vind die Intcode machine vooral briljant verzonnen.

Ben er redelijk goed uitgekomen, door blocking in- en out channels te gebruiken en de async tools van Julia in te zetten. Had wel wat timing problemen die soms voor vreemde antwoorden zorgden wat ik nog niet helemaal snap. Ik had in ieder geval niet verwacht dat ik deze materie zou tegenkomen in dit oefenprojectje, dus dat is dan wel weer leuk.

[BernardV]

Ik heb de IntCode machine heel simpel gehouden, een loop en een switch in die loop voor alle dagen tot Dag 7 part 2, toen heb ik het iets om moeten schrijven, maar niet heel anders.

//EDIT: Voor degene die Dag 5 deel 2 wil zien zoals ik het heb: https://pastebin.com/Ze11CPRw
Deze was dus met een paar aanpassingen wel relatief makkelijk om te zetten naar Dag 7 deel 2

[ Voor 34% gewijzigd door BernardV op 07-12-2019 15:01 ]

[MerijnB]

Gropah schreef op zaterdag 7 december 2019 @ 13:57:
Opzich vind ik die Intcode machine wel leuk, maar vind het ergens toch niet helemaal eerlijk/leuk. Ik zit ook in een leaderboard met mensen die wat minder goed kunnen programmeren en die lopen er nu toch tegen aan dat hun oplossingen van de vorige keren niet goed genoeg zijn, of ze nog niet af hadden, waardoor ze weer veel tijd moeten steken in het verbeteren/oplossen daarvan in plaats van zich te kunnen focussen op een nieuwe puzzel.

Kan ik me niet helemaal in vinden. Gezien de moeilijkheidsgraad oploopt is het niet vreemd dat iemand die moeite had met dag 2 meer moeite heeft met dag 7. Daarbij geeft het terugkomen van een eerder geschreven stuk code inzicht in wat je de eerste keer niet handig hebt gedaan waardoor je nu laster erop door kunt gaan, wat imho een zeer belangrijke skill is bij het schrijven van software.

[CMG]

Ik heb heel lang over see 2 gedaan omdat ik gewoon niet begreep wat de bedoeling was; eer dat ik door had dat je de eerste ronde er niet meer bij hoefde te doen (en zo die eindstation als beginstadium voor deel 2 gebruiken, niet nodig was), ieder wel een eigen State die behouden werd, maar moest runnen totdat je geen input meer had, was ik 5 uur verder (met wat pauzes), het echte aanpassen/programmeren toen ik door had wat er precies moest gebeuren, was weer ik 3 minuten klaar...

[P_Tingen]

@CMG Dat is wel een beetje ook mijn probleem, ik vind de puzzeltjes leuk, maar de láp-pen tekst vind ik soms wat teveel van het goede, zeker omdat er soms echt wel kleine gotcha's in die tekst zitten die bepalend zijn voor de puzzel. Of juist zinnen die je op het verkeerde been zetten omdat je ze verkeerd interpreteert. Mijn Engels is aardig goed, maar het is niet mijn eerste taal, dus sta ik op 'achterstand' bij diegene voor wie dat wel geldt.

Overigens heb ik ook wel een beetje mixed feelings bij de IntCode computer. Aan de ene kant is het leuk om hem steeds verder uit te bouwen, maar als je in een eerdere dag vast bent komen te zitten, kun je niet verder. Aan de andere kant: er zijn genoeg oplossingen te vinden op GitHub, dus als je er niet uitkomt kun je altijd je eigen code weggooien en die van GitHub adopteren.

[ Voor 29% gewijzigd door P_Tingen op 07-12-2019 16:53 ]

[Daos]

diabolofan schreef op dinsdag 3 december 2019 @ 21:39:

spoiler:

Ik zat er in mijn hoofd mee dat ik een x, y en een object wilde opslaan, wat dus niet lukte in een dictionary/map. Nu als key van de dictionary een string gedaan, waarbij de key dan dus is "x_y", en dan gaat het inderdaad stukje sneller. Nu op 190 ms, nog steeds niet heel goed..

Tegenwoordig zitten er tuples in C#. Je kan zoiets doen (waar Abc type van je value is) :

C#:

var values = new Dictionary<(int x, int y), Abc>();

values[(5, 3)] = new Abc(); 

Vroeger kon je (kan nog steeds) dit ook oplossen door een eigen klasse te maken die de IEquatable<T> interface implementeerd. Je moet dan je eigen GetHashCode en Equals maken. Als je die hebt, dan kan je die klasse als key gebruiken.

[CMG]

P_Tingen schreef op zaterdag 7 december 2019 @ 16:52:
@CMG Dat is wel een beetje ook mijn probleem, ik vind de puzzeltjes leuk, maar de láp-pen tekst vind ik soms wat teveel van het goede, zeker omdat er soms echt wel kleine gotcha's in die tekst zitten die bepalend zijn voor de puzzel. Of juist zinnen die je op het verkeerde been zetten omdat je ze verkeerd interpreteert. Mijn Engels is aardig goed, maar het is niet mijn eerste taal, dus sta ik op 'achterstand' bij diegene voor wie dat wel geldt.

Overigens heb ik ook wel een beetje mixed feelings bij de IntCode computer. Aan de ene kant is het leuk om hem steeds verder uit te bouwen, maar als je in een eerdere dag vast bent komen te zitten, kun je niet verder. Aan de andere kant: er zijn genoeg oplossingen te vinden op GitHub, dus als je er niet uitkomt kun je altijd je eigen code weggooien en die van GitHub adopteren.

Ja, dat laatste kan ik niet, ik moet het zelf doen, of niet, weet niet of dat eergevoel is of iets anders, maar ik moet en zal het allemaal zelf fixen, zelfs als ik er, zoals vandaag, 5 uur over doe (zaten lange pauzes tussen).

[P_Tingen]

CMG schreef op zaterdag 7 december 2019 @ 17:49:
[...]
Ja, dat laatste kan ik niet, ik moet het zelf doen, of niet, weet niet of dat eergevoel is of iets anders, maar ik moet en zal het allemaal zelf fixen, zelfs als ik er, zoals vandaag, 5 uur over doe (zaten lange pauzes tussen).

Dat lijkt me dan wel weer problematisch wanneer je als software ontwikkelaar in een team terecht komt, of is dat vooral met dit soort hobbywerk ?

[WoLFjuh]

Ik ben ook de t.net leaderboard gejoined! Tof dat er zo veel mensen mee doen.

Happy coding!

Joffrey

[CMG]

P_Tingen schreef op zaterdag 7 december 2019 @ 19:31:
[...]

Dat lijkt me dan wel weer problematisch wanneer je als software ontwikkelaar in een team terecht komt, of is dat vooral met dit soort hobbywerk ?

In dit geval, het is een challenge. Werken in een team gaat prima (al werk ik voornamelijk zelfstandig dit jaar sinds ik gestopt ben als CTO en alleen nog maar mijn eigen klanten bedien.)

[Gropah]

P_Tingen schreef op zaterdag 7 december 2019 @ 16:52:
@CMG Dat is wel een beetje ook mijn probleem, ik vind de puzzeltjes leuk, maar de láp-pen tekst vind ik soms wat teveel van het goede, zeker omdat er soms echt wel kleine gotcha's in die tekst zitten die bepalend zijn voor de puzzel. Of juist zinnen die je op het verkeerde been zetten omdat je ze verkeerd interpreteert. Mijn Engels is aardig goed, maar het is niet mijn eerste taal, dus sta ik op 'achterstand' bij diegene voor wie dat wel geldt.

Je bent niet de enige. Vandaag had ik ook problemen om bijvoorbeeld voor deel 2 te weten wanneer te stoppen en er waren ppl genoeg op de subreddit die er ook problemen mee hadden.

[DataGhost]

Gropah schreef op zaterdag 7 december 2019 @ 20:04:
[...]


Je bent niet de enige. Vandaag had ik ook problemen om bijvoorbeeld voor deel 2 te weten wanneer te stoppen en er waren ppl genoeg op de subreddit die er ook problemen mee hadden.

Je moet stoppen bij 99 maar er zijn natuurlijk veel verschillende aanpakken. Ik liet m'n machine gewoon steeds halten na een output en gaf die door als input aan de volgende machine, die ik dan weer liet resumen. Geen gehannes met threads etc, en op het moment dat een van de machines klaar is, pak je gewoon de laatste output van de laatste machine. Ik was in 20 minuutjes klaar met coden omdat m'n eerdere opzet heel makkelijk aan te passen was (en bijna geen aanpassingen hoefde).

[ Voor 9% gewijzigd door DataGhost op 07-12-2019 20:27 ]

[armageddon_2k1]

Ah, you gotta love TDD. Voor 7.1 mn IntComputer al omgeschreven naar een volledige class, en voor 7.2 sates ingebouwd zoals Idle, Waiting, Halted, Error. In 1x door mn tests heen en in 1x het goede antwoord.

Vind het wel erg leuk, heb nog nooit eerder AoC gedaan. Niveau valt me ook nog mee tot nu toe. Project Euler is vaak veel fundamenteler en ga je nat op execution times en overflows.

spoiler:

Voor 7.2 is threads echt zware overkill. Simpele manier van eventhandlers/observables/etc werkte perfect. De IntComputer heeft een input stack en als ie bij de INPUT opcode komt en er staat niks op de stack gaat ie gewoon in Wait. De methode waarmee je weer iets op de stack gooit heeft een boolean “autoresume” welke checkt of ie op Wait staat en dan gaat. Je kan dan gewoon outputhandlers toevoegen aan een IntComputer welke de output doorpleuren naar de input methode van een ander,

[ Voor 39% gewijzigd door armageddon_2k1 op 07-12-2019 21:07 ]

[Daanoz]

DataGhost schreef op zaterdag 7 december 2019 @ 20:26:
[...]

Je moet stoppen bij 99 maar er zijn natuurlijk veel verschillende aanpakken. Ik liet m'n machine gewoon steeds halten na een output en gaf die door als input aan de volgende machine, die ik dan weer liet resumen.

Dat was inderdaad ook mijn tactiek, gewoon de executie cycle "pauzeren" zodra de output opCode voorbij komt. Had niet verwacht dat het goed zou werken, gezien een van de puzzels van vorig jaar waar ook meerdere "machines" input en outputs aan elkaar moesten doorgeven, waar dit niet echt lekker werkte... Mogelijk komt dat nog in de komende 18 dagen

[JeroenTheStig]

Ik probeer te begrijpen wat het idee van day 7 part 2 is, maar dat lukt nog niet. Als ik het goed begrijp moet de output van amplifier 5 teruggekoppeld worden naar amplifier 1 als tweede inputvariabele. De eerste inputvariabele is een waarde tussen 5 en 9 (de phase setting).

Maar als ik de voorbeelden bekijk dan zie ik het volgende:

code:

Max thruster signal 139629729 (from phase setting sequence 9,8,7,6,5):

3,26,1001,26,-4,26,3,27,1002,27,2,27,1,27,26,
27,4,27,1001,28,-1,28,1005,28,6,99,0,0,5

Maar wat was dan de phase setting van de eerste iteratie? En hoeveel iteraties zijn er in totaal? Kan iemand mij wat hints geven, puur hoe dit functioneel moet werken?

[Gropah]

JeroenTheStig schreef op zaterdag 7 december 2019 @ 22:13:
Ik probeer te begrijpen wat het idee van day 7 part 2 is, maar dat lukt nog niet. Als ik het goed begrijp moet de output van amplifier 5 teruggekoppeld worden naar amplifier 1 als tweede inputvariabele. De eerste inputvariabele is een waarde tussen 5 en 9 (de phase setting).

Maar als ik de voorbeelden bekijk dan zie ik het volgende:

code:

Max thruster signal 139629729 (from phase setting sequence 9,8,7,6,5):

3,26,1001,26,-4,26,3,27,1002,27,2,27,1,27,26,
27,4,27,1001,28,-1,28,1005,28,6,99,0,0,5

Maar wat was dan de phase setting van de eerste iteratie? En hoeveel iteraties zijn er in totaal? Kan iemand mij wat hints geven, puur hoe dit functioneel moet werken?

De phase setting staat op de eerste regel (9,8,7,6,5) en die hoef je maar 1 keer te geven. Word een machine hergebruikt, dan hergebruikt hij ook zijn phase setting. De machine stopt wanneer E bij halt komt.

[Daanoz]

De clue zit hem hier:

Provide each amplifier its phase setting at its first input instruction; all further input/output instructions are for signals.

spoiler:

m.a.w. creëer de 5 processors, en geef ze allemaal als eerste input de phasesetting, daarna alleen de output van de vorige processor

[Beneveerg]

Dank alleen die mij hebben geholpen met Dag 2, deel 2. Mijn originele gedachte was, elke mogelijke optie laten proberen. Dat leek mij niet de juiste insteek, maar dus wel.

Hoe ik het ook echt uitvoerbaar kreeg duurde even.

DataGhost schreef op woensdag 4 december 2019 @ 11:34:
[...]

Een inverse. Maar daar is niet zomaar een algemene oplossing voor die je kan Googlen, dus zal je het zelf moeten programmeren. Het is ook niet gezegd dat dat zomaar mogelijk is, aangezien code en data door elkaar lopen, en writable zijn
Ik wil niet direct te veel hints geven omdat dan de oplossing snel duidelijk is Maar bedenk je dat de eerste paar dagen redelijk makkelijk zijn.

@MerijnB hieronder: dat is dus "te veel hints" IMO.

MerijnB schreef op woensdag 4 december 2019 @ 11:43:
[...]


Als je alle mogelijke inputs probeert om te kijken welke matched?

@DataGhost tja, ik snap je, maar ik vond jou omschrijving een beetje cryptisch In ieder geval (zoals je al zei) zijn de problemen op dit moment nog zo simpel dat het niet veel uitmaakt (je kunt het nu nog oplossen met brute force).

[JeroenTheStig]

Daanoz schreef op zaterdag 7 december 2019 @ 22:18:
De clue zit hem hier:

[...]

spoiler:

m.a.w. creëer de 5 processors, en geef ze allemaal als eerste input de phasesetting, daarna alleen de output van de vorige processor

Oke, en het moment waarop het proces stopt is als amplifier nr 5 een code 99 verwerkt? Dan heb ik denk ik gemist dat iedere output anders dan nul welke niet direct opgevolgd wordt door een code 99 niet langer als een 'diagnostic error' moet worden beschouwd.

[CMG]

Volgens mij was vandaag een van de makkelijkste dit jaar.

Kleine tip: als je de afbeelding rendert, laat dan de 'witte' pixels oplichten en niet de zwarte, dat maakt de tekst beter leesbaar op het eind

[edit] autocorrect typo

[ Voor 6% gewijzigd door CMG op 08-12-2019 09:04 ]

[P_Tingen]

CMG schreef op zondag 8 december 2019 @ 08:36:
Volgens mij was vandaag een van de makkelijkste dit jaar.

Kleine tip: als je de afbeelding rendert, laat dan de 'witte' pixels oplichten en niet de zwarte, dat maakt de tekst beter leesbaar op het eind

[edit] autocorrect typo

Goeie tip. Tip van mij: dubbelcheck even welke pixels de witte zijn en welke de zwarte. Als je de verkeerde kiest, zit je met een plaatje waar je geen kaas van kan maken
Ik zat dus eerst naar de inverse te kijken. Met 1 koffie op zondagochtend lukt dat dus kennelijk niet.

[ Voor 9% gewijzigd door P_Tingen op 08-12-2019 11:51 ]

[ProAce]

Nog een tipje, een U en een V kunnen op elkaar lijken

[Mawlana]

ProAce schreef op zondag 8 december 2019 @ 11:53:
Nog een tipje, een U en een V kunnen op elkaar lijken

Goede tip, de U zag ik aan voor een V.

[armageddon_2k1]

Dag 8 was weer een makkie

P_Tingen schreef op zaterdag 7 december 2019 @ 16:52:
@CMG Dat is wel een beetje ook mijn probleem, ik vind de puzzeltjes leuk, maar de láp-pen tekst vind ik soms wat teveel van het goede, zeker omdat er soms echt wel kleine gotcha's in die tekst zitten die bepalend zijn voor de puzzel. Of juist zinnen die je op het verkeerde been zetten omdat je ze verkeerd interpreteert. Mijn Engels is aardig goed, maar het is niet mijn eerste taal, dus sta ik op 'achterstand' bij diegene voor wie dat wel geldt.

Lappen tekst? Dat valt toch reuze mee? Een paar paragraafjes en de belangrijke dingen staan dikgedrukt. Ik ben nog niet tegengekomen dat er kleine gotcha's inzitten eigenlijk. De specificaties zijn best helder beschreven met testcases. Als de testcases werken werkt het uiteindelijke programma ook.

Voor m'n gevoel kan het eigenlijk niet veel duidelijker

[ Voor 94% gewijzigd door armageddon_2k1 op 08-12-2019 15:00 ]

[Reynouts]

Kan me herinneren van voorgaande jaren dat soms de weekendpuzzels wat zwaarder waren (kan ook toeval zijn geweest), maar dit was inderdaad een easy sunday morning puzzel.



Wel nog even zitten kijken of ik de laatste "menselijke" stap niet snel kon automatiseren met openCV ofzo, maar dat ging toch iets langer duren dan gehoopt. Je weet eigenlijk nog niets op voorhand, bijvoorbeeld de breedte van de karakters zijn ook onbekend.

Zijn er andere die wel zoiets als OCR gedaan hebben voor de fun?

En nog mooie woorden tegengekomen in jullie output?

[ Voor 4% gewijzigd door Reynouts op 08-12-2019 15:05 ]

[CMG]

Ik ben trouwens voor de lol de puzzels uit 2015 aan het doen, ben nu bij dag 17, waarbij mijn aanpak om alle combo’s te berekenen (zelfs met onder en bovengrens) te lang duurt, dus ik moet wat slimmers gaan bedenken, eerste keer dat mijn eerste ingeving niet werkt.

[JeroenTheStig]

Pff... dat was een hele bevalling, maar ik heb dag 7 deel 2 eindelijk klaar. Debuggen is best lastig als het fout gaat halverwege de tweede iteratie met zoveel input .

Blijkbaar moest ik het hele proces stoppen als één van de intcomputers een code 99 krijgt, zonder dat direct daarvoor een output is geweest. De succesvolle iteratie van daarvoor geldt dan als laatste succesvolle output.

[armageddon_2k1]

Nee, de laatste geeft 99 en dan moet je z'n laatste output als antwoord geven. Althans dat was bij mij

[dcm360]

Op zich is de tekst vrij beschrijvend wat er moet gebeuren:

Eventually, the software on the amplifiers will halt after they have processed the final loop. When this happens, the last output signal from amplifier E is sent to the thrusters.

Dus na de laatste iteratie zegt iets in de software 'halt', en de output is dan de laatste output van amplifier E.

[Sharkware]

JeroenTheStig schreef op zondag 8 december 2019 @ 16:58:
Pff... dat was een hele bevalling, maar ik heb dag 7 deel 2 eindelijk klaar.

Same here... Eindelijk gelukt.

Dag 7 heeft me zo wel een uur of 6 gekost omdat ik bij deel 1 iets over het hoofd gezien had in de opdracht (dat elke phase maar 1x voor kan komen) en bij deel 2 de opdracht niet goed begrepen had (phase alleen nodig bij opstarten, elke restart van de computer heeft daarna maar 1 input en dat dient dan de output van de vorige te zijn, phase heb je dan niet meer nodig).

[ Voor 9% gewijzigd door Sharkware op 08-12-2019 18:16 ]

[armageddon_2k1]

Dat zijn toch dingen die letterlijk dikgedrukt stonden?

Edit: klinkt beetje snarky. Zo is het niet bedoeld

[ Voor 34% gewijzigd door armageddon_2k1 op 08-12-2019 17:58 ]

[Sharkware]

armageddon_2k1 schreef op zondag 8 december 2019 @ 17:57:
Dat zijn toch dingen die letterlijk dikgedrukt stonden?

Dat eerste wel... Kwestie van lezen. Dat tweede was interpretatie...

[diabolofan]

Even een inhaalslag gemaakt van dag 5 tot en met dag 8(behalve dag 7). Op dag 5 heel lang vast gezeten omdat ik niet snapte wat wat er met de input/output van opcode 3 en 4 bedoelt werd. Toen bleek dat de 'input' van opcode 3 helemaal gedefinieerd staat, net voor het invulveld..

Nu dus nog 'even' dag 7 doen, hopelijk hoef ik niet teveel om te bouwen en is dit de laatste vraag die voorborduurt op dag 2/5, want het wordt nu wel een zooitje (om omschrijven heb ik niet zo'n zin in )

Daos schreef op zaterdag 7 december 2019 @ 17:26:
[...]


Tegenwoordig zitten er tuples in C#. Je kan zoiets doen (waar Abc type van je value is) :

C#:

var values = new Dictionary<(int x, int y), Abc>();

values[(5, 3)] = new Abc(); 

Vroeger kon je (kan nog steeds) dit ook oplossen door een eigen klasse te maken die de IEquatable<T> interface implementeerd. Je moet dan je eigen GetHashCode en Equals maken. Als je die hebt, dan kan je die klasse als key gebruiken.

Goed ideetje voor de volgende keer, alhoewel ik niet zo'n fan ben van Tuple's, maak dan maar zelf een class vind ik altijd..

[JeroenTheStig]

Eén van de gasten uit de top 10 heeft video’s op zijn channel staan over hoe zijn oplossingen tot stand kwamen. Ongelooflijk hoe snel die gasten zijn. Als ik er naar kijk, dan voel ik me echt een amateur...

[CMG]

JeroenTheStig schreef op zondag 8 december 2019 @ 20:27:
Eén van de gasten uit de top 10 heeft video’s op zijn channel staan over hoe zijn oplossingen tot stand kwamen. Ongelooflijk hoe snel die gasten zijn. Als ik er naar kijk, dan voel ik me echt een amateur...

Hij doet wel al 10 jaar van dit soort programming challenges... dan leer je te skimmen en herken je het gestelde probleem wat sneller

[Reptile209]

Pfff, eindeloos zitten klooien met 7-1: ik had 5 werkend in Excel VBA en hem voor 7 omgezet in PHP. Alle tests werkten prima, maar de output van 5 klopte niet. Bleek er nog een newline achter de laatste code te zitten bij de data van de challenge, die zorgde dat de twee parameters onterecht ongelijk werden bij opcode 8. Één keer. Pas bij regel voor regel vergelijken van debugging output tussen VBA en PHP de fout gevonden. Grrr...
Ombouwen naar 7-2 is vooralsnog geen succes: ik zie nog niet helemaal hoe ik mijn machine daarop moet aanpassen...

[armageddon_2k1]

Dag 9, tijd om de IntComputer weer af te stoffen!

[Daanoz]

Hij komt wel vaak terug inderdaad, al bijna de helft van de puzzels... Vraag me af hoever ze met dit ding gaan.

[Mawlana]

Ik had dag 7 overgeslagen, maar ik moet 'm dus alsnog doen.

[armageddon_2k1]

Aangezien er staat dat ie vanaf dag 9 feature complete is niet veel verder denk ik?

[Reptile209]

sylvesterrr schreef op maandag 9 december 2019 @ 08:04:
Ik had dag 7 overgeslagen, maar ik moet 'm dus alsnog doen.

Goed nieuws: dag 7 was een side-branch van de intComputer. Je kan dag 5 als basis pakken.

[CMG]

Tip voor mensen die error 203 krijgen; dat komt waarschijnlijk door je opcode 9 implementatie en niet opcode 3; 9 moet (startende bij 0) elke keer zichzelf modificeren. Dus 10 => 10, 1 => 11, etc...

[JeroenTheStig]

Vanmorgen de aanpassingen gedaan aan mijn intComputer. De voorbeelden in de opgave doen het prima, echter de uitkomst van de opdracht klopt niet. Eerst maar naar mijn werk gegaan, vanavond maar verder kijken wat er mis is. Waarschijnlijk ligt het aan datgene wat @CMG hierboven vermeldt, want 203 komt mij bekend voor

[Ethikka]

Ook beste tijd vastgezeten op "203 0", had aanpassingen gedaan waardoor het adres waarop weggeschreven word niet altijd immidiate (so far so good) maar ook relatief kon.

Probleem daarin is dat voor wegschrijven relatief betekend (immidiate val+offset) en voor lezen betekend (waarde van geheugen adres+offset)

[Gropah]

Ook ik zit vast op [203,0]. Ik denk dat ik de operatie nog niet helemaal snap,

Zoals ik hem begrijp is de relative mode niets meer dan een offset introduceren in je position mode. Dus stel je hebt relative base offset 10, dan zal de op [204, pos1] de code outputten op positie pos1 + 10. Met relative base offset 10 zal hij [201, pos1, pos2, pos3] zou hij store program[pos1 + 10] + program[pos2] into program[pos3] moeten doen, waarbij program de lijst met getallen is. Tot zover klopt het toch?

Dus ik heb nu problemen met de input operatie. Met relative base offset 10, zou hij [203, 0] de input die de machine krijgt moeten opslaan in program[0 + 10]. Ik heb het volgende programma "109,2,203,-1,99", wat eerst zijn relative baseoffset naar 2 zet, vervolgens input inleest en deze opslaat in -1 + 2 = 1. En dit programma doet ook precies dit met mijn machine. Maar wanneer ik hem met mijn persoonlijke input draai probeert hij op een gegeven moment weg te schrijven naar een positie kleiner dan 0.

Iemand die tips heeft?

[P_Tingen]

Reptile209 schreef op maandag 9 december 2019 @ 08:16:
[...]
Goed nieuws: dag 7 was een side-branch van de intComputer. Je kan dag 5 als basis pakken.

Slecht nieuws als je dag 5 nog niet klaar had (ondergetekende). Mijn IntCode computer liep vast en dat kwam uiteindelijk door mijn verkeerde interpretatie van

Opcode 6 is jump-if-false: if the first parameter is zero, it sets the instruction pointer to the value from the second parameter.

Ik had verkeerd en schreef param-2 weg naar de waarde van het adres waar de instruction pointer naar verwees, maar dat was dus niet goed. Nou, nu eerst dag 7 maar, want dat was ook de IntCode computer....

[BernardV]

@Gropah Heb je bij de '9' wel dat de relative base vermeerderd met de waarde en niet vervangen wordt door de waarde? Dus 109,2,109,2,203,-1,99 zou zijn relative += 2, relative +=2, plaats input op 4-1 = 3?
De relative begint op 0.

[ Voor 9% gewijzigd door BernardV op 09-12-2019 12:54 ]

[P_Tingen]

JeroenTheStig schreef op zondag 8 december 2019 @ 20:27:
Eén van de gasten uit de top 10 heeft video’s op zijn channel staan over hoe zijn oplossingen tot stand kwamen. Ongelooflijk hoe snel die gasten zijn. Als ik er naar kijk, dan voel ik me echt een amateur...

Ook leuk om te kijken is een presentatie van Eric Wastl (de maker van AoC):

[Gropah]

BernardV schreef op maandag 9 december 2019 @ 12:53:
@Gropah Heb je bij de '9' wel dat de relative base vermeerderd met de waarde en niet vervangen wordt door de waarde? Dus 109,2,109,2,203,-1,99 zou zijn relative += 2, relative +=2, plaats input op 4-1 = 3?
De relative begint op 0.

Dat doet hij goed.

Ik heb er voor vandaag al genoeg tijd in gestopt, heb vandaag nog een deadline, ik denk dat ik hem morgen wel verder ga oplossen ofzo.

[DRaakje]

https://pastebin.com/sWuGcGih

Dit is mijn int computer, ik moet nog eens kijken naar het lezen en steppen door de parameters. Zo wil ik auto increment van de adresspointer, en een soort van decompiler maken zodat je kan zien wat ie gaat doen bij elke step, e.d. Ook heb ik nu een aparte method voor Get en Set voor de parameters, maar het zou makkelijker kunnen.

[ Voor 16% gewijzigd door DRaakje op 09-12-2019 13:46 ]

[mrlukasbos]

die 203 0 error is mij ook bekend. Ik had opcode 3 niet aangepast voor 'immediate' values (zoals het hoort) maar opcode 3 is wel gevoelig voor 'relative' values. Hierbij mijn oplossing in Haskell: https://github.com/mrlukasbos/aoc2019/blob/master/day-9/9.hs

[Gropah]

fml. Part 1 gedaan, maar part 2 crasht bij mij . Just my luck. En ja, er zit echt test in

edit: opgelost. Ik resizede voordat de relative offset er bij kwam

[ Voor 17% gewijzigd door Gropah op 09-12-2019 15:09 ]

[Hydra]

Dag 9 (waar weinig in staat) en m'n IntCode computer.

Wel blij dat we kennelijk klaar zijn met dat ding uitbreiden, was er wel een beetje klaar mee. An sich was de hoeveelheid werk miniem nu, alleen had ik over 't stuk heengelezen dat het 'geheugen' veel groter is dan wat je initieel hebt. En dan crash je dus op een out of bounds.

spoiler:

M'n geheugen is nu een hash-map, toen werkte het direct

Vond deel 2 van vandaag nogal raar. Die werkte direct.

[Gropah]

Hydra schreef op maandag 9 december 2019 @ 15:09:
Dag 9 (waar weinig instaat) en m'n IntCode computer.

Wel blij dat we kennelijk klaar zijn met dat ding uitbreiden, was er wel een beetje klaar mee. An sich was de hoeveelheid werk miniem nu, alleen had ik over 't stuk heengelezen dat het 'geheugen' veel groter is dan wat je initieel hebt. En dan crash je dus op een out of bounds.

spoiler:

M'n geheugen is nu een hash-map, toen werkte het direct

Vond deel 2 van vandaag nogal raar. Die werkte direct.

Ik ga even in je code kijken gezien je kotlin doet en ik dat nu juist aan het leren ben.

Deel 2 is inderdaad raar, maar test schijnbaar wel andere dingen. Oh, dat de intcode machine compleet is betekend niet dat hij niet meer gaat terug komen

[Hydra]

Gropah schreef op maandag 9 december 2019 @ 15:17:
Deel 2 is inderdaad raar, maar test schijnbaar wel andere dingen. Oh, dat de intcode machine compleet is betekend niet dat hij niet meer gaat terug komen

Ja, dat wou ik niet spoilen, maargoed...

Als je vragen hebt; let me know.

[ Voor 4% gewijzigd door Hydra op 09-12-2019 15:52 ]

[veldsla]

Ik heb er ook steeds een beetje half naar zitten kijken en miste toen ook een belangrijk detail (relative writes ). Wel leuk dat je na aanpassingen de tests/opdrachten van de vorige dagen ook kunt gebruiken om de boel te checken.

Voor wie bang is voor het zinnetje 'The computer should have support for large numbers', 64-bit ints zijn gewoon voldoende. Ik vond dat al een beetje flauw (hoewel Julia ook Int128 en BigInt out-of-the-box heeft)

[JeroenTheStig]

veldsla schreef op maandag 9 december 2019 @ 16:25:
Ik heb er ook steeds een beetje half naar zitten kijken en miste toen ook een belangrijk detail (relative writes ). Wel leuk dat je na aanpassingen de tests/opdrachten van de vorige dagen ook kunt gebruiken om de boel te checken.

Voor wie bang is voor het zinnetje 'The computer should have support for large numbers', 64-bit ints zijn gewoon voldoende. Ik vond dat al een beetje flauw (hoewel Julia ook Int128 en BigInt out-of-the-box heeft)

Bedankt voor de hint , nu weet ik in ieder geval wat er bij mij mis gaat. Vanavond eens even kijken, vermoedelijk een makkelijke fix.

[Night-Reveller]

Heu! Ik doe nu ook mee, nog niet ver (dag 3...) maar de puzzeltjes zijn leuk en vermakelijk.

[Reynouts]

Hydra schreef op maandag 9 december 2019 @ 15:09:
Dag 9 (waar weinig in staat) en m'n IntCode computer.

Wel blij dat we kennelijk klaar zijn met dat ding uitbreiden, was er wel een beetje klaar mee. An sich was de hoeveelheid werk miniem nu, alleen had ik over 't stuk heengelezen dat het 'geheugen' veel groter is dan wat je initieel hebt. En dan crash je dus op een out of bounds.

spoiler:

M'n geheugen is nu een hash-map, toen werkte het direct

Vond deel 2 van vandaag nogal raar. Die werkte direct.

Ik denk dat deel 2 een gratis cadeautje was voor degene die klaar waren met de Intcode computer opdrachten (zoals ik).

Op naar de volgende 🤗

[Beneveerg]

Ik heb dag 3 maar over geslagen, omdat ik geen idee heb over hoe en wat, misschien bij andere talen maar eens spieken.

Dag 4-1 heeft ook lang zat geduurd en het script doet er best lang over om een uitkomst te hebben, maar hij doet het wel. https://github.com/bengreeve/AdventCode/blob/master/4-1.ps1

[Boudewijn]

Ik ben net een weekend weggeweest en aan 6 begonnen maar ik kom er niet uit.
Mijn bevindingen:
[spoiler
Heb net ontdekt dat je meerdere roots hebt omdat je losse objecten A hebt die om B orbitten...
[/]
Dat is gefixed in mijn code maar is niet de oplossing.

Dit is nu mijn code:

spoiler:

[code=python]
class Tree:

def __init__(self, input):
input, self.nodes = input, dict()

for line in input:
self.add_relation(line)

self.roots = self.find_roots()
for root in self.roots:
self.add_orbits_to_node(root, 0)

def add_relation(self, line):
parent, child = line.split(')')[0], line.split(')')[1]
if parent not in self.nodes:
self.nodes[parent] = [set(), 1]
self.nodes[parent][0].add(child)
if child not in self.nodes:
self.nodes[child] = [set(), 1]

def find_roots(self):
possible_root_nodes = list(self.nodes.keys())

for n in self.nodes:
if n[0] in possible_root_nodes:
possible_root_nodes.remove(n[0])
return possible_root_nodes

def add_orbits_to_node(self, name, orbits):
self.nodes[name][1] = orbits

for child in self.nodes[name][0]:
self.add_orbits_to_node(child, orbits + 1)
return


Wat dan weer wordt gerund doot zoiets als dit:
(get_input levert een list van strings)
input = get_input("input")
t = Tree(input)
total_orbits=0
for node_name in t.nodes.keys():
total_orbits+=t.nodes[node_name][1]
print("6a: {}".format(total_orbits))

[/]

Maar dit werkt dus niet.

Kan iemand me een hint geven?

[ Voor 9% gewijzigd door Boudewijn op 09-12-2019 20:44 ]

[MerijnB]

Boudewijn schreef op maandag 9 december 2019 @ 20:43:
Ik ben net een weekend weggeweest en aan 6 begonnen maar ik kom er niet uit.
Mijn bevindingen:
[spoiler
Heb net ontdekt dat je meerdere roots hebt omdat je losse objecten A hebt die om B orbitten...
[/]
Dat is gefixed in mijn code maar is niet de oplossing.

Dit is nu mijn code:

spoiler:

[code=python]
class Tree:

def __init__(self, input):
input, self.nodes = input, dict()

for line in input:
self.add_relation(line)

self.roots = self.find_roots()
for root in self.roots:
self.add_orbits_to_node(root, 0)

def add_relation(self, line):
parent, child = line.split(')')[0], line.split(')')[1]
if parent not in self.nodes:
self.nodes[parent] = [set(), 1]
self.nodes[parent][0].add(child)
if child not in self.nodes:
self.nodes[child] = [set(), 1]

def find_roots(self):
possible_root_nodes = list(self.nodes.keys())

for n in self.nodes:
if n[0] in possible_root_nodes:
possible_root_nodes.remove(n[0])
return possible_root_nodes

def add_orbits_to_node(self, name, orbits):
self.nodes[name][1] = orbits

for child in self.nodes[name][0]:
self.add_orbits_to_node(child, orbits + 1)
return


Wat dan weer wordt gerund doot zoiets als dit:
(get_input levert een list van strings)
input = get_input("input")
t = Tree(input)
total_orbits=0
for node_name in t.nodes.keys():
total_orbits+=t.nodes[node_name][1]
print("6a: {}".format(total_orbits))

[/]

Maar dit werkt dus niet.

Kan iemand me een hint geven?

Deel 1 of 2? Werkt het voorbeeld wel?

[JeroenTheStig]

Dag 9 deel twee was inderdaad een weggevertje. Wel grappig om te zien dat zelfs op een moderne machine het eventjes duurt voor er een antwoord uit rolt.

Het is alleen wel tijd voor een stevige refactorslag als ik fatsoenlijk door wil gaan met de intcode machine.

[Boudewijn]

@MerijnB Het gaat om 6a.

Python:

from unittest import TestCase

from Aoc_2019_6 import *


class TestAoc2019_6(TestCase):

    def get_input(self, file):
        f = open(file, "r")
        result = list(map(lambda x: x[0:-1], f.readlines()))
        f.close()
        return result

    def test_tree_weight(self):
        input = self.get_input("test_input")
        t = Tree(input)
        self.assertEqual("COM", t.find_roots()[0])

    def test_tree_weight(self):
        input = self.get_input("test_input")
        t = Tree(input)

        self.assertEqual(3, t.nodes['D'][1])
        self.assertEqual(7, t.nodes['L'][1])
        self.assertEqual(0, t.nodes['COM'][1])
        self.assertEqual(0, t.nodes[t.find_roots()[0]][1])

    def test_total_tree_weight(self):
        input = self.get_input("test_input")
        t = Tree(input)
        total_orbits = 0
        for node_name in t.nodes.keys():
            total_orbits += t.nodes[node_name][1]
        self.assertEqual(42, total_orbits)

Ja dat ziet er goed uit, zie ook bijvoorbeeld bovenstaande unittests (die deel ik zonder spoiler tags omdat de testcode wmb alleen laat zien wat de output moet zijn ipv de mechanica erachter)

[Hydra]

JeroenTheStig schreef op maandag 9 december 2019 @ 20:55:
Dag 9 deel twee was inderdaad een weggevertje. Wel grappig om te zien dat zelfs op een moderne machine het eventjes duurt voor er een antwoord uit rolt.

Waar bouw je het dan in? Bij mij is het 240ms.

[JeroenTheStig]

Hydra schreef op maandag 9 december 2019 @ 21:21:
[...]


Waar bouw je het dan in? Bij mij is het 240ms.

Ik bouw het in Java. Het begon als spielerij om ook wat patterns te oefenen/testen en ik weet dat het overkill is, maar ik ben in het begin losgegaan met een interpreter pattern met een abstract factory met een implementatie per opcode type. Het wordt met al die aanpassingen in de loop van de tijd wat rommelig en het wordt er vast niet sneller op.

Ik weet ook niet of het per persoon verschillend is qua hoeveelheid te verwerken opcodes vanwege de verschillen in de inputfiles, maar in opdracht 2 worden er bij mij 371205 opcodes verwerkt.

[ Voor 3% gewijzigd door JeroenTheStig op 09-12-2019 21:35 ]

[armageddon_2k1]

Fuck, vandaag niet gelukt om hem af te krijgen door de bedrijven door. Verkeerd gelezen op sommige momenten..... ik met mn grote mond. Morgen maar verder

[dcm360]

Maar goed dat ik braaf ben gaan debuggen voordat ik hier ging lezen, anders had ik veel te snel geweten dat ik ook opcode 3 vergeten was met de nieuwe mode

De performance viel me ook mee, in 229ms worden beide delen berekend bij mij, ondanks dat ik meestal een performance-penalty moet incasseren vanwege het gebruik van immutable datastructuren.

@JeroenTheStig Het aantal opcodes is denk ik voor iedereen gelijk (ik kwam op 371206), het is relatief eenvoudig om programma's te genereren die dezelfde structuur hebben maar wel een andere output geven.

[ Voor 23% gewijzigd door dcm360 op 09-12-2019 22:46 ]

[armageddon_2k1]

Heeft opcode 9 eigenlijk ook de mogelijkheid tot relative mode?

spoiler:

Edit: ik zie een 209,12 in mn input. Oftewel Relative Opcode met Relative mode. Dus de nieuwe offset wordt: offset + memory[offset + 12] dan. Klopt mn gedachtegang?

[ Voor 61% gewijzigd door armageddon_2k1 op 09-12-2019 22:58 ]

[Gropah]

armageddon_2k1 schreef op maandag 9 december 2019 @ 22:54:
Heeft opcode 9 eigenlijk ook de mogelijkheid tot relative mode?

spoiler:

ja

spoiler: nog meer spoiler

alles wat iets opslaat of uitleest kan een relative mode hebben

[Reynouts]

Boudewijn schreef op maandag 9 december 2019 @ 20:58:
@MerijnB Het gaat om 6a.

Python:

from unittest import TestCase

from Aoc_2019_6 import *


class TestAoc2019_6(TestCase):

    def get_input(self, file):
        f = open(file, "r")
        result = list(map(lambda x: x[0:-1], f.readlines()))
        f.close()
        return result

    def test_tree_weight(self):
        input = self.get_input("test_input")
        t = Tree(input)
        self.assertEqual("COM", t.find_roots()[0])

    def test_tree_weight(self):
        input = self.get_input("test_input")
        t = Tree(input)

        self.assertEqual(3, t.nodes['D'][1])
        self.assertEqual(7, t.nodes['L'][1])
        self.assertEqual(0, t.nodes['COM'][1])
        self.assertEqual(0, t.nodes[t.find_roots()[0]][1])

    def test_total_tree_weight(self):
        input = self.get_input("test_input")
        t = Tree(input)
        total_orbits = 0
        for node_name in t.nodes.keys():
            total_orbits += t.nodes[node_name][1]
        self.assertEqual(42, total_orbits)

Ja dat ziet er goed uit, zie ook bijvoorbeeld bovenstaande unittests (die deel ik zonder spoiler tags omdat de testcode wmb alleen laat zien wat de output moet zijn ipv de mechanica erachter)

Ben je er al uitgekomen? Ik kan je code op de telefoon niet helemaal netjes lezen van de vorige post en heb er vluchtig naar gekeken.

Wat mij bij staat is dat ik het precies andersom opgeslagen heb. Dus een node moet zijn "parent" kennen om de orbits die hij direct en indirect heeft makkelijk te kunnen tellen. Misschien verwarrend in de normale termen van een tree datastructuur.

De root van de tree heeft 0 direct en indirect orbits dacht ik.

Maar het kan zijn dat ik het toch niet goed onthouden heb, maar wie weet heb je er wat aan..

[armageddon_2k1]

Zo vanochtend in de trein Day 9 even gefixed. Werkt als een zonnetje nu. Part 2 in 100ms.

spoiler:

Ik heb in Kotlin een data class gemaakt Parameter met een get en set methode. Deze neemt voor elke parameter de logica van offsets, pointers etc uit handen. Vervolgens alle handmatige calls naar het RAM omgezet naar de classes en het liep meteen goed. TDD weer for the win!

[Boudewijn]

Reynouts schreef op maandag 9 december 2019 @ 23:30:
[...]


Ben je er al uitgekomen? Ik kan je code op de telefoon niet helemaal netjes lezen van de vorige post en heb er vluchtig naar gekeken.

Wat mij bij staat is dat ik het precies andersom opgeslagen heb. Dus een node moet zijn "parent" kennen om de orbits die hij direct en indirect heeft makkelijk te kunnen tellen. Misschien verwarrend in de normale termen van een tree datastructuur.

De root van de tree heeft 0 direct en indirect orbits dacht ik.

Maar het kan zijn dat ik het toch niet goed onthouden heb, maar wie weet heb je er wat aan..

Ja dat de root er 0 heeft is bekend, ik ga vanavond de code maar eens opnieuw maken.
Het rare is dat ik alles met testcases doe en de gegeven data dus wel mijn model valideert.

Ik mis dus een testcase. Meerdere roots heb ik gevonden... maar verder nog even kijken.

[BernardV]

Vanochtend voordat ik naar het werk ging Dag 10 part 1 gedaan, kwam er niet direct uit met Part 2.
Die is inmiddels (in de pauze) ook opgelost, domme fout en niet geduldig kijken was de oorzaak.

spoiler:

Ik had de hoeken berekend met atan2 tussen de punten, maar had alles 90 verschoven tov het startpunt van de laser dit had ik veel eerder kunnen zien als ik het voorbeeld goed had bekeken.

[Hydra]

Dag 10 in Kotlin

Erg leuke challenge! Wel veel tijd aan besteed; mijn eerste twee implementaties werkten niet. Toen kreeg ik een redelijk eureka moment, en vielen de stukjes op hun plek. Toen met deel twee had ik vrij snel de oplossing, alleen was ik aan het klooien omdat ik de output van mezelf niet goed las tov de voorbeelden op de site.

[Boudewijn]

Reynouts schreef op maandag 9 december 2019 @ 23:30:
[...]


Ben je er al uitgekomen? Ik kan je code op de telefoon niet helemaal netjes lezen van de vorige post en heb er vluchtig naar gekeken.

Wat mij bij staat is dat ik het precies andersom opgeslagen heb. Dus een node moet zijn "parent" kennen om de orbits die hij direct en indirect heeft makkelijk te kunnen tellen. Misschien verwarrend in de normale termen van een tree datastructuur.

De root van de tree heeft 0 direct en indirect orbits dacht ik.

Maar het kan zijn dat ik het toch niet goed onthouden heb, maar wie weet heb je er wat aan..

Goed ik zie nu pas dat code in een spoiler niet goed werkt qua layout.
Ik heb een complete rewrite gedaan met een OO sausje. Overkill maar in mijn hoofd relaxter.

Dit keer ben ik inderdaad van een parent-relatie ipv child-relatie uitgegaan. Die laatste was vond ik handiger omdat je alle parents kunt pakken (de exemplaren zonder parent) en die 0 orbits toekennen. Dan geldt voor elke child dat de orbit die van de parents+1 is. dan veeg je altijd alle children mee.

Nieuwe code zo maar eens testen, kwam ook geen goed resultaat uit helaas. Wel veel schoner.

[Boudewijn]

Goed ik kom er alsnog niet uit, ik denk dat ik niet goed begrijpend lees.

Mijn democode maakt netjes 42 orbits met dit als output:

code:

6a: Total orbits: 42
[( COM : - @ 0 ), ( B : COM @ 1 ), ( C : B @ 2 ), ( G : B @ 2 ), ( D : C @ 3 ), ( H : G @ 3 ), ( E : D @ 4 ), ( I : D @ 4 ), ( F : E @ 5 ), ( J : E @ 5 ), ( K : J @ 6 ), ( L : K @ 7 )]

In een formatje: ( <node naam> : <parent> @ <aantal orbits voor deze node> )

Dit is de code die de het model beheert (doet wat IO en puzzle-specifieke dingen)
https://pastebin.com/UHU3GcXe

Mijn tree-model:
https://pastebin.com/CCfFweYm
En mijn node (meer voor de show dan voor wat anders):
https://pastebin.com/m72iSvxA


Ik zie oprecht niet in waar de fout zit, dit is een vrij triviale puzzle... ik heb 35 sterren bij de 2016-editie dus kan wel iets maar loop hier compleet vast. Kan iemand me een hint geven?

[ Voor 4% gewijzigd door Boudewijn op 10-12-2019 16:13 ]

[P_Tingen]

Dag 10, deel 1 gedaan. Maar nu deel 2 nog.

spoiler:

Ik heb de hoeken berekend van de laser naar de asteroïden, maar de laser begint op 90 graden en gaat dan rechtsom. Hoe bereken ik dan - met atan2 - de hoek tussen de laser en de asteroïde??

[ProAce]

P_Tingen schreef op dinsdag 10 december 2019 @ 16:13:
Dag 10, deel 1 gedaan. Maar nu deel 2 nog.

spoiler:

Ik heb de hoeken berekend van de laser naar de asteroïden, maar de laser begint op 90 graden en gaat dan rechtsom. Hoe bereken ik dan - met atan2 - de hoek tussen de laser en de asteroïde??

spoiler:

Ik heb de hoek van atan2 lineair omgerekend met de map functie van arduino
Dus van -180 tot -90 mappen naar 270 tot 360, en van -90 tot 180 naar 0 tot 270.
Dit werkt voor de test input, maar mijn eigen klopt niet....

[armageddon_2k1]

Zo Dag 10 is klaar....

spoiler:

Even een aandachtspuntje voor als je hoeken niet kloppen. Hou er rekening mee dat 'naar boven toe' een afname in y coordinaat is. Duurde even voordat ik dat bugje opgelost had

[BernardV]

ProAce schreef op dinsdag 10 december 2019 @ 16:49:
[...]

spoiler:

Ik heb de hoek van atan2 lineair omgerekend met de map functie van arduino
Dus van -180 tot -90 mappen naar 270 tot 360, en van -90 tot 180 naar 0 tot 270.
Dit werkt voor de test input, maar mijn eigen klopt niet....

spoiler:

Let wel dat je er geen "ints" van maakt, je kunt natuurlijk iets krijgen als 75,4 graden

//EDIT:
Hoe ik Dag 10 part 2 heb aangepakt:

spoiler:

Ik heb de hoek berekend tussen alle asteroids vanaf mijn laser. Ik heb een lijst gemaakt van alle voorkomende hoeken, deze lijst gesorteerd op hoek. Alle asteroids die onder een hoek vallen toegevoegd aan die lijst gesorteerd op de afstand van laag naar hoog. Nu kan ik de lijst doorlopen en onder elke voorkomende hoek de asteroid verwijderen die het dichtst bij is. Bij een volgende run idem...

Dit is het kort omschreven.
Runtime voor mijn input 48ms, 47ms voor het voorbeeld, dus gelijk. Part 1 + 2 samen 100ms.

[ Voor 43% gewijzigd door BernardV op 10-12-2019 18:43 ]

[Daanoz]

Boudewijn schreef op dinsdag 10 december 2019 @ 16:12:
Goed ik kom er alsnog niet uit, ik denk dat ik niet goed begrijpend lees.

Heb je code niet gedebugged ofzo, maar iets wat ik anders heb gedaan is dit stuk:

code:

child_node = Node(child_name)
parent_node = self.get_or_create_node_by_name(parent_name)

Je neemt hier aan dat de child node nooit eerder is langs gekomen in de lijst als een parent van een andere node...

[armageddon_2k1]

Hydra schreef op dinsdag 10 december 2019 @ 14:14:
Dag 10 in Kotlin

Erg leuke challenge! Wel veel tijd aan besteed; mijn eerste twee implementaties werkten niet. Toen kreeg ik een redelijk eureka moment, en vielen de stukjes op hun plek. Toen met deel twee had ik vrij snel de oplossing, alleen was ik aan het klooien omdat ik de output van mezelf niet goed las tov de voorbeelden op de site.

Kotlin is ❤️. Mooie oplossing, stuk minder verbose dan mijnes. Maar je hebt ook al aardig wat AoC grondwerk liggen zag ik.

@Daanoz en @Boudewijn, de orbits vraag heb je toch helemaal geen uitgebreide tree structuur nodig? Gewoon een hashmapje met was parent child relaties is genoeg (wat natuurlijk effectief een soort tree is, maar ik vond het minder fout gevoelig)

[ Voor 14% gewijzigd door armageddon_2k1 op 10-12-2019 19:00 ]

[Boudewijn]

@armageddon_2k1 @Daanoz Zeker maar dat werkte niet goed in versie1... dus daarna het heel overkill uitgeschreven en het werkt alsnog niet. Ik denk dat ik een rare edge case mis ofzo. Straks nog ff op kauwen.

[ Voor 14% gewijzigd door Boudewijn op 10-12-2019 19:05 ]

[JeroenTheStig]

Dag 10 ook weer klaar. Deze keer had ik een verschrikkelijk domme bug in het printen van mijn antwoord:

Java:

System.out.println("Answer 2: " + vaporizedAsteroid.x * 100 + vaporizedAsteroid.y);

Daar kwam bij coordinaat (16,23) dus 160023 uit i.p.v. 1623

[Daanoz]

armageddon_2k1 schreef op dinsdag 10 december 2019 @ 18:59:

@Daanoz en @Boudewijn, de orbits vraag heb je toch helemaal geen uitgebreide tree structuur nodig? Gewoon een hashmapje met was parent child relaties is genoeg (wat natuurlijk effectief een soort tree is, maar ik vond het minder fout gevoelig)

Correct, maar dat is eigenlijk ook wat we hebben toch? Een map om de nodes te vinden, en in elke node een link naar z'n parent... Of bedoel je nog simpeler?

[DataGhost]

Hydra schreef op dinsdag 10 december 2019 @ 14:14:
Dag 10 in Kotlin

Erg leuke challenge! Wel veel tijd aan besteed; mijn eerste twee implementaties werkten niet. Toen kreeg ik een redelijk eureka moment, en vielen de stukjes op hun plek. Toen met deel twee had ik vrij snel de oplossing, alleen was ik aan het klooien omdat ik de output van mezelf niet goed las tov de voorbeelden op de site.

Ik heb Kotlin nog nooit gebruikt dus misschien lees ik het verkeerd, maar volgens mij is je oplossing fout en gaat 'ie alleen maar goed omdat je antwoord bij deel 1 hoger was dan 200, denk daar maar eens over na

[ProAce]

BernardV schreef op dinsdag 10 december 2019 @ 17:35:
[...]

spoiler:

Ik heb de hoek berekend tussen alle asteroids vanaf mijn laser. Ik heb een lijst gemaakt van alle voorkomende hoeken, deze lijst gesorteerd op hoek. Alle asteroids die onder een hoek vallen toegevoegd aan die lijst gesorteerd op de afstand van laag naar hoog. Nu kan ik de lijst doorlopen en onder elke voorkomende hoek de asteroid verwijderen die het dichtst bij is. Bij een volgende run idem...

Dit is het kort omschreven.
Runtime voor mijn input 48ms, 47ms voor het voorbeeld, dus gelijk. Part 1 + 2 samen 100ms.

spoiler:

https://github.com/ProAce...aster/2019/Day_10/main.go Ik heb het ook zo aangepakt, en de testcode werkt perfect, maar ik kan er niet achterkomen waarom mijn eigen input niet werkt

[DataGhost]

ProAce schreef op dinsdag 10 december 2019 @ 20:06:
[...]

spoiler:

https://github.com/ProAce...aster/2019/Day_10/main.go Ik heb het ook zo aangepakt, en de testcode werkt perfect, maar ik kan er niet achterkomen waarom mijn eigen input niet werkt

Ik weet niet goed hoe ik hier een hint van kan maken zonder direct alles te spoileren, maar

spoiler:

je berekent de distance verkeerd

Ik weet trouwens niet of dat uitmaakt voor het eindresultaat. Dat maakt uit voor het eindresultaat.
Ook zitten er volgens mij twee fouten in je anihilateAsteroids-functie, waar je waarschijnlijk niet direct last van gaat hebben met de test-input, een beetje hetzelfde verhaal als in mijn vorige post. Die twee fouten hebben daar allebei in zekere zin mee te maken, maar op een andere manier dan in de code van Hydra.

[ Voor 5% gewijzigd door DataGhost op 10-12-2019 21:06 ]

[FrankMennink]

Oef, dag 10 was wel even een pittige. Code is ook wel een lekker uitgebreid monster geworden. Ook behoorlijk wat tijd verspild aan een + wat een - moest zijn

spoiler:

ik werk met alles met een relatief coordinaat, alleen bij het terugrekenen t foutje gemaakt waar armageddon_2k1 voor waarschuwde. Ook lekker moeilijk gedaan met dan helling van de lijn en dan opdelen in 4 kwadranten.

[ProAce]

DataGhost schreef op dinsdag 10 december 2019 @ 21:02:
[...]

Ik weet niet goed hoe ik hier een hint van kan maken zonder direct alles te spoileren, maar

spoiler:

je berekent de distance verkeerd

Ik weet trouwens niet of dat uitmaakt voor het eindresultaat. Dat maakt uit voor het eindresultaat.
Ook zitten er volgens mij twee fouten in je anihilateAsteroids-functie, waar je waarschijnlijk niet direct last van gaat hebben met de test-input, een beetje hetzelfde verhaal als in mijn vorige post. Die twee fouten hebben daar allebei in zekere zin mee te maken, maar op een andere manier dan in de code van Hydra.

spoiler:

Ik moest er even voor naar jouw code kijken om te snappen wat er mis mee was, maar zo worden "negatieve" coordinaten goed afgehandeld en nu werkt het wel .

Bedoel je met fout twee dat op een gegeven moment de slices leeg zullen zijn maar je er nog wel overheen itereert?

[diabolofan]

Vandaag vond ik goed te doen, maar ik zit nog steeds met vriend intcode van dag 7 part 1. Die 3 voorbeelden doen het prima, maar met de puzzle input werkt het blijkbaar niet. Heb dit topic al doorgespit en wat code van anderen bekeken, maar kan maar niet vinden wat ik fout doe...

Het enige verschil wat ik zie tussen de voorbeelden en mijn puzzle input, is dat bij de voorbeelden er twee keer direct de inputs worden gevraagd aan het begin, terwijl dit mijn puzzle input niet het geval is. Bij sommige phase settings heb ik in ieder geval dat niet altijd de tweede input wordt opgevraagd wat me niet lijkt te horen, wat dus betekend dat ik ergens een 3 overschijf wat dus niet zou moeten... Iemand een tip/hint? https://github.com/gercob...AdventOfCode2019/Day07.cs

[ Voor 7% gewijzigd door diabolofan op 10-12-2019 22:33 ]

[MerijnB]

diabolofan schreef op dinsdag 10 december 2019 @ 22:31:
Vandaag vond ik goed te doen, maar ik zit nog steeds met vriend intcode van dag 7 part 1. Die 3 voorbeelden doen het prima, maar met de puzzle input werkt het blijkbaar niet. Heb dit topic al doorgespit en wat code van anderen bekeken, maar kan maar niet vinden wat ik fout doe...

Het enige verschil wat ik zie tussen de voorbeelden en mijn puzzle input, is dat bij de voorbeelden er twee keer direct de inputs worden gevraagd aan het begin, terwijl dit mijn puzzle input niet het geval is. Bij sommige phase settings heb ik in ieder geval dat niet altijd de tweede input wordt opgevraagd wat me niet lijkt te horen, wat dus betekend dat ik ergens een 3 overschijf wat dus niet zou moeten... Iemand een tip/hint? https://github.com/gercob...AdventOfCode2019/Day07.cs

Weet je of het bij alle permutations fout gaat of bij enkele specifieke?