Advent of Code 2019

[diabolofan]

MerijnB schreef op dinsdag 10 december 2019 @ 22:46:
[...]


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

Nee bij eigenlijk allemaal vermoed ik. Sowieso bij de paar eerste al niet. (0,1,2,3,4 en 0,1,2,4,3 bijv)


OOOPS. Uur of 4 van mijn level verspild... Ik gebruikte nog de puzzle input van day 5...

[ Voor 15% gewijzigd door diabolofan op 10-12-2019 23:19 ]

[MerijnB]

diabolofan schreef op dinsdag 10 december 2019 @ 22:53:
[...]


Nee bij eigenlijk allemaal vermoed ik. Sowieso bij de paar eerste al niet. (0,1,2,3,4 en 0,1,2,4,3 bijv)


OOOPS. Uur of 4 van mijn level verspilt... Ik gebruikt de puzzle input van day 5...

Zal ik je een executable sturen die alleen 0, 1, 2, 3, 4 doet en daarbij alle stappen output, kan je vergelijken met jou app.

Ah, ik zie de edit, ik vermoed dat het nu opgelost is

[ Voor 5% gewijzigd door MerijnB op 10-12-2019 23:02 ]

[Hydra]

DataGhost schreef op dinsdag 10 december 2019 @ 19:54:
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

Hij werkt op alle test inputs dus lijkt me sterk dat 'ie fout is. Wat denk jij dat er mis is dan?

[ Voor 3% gewijzigd door Hydra op 10-12-2019 23:14 ]

[JeroenTheStig]

Hydra schreef op dinsdag 10 december 2019 @ 23:13:
[...]


Hij werkt op alle test inputs dus lijkt me sterk dat 'ie fout is. Wat denk jij dat er mis is dan?

Ik denk dat hij bedoelt dat als je antwoord op vraag 1 kleiner zou zijn dan 200, je in de eerste 360 graden rondje van de laser nog geen 200 asteroides hebt gelaserd. In dat geval zal je na de eerste ronde dus opnieuw de zichtbare asteroiden moeten bepalen vanaf de asteroide waar je laser staat en weer verder moeten laseren.

Zie als voorbeeld mijn code vanaf regel 40.

Overigens zie ik nog wel een paar bugjes in mijn code, maar ik denk dat je het idee wel begrijpt

[ Voor 6% gewijzigd door JeroenTheStig op 10-12-2019 23:25 ]

[Gropah]

Hydra schreef op dinsdag 10 december 2019 @ 23:13:
[...]


Hij werkt op alle test inputs dus lijkt me sterk dat 'ie fout is. Wat denk jij dat er mis is dan?

Als ik het zo lees kan het zijn dat je een map pakt waar een lege mutable list achter zit. Dan haal je niets weg, maar je itereert wel gewoon door, waardoor als je stopt bij 200 er niet per se 200 asteroids zijn vernietigd. Maar met jouw input klopt het schijnbaar wel allemaal.

En interessant om weer naar je code te kijken. Je maakt erg veel gebruik van map, erg leerzaam omdat ik het zelf niet zoveel gebruikte voordat ik kotlin deed. Dus nu is het een beetje een uitdaging voor mij geworden om zoveel mogelijk daar mee te werken

Vind je trouwens niet dat je een beetje vals speelt met je benchmarks als je al een groot deel van de berekening bij de initialisatie van het object doet en dus buiten je timers?

[Hydra]

JeroenTheStig schreef op dinsdag 10 december 2019 @ 23:18:
Ik denk dat hij bedoelt dat als je antwoord op vraag 1 kleiner zou zijn dan 200, je in de eerste 360 graden rondje van de laser nog geen 200 asteroides hebt gelaserd.

Nee dat klopt niet. Hij lasert gewoon 200 asteroides:

val list = rads[i % rads.size].second

Hij leest vermoedelijk over de modulo heen. Wat wel klopt is dat 'ie kwa movement geen rekening houdt met als een lijst leeg is, maar dat is met deze input niet nodig. En ik schrijf oplossingen ook niet voor elke willekeurige input.

Gropah schreef op woensdag 11 december 2019 @ 00:28:
Als ik het zo lees kan het zijn dat je een map pakt waar een lege mutable list achter zit. Dan haal je niets weg, maar je itereert wel gewoon door, waardoor als je stopt bij 200 er niet per se 200 asteroids zijn vernietigd. Maar met jouw input klopt het schijnbaar wel allemaal.

Nee dat klopt niet. Het is een lijst van mutable lijsten

En interessant om weer naar je code te kijken. Je maakt erg veel gebruik van map, erg leerzaam omdat ik het zelf niet zoveel gebruikte voordat ik kotlin deed. Dus nu is het een beetje een uitdaging voor mij geworden om zoveel mogelijk daar mee te werken

Leuk! Ik heb wel het voordeel dat ik Kotlin ook in m'n werk gebruik tegenwoordig. Dus ik ben aardig verschoven naar de functionele kant. Waarbij soms collega's een beetje moeite krijgen met het leze van de code, dus ik moet wel oppassen in m'n werk niet te veel te gaan code-golven.

Vind je trouwens niet dat je een beetje vals speelt met je benchmarks als je al een groot deel van de berekening bij de initialisatie van het object doet en dus buiten je timers?

Zie je die 'by lazy'? Die berekeningen vallen niet buiten de timer Het enige wat ik normaliter buiten de timer doe is het inlezen en mappen van de input.

[ Voor 67% gewijzigd door Hydra op 11-12-2019 07:03 ]

[bakkerjangert]

Vandaag was ook weer leuk en prima te doen (als je tenminste goed leest; heeft me even gekost om uit te vinden dat ik eerst moet draaien en dan pas moet lopen; had ik natuurlijk weer net andersom geimplementeerd ). Nadat ik dat licht zag had ik de oplossing redelijk snel gevonden. Part 2 is wel een beetje een weg-gevertje.

[ Voor 7% gewijzigd door bakkerjangert op 11-12-2019 09:18 ]

[Hydra]

Vind die IntCode assignments maar niks...

Dag 11 in Kotlin

[armageddon_2k1]

Deze vond ik niks

[BernardV]

armageddon_2k1 schreef op woensdag 11 december 2019 @ 12:17:
Deze vond ik niks

Moet nog beginnen, dank je voor de opbeurende woorden

[veldsla]

Vond het wel grappig. Als je Intcode machine goed werkt is het een simpel loopje. Toch kreeg ik het voor elkaar om de opdracht 2x verkeerd te lezen. (In my defence, er was nog geen cafeïne ingegaan)

[FrankMennink]

Dag 11 in Python3

Was opzich wel een leuke puzzel, tijdje vastgezeten omdat dat ding in een soort loop bleef hangen (draaide letterlijk in cirkels), bleek na veel gevloek en getier een foutje te zijn in t lezen van de input. Buiten dat draaide alles lekker in een keer door

[Gropah]

Ik vond het wel prima te doen, maar

spoiler:

Het duurde even voordat ik doorhad dat ik de output van 1 hergebruikte voor deel 2, wat niet de bedoeling is, en dat mijn output van 2 de y de verkeerde kant op liet lopen...

[BernardV]

Hij was inderdaad prima te doen, maar wat @veldsla al zei; Als je Intcode machine goed werkt is het niet veel werk.

[Vloris]

Mijn dag 11 in python 3: https://github.com/vloris...lob/master/day11/day11.py

Niet de kortste/compactste, maar ik doe de hele advent dit jaar vooral om een beetje leesbaar/onderhoudbare pythoncode te leren schrijven.

[DataGhost]

ProAce schreef op dinsdag 10 december 2019 @ 22:08:
[...]

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?

De dag is voorbij en het is opgelost dus geen spoiler meer, maar volgens mij heb je een off-by-one waar je nooit aan toe komt omdat er meer dan 200 asteroids zijn, en ik denk dat je slice op regel 115 verkeerd is, waar je om dezelfde reden geen last van hebt. Jouw code zal prima doorrammelen tot de 29347239847e asteroide, ook al heb je er maar 500

Hydra schreef op woensdag 11 december 2019 @ 06:57:
[...]


Nee dat klopt niet. Hij lasert gewoon 200 asteroides:

val list = rads[i % rads.size].second

Hij leest vermoedelijk over de modulo heen. Wat wel klopt is dat 'ie kwa movement geen rekening houdt met als een lijst leeg is, maar dat is met deze input niet nodig. En ik schrijf oplossingen ook niet voor elke willekeurige input.

Daar las ik niet overheen, maar je rads.size is groter dan 200 dus heel die modulo had je ook weg kunnen laten in principe. Ik probeerde je gewoon op een denkfout te wijzen, als je namelijk de 400e asteroide had moeten teruggeven had je waarschijnlijk het verkeerde antwoord gekregen. Het maakt voor deze input inderdaad niks uit.

[ Voor 40% gewijzigd door DataGhost op 11-12-2019 14:55 ]

[Hydra]

DataGhost schreef op woensdag 11 december 2019 @ 14:48:
Daar las ik niet overheen, maar je rads.size is groter dan 200 dus heel die modulo had je ook weg kunnen laten in principe. Ik probeerde je gewoon op een denkfout te wijzen, als je namelijk de 400e asteroide had moeten teruggeven had je waarschijnlijk het verkeerde antwoord gekregen. Het maakt voor deze input inderdaad niks uit.

Punt is meer dat wat jij een 'denkfout' noemt, gewoon een bewuste keuze is. Komt iets vriendelijker over in je communicatie.

[ProAce]

DataGhost schreef op woensdag 11 december 2019 @ 14:48:
[...]

De dag is voorbij en het is opgelost dus geen spoiler meer, maar volgens mij heb je een off-by-one waar je nooit aan toe komt omdat er meer dan 200 asteroids zijn, en ik denk dat je slice op regel 115 verkeerd is, waar je om dezelfde reden geen last van hebt. Jouw code zal prima doorrammelen tot de 29347239847e asteroide, ook al heb je er maar 500

Ik zie wat je bedoelt, maar zie niet hoe ik het zo 123 kan fixen. En gezien het nu werkt laat ik het maar even zo.

Loop flink te stoeien met Go en zijn goroutines, die willen nog niet echt meewerken met mijn intcode machine

[DataGhost]

Hydra schreef op woensdag 11 december 2019 @ 16:28:
[...]


Punt is meer dat wat jij een 'denkfout' noemt, gewoon een bewuste keuze is. Komt iets vriendelijker over in je communicatie.

Sure thing. Waarom heb je dan überhaupt regels 29 t/m 37 staan, als je gewoon

code:

var p = rads[199].second.removeAt(0)

had kunnen gebruiken voor hetzelfde resultaat? Wordt 'ie nog sneller van ook.

ProAce schreef op woensdag 11 december 2019 @ 17:09:
[...]


Ik zie wat je bedoelt, maar zie niet hoe ik het zo 123 kan fixen. En gezien het nu werkt laat ik het maar even zo.

Loop flink te stoeien met Go en zijn goroutines, die willen nog niet echt meewerken met mijn intcode machine

De slice die je pakt, vermoedelijk om de geschoten asteroide weg te halen, is [:1]. Daarmee hou je dus juist alleen maar de weggeschoten asteroide over en gooi je de rest uit de lijst. Ik denk dat je [1:] bedoelt dus. Maar daarmee houd je nog wel het probleem dat je op een gegeven moment lege lijsten hebt, die je dus moet skippen. Verder onderaan doe je i++ en dan kijk je of i gelijk is aan len-1 (wat nog adressable is) en dan zet je i op 0, dus basically skip je de laatst mogelijke hoek, als ik het goed lees.

[ Voor 49% gewijzigd door DataGhost op 11-12-2019 21:15 ]

[Alain]

Ik heb t/m dag 8 elke dag tot laat gewerkt en toch mijn puzzel opgelost. Nu 3 dagen vrij geweest en geen enkele gedaan.

Morgen maar weer eens oppakken.

[diabolofan]

Poe, nog steeds bezig met day 7, part 2, maar komt er niet meer uit... Voorbeelden doen het, de input niet (en nu gebruik ik wel de goede input )

Kloppen mijn onderstaande aannames/denkstappen?

spoiler:

1. Amplifier A zorgt er voor mij altjid voor dat de chain gestopt wordt (die krijgt het eerst een 99). Als dat gebeurd dan pak ik de output die E voor het laatst gegeven heeft. Klopt dit?
2. Als ik een opcode 4 (output) krijg, dan stop ik ook de loop, en voer ik deze Output aan de volgende amplifier. Of moet ik hier eerst kijken of er wel een 99 opcode achteraankomt?
3. Ik onthoud momenteel de instruction point/index van de amplifier wanneer deze een output genereerd? Dus als bijv amplifier A op index 40 van de numbers array een opcode 4 tegenkomt, dan hoog ik de index met 2 op en sla dit op in mijn amplifier (want er is een output). Als hij dan bij E is aangekomen die vervolgens weer A gaat aanroepen, dan ga ik dus verder op index 42.

[ProAce]

DataGhost schreef op woensdag 11 december 2019 @ 21:05:
[...]

De slice die je pakt, vermoedelijk om de geschoten asteroide weg te halen, is [:1]. Daarmee hou je dus juist alleen maar de weggeschoten asteroide over en gooi je de rest uit de lijst. Ik denk dat je [1:] bedoelt dus. Maar daarmee houd je nog wel het probleem dat je op een gegeven moment lege lijsten hebt, die je dus moet skippen. Verder onderaan doe je i++ en dan kijk je of i gelijk is aan len-1 (wat nog adressable is) en dan zet je i op 0, dus basically skip je de laatst mogelijke hoek, als ik het goed lees.

Daar heb je gelijk in, het moest [1:] zijn. En dat skippen is ook correct, met deze input geen last van. Voor die lege lijsten heb ik geprobeerd die er uit te halen, maar dan klopt de uitkomst niet met het voorbeeld. Bedankt voor het meekijken in ieder geval

[DataGhost]

ProAce schreef op woensdag 11 december 2019 @ 21:57:
[...]


Daar heb je gelijk in, het moest [1:] zijn. En dat skippen is ook correct, met deze input geen last van. Voor die lege lijsten heb ik geprobeerd die er uit te halen, maar dan klopt de uitkomst niet met het voorbeeld. Bedankt voor het meekijken in ieder geval

Ik hoop dat je de lijsten niet weghaalt terwijl je door diezelfde lijsten aan het itereren bent?

[ProAce]

DataGhost schreef op woensdag 11 december 2019 @ 21:58:
[...]

Ik hoop dat je de lijsten niet weghaalt terwijl je door diezelfde lijsten aan het itereren bent?

Ik heb of meer koffie nodig, of moet naar bed. Je hebt gelijk, dat is niet handig inderdaad

[Alain]

diabolofan schreef op woensdag 11 december 2019 @ 21:54:
Kloppen mijn onderstaande aannames/denkstappen?

spoiler:

1) Nee
2) Nee
3) Ja

[DataGhost]

diabolofan schreef op woensdag 11 december 2019 @ 21:54:
Poe, nog steeds bezig met day 7, part 2, maar komt er niet meer uit... Voorbeelden doen het, de input niet (en nu gebruik ik wel de goede input )

Kloppen mijn onderstaande aannames/denkstappen?

spoiler:

1. Amplifier A zorgt er voor mij altjid voor dat de chain gestopt wordt (die krijgt het eerst een 99). Als dat gebeurd dan pak ik de output die E voor het laatst gegeven heeft. Klopt dit?
2. Als ik een opcode 4 (output) krijg, dan stop ik ook de loop, en voer ik deze Output aan de volgende amplifier. Of moet ik hier eerst kijken of er wel een 99 opcode achteraankomt?
3. Ik onthoud momenteel de instruction point/index van de amplifier wanneer deze een output genereerd? Dus als bijv amplifier A op index 40 van de numbers array een opcode 4 tegenkomt, dan hoog ik de index met 2 op en sla dit op in mijn amplifier (want er is een output). Als hij dan bij E is aangekomen die vervolgens weer A gaat aanroepen, dan ga ik dus verder op index 42.

spoiler:

1. Wat verwacht je anders in B te stoppen, en C, D en E?
2. Je kan natuurlijk je code door laten lopen of kijken of er een 99 achteraan komt, maar of je programma halt (99) of vraagt om input, die je van een andere amplifier moet gaan krijgen, dus je moet op de een of andere manier wachten/stoppen. Ik heb gewoon mijn programma gehalt na elke output.
3. Als je 'm niet zou stoppen, gaat 'ie dan ook verder op index 42?

Alain schreef op woensdag 11 december 2019 @ 22:03:
[...]

spoiler:

1) Nee

Care to elaborate?

[ Voor 5% gewijzigd door DataGhost op 11-12-2019 22:04 ]

[JeroenTheStig]

Die van vandaag was vrij eenvoudig (mits je intcode computer het goed eot), maar ik vermaak me nog steeds prima met de puzzels. Grappig om te zien dat door het invoeren van een intcode string een registration identifier uitgeprint wordt in de console.

[ Voor 8% gewijzigd door JeroenTheStig op 11-12-2019 22:08 ]

[Alain]

DataGhost schreef op woensdag 11 december 2019 @ 22:03:
Care to elaborate?

De amplifiers gaan in halt in de volgorde A, B, C, D, E. Niet letterlijk uit de tekst te halen, maar zo werkt het wel.

[DataGhost]

Alain schreef op woensdag 11 december 2019 @ 22:12:
[...]


De amplifiers gaan in halt in de volgorde A, B, C, D, E. Niet letterlijk uit de tekst te halen, maar zo werkt het wel.

Ja, maar

spoiler:

als je ze na elke output halt, en de eerste halt vervolgens zonder output, zal de rest ook halten zonder output (a.k.a. de laatste output van E verandert niet), of je programma is fout (er is immers geen input meer voor de rest van de amplifiers dus die zullen nooit halten).

[Alain]

DataGhost schreef op woensdag 11 december 2019 @ 22:21:
[...]

Ja, maar

spoiler:

als je ze na elke output halt, en de eerste halt vervolgens zonder output, zal de rest ook halten zonder output (a.k.a. de laatste output van E verandert niet), of je programma is fout (er is immers geen input meer voor de rest van de amplifiers dus die zullen nooit halten).

spoiler:

Mijn implementatie halt niet tenzij deze opcode 99 tegen komt.

[DataGhost]

Alain schreef op woensdag 11 december 2019 @ 22:27:
[...]

spoiler:

Mijn implementatie halt niet tenzij deze opcode 99 tegen komt.

Die van diabolofan (en die van mij) dus wel, dus in zijn geval klopt het gewoon.

[Alain]

DataGhost schreef op woensdag 11 december 2019 @ 22:31:
[...]

Die van diabolofan (en die van mij) dus wel, dus in zijn geval klopt het gewoon.

Nee, dan klopt het in beide gevallen niet. Het proces hoort pas in halt te gaan wanneer opcode 99 gegeven is. Niet eerder en niet later. Dat jij je statemachine in een wacht status zet is iets anders.

[BSTNjitRam]

Edit: Rubber duck debugging helpt, na het posten hiervan snapt mijn snapper ineens dat het gaat om de getallen 234208 t/m765869 en ik dus niet in deze opgegeven string hoef te gaan zoeken naar passwords... Het is al laat


Ben zelf ook begonnen en ben aangekomen bij dag 4. Kan iemand me vertellen wat ik over het hoofd zie, want ik denk op het oog al te kunnen zien dat er 0 passwords mogelijk zijn (en dat komt ook uit mijn code).

Mijn puzzle input is

code:

234208-765869

1 van de voorwaarden van het password is dat er 2 achtereenvolgende digits gelijk zijn, iets wat in deze puzzle input nergens voorkomt.

[ Voor 23% gewijzigd door BSTNjitRam op 11-12-2019 22:48 ]

[Sharkware]

Dag 9 is me dan toch eindelijk gelukt... Volgende keer maar weer gewoon fatsoenlijk opzetten ipv. in elkaar hacken... In my defense, ben begonnen met de code op mijn mobiel en dan typ je niet zo graag veel...

[ Voor 58% gewijzigd door Sharkware op 11-12-2019 22:50 ]

[diabolofan]

Bedankt @alain en @dataghost voor het meedenken! Maar concluderend lijkt het er dus op dat ik het wel goed doe, maar toch niet de juist output krijg... Ik zet hem dus inderdaad in een 'wachtmodus' na een output (ik voer de chain verder uit, zodat hij vanzelf weer bij de die amplifier uit komt met een nieuwe input. De amplifier gaat dan weer verder waar hij gebleven was, en als hij dan een 3 tegen komt gebruikt hij die nieuwe input).

[FrankMennink]

BSTNjitRam schreef op woensdag 11 december 2019 @ 22:45:
Edit: Rubber duck debugging helpt, na het posten hiervan snapt mijn snapper ineens dat het gaat om de getallen 234208 t/m765869 en ik dus niet in deze opgegeven string hoef te gaan zoeken naar passwords... Het is al laat


Ben zelf ook begonnen en ben aangekomen bij dag 4. Kan iemand me vertellen wat ik over het hoofd zie, want ik denk op het oog al te kunnen zien dat er 0 passwords mogelijk zijn (en dat komt ook uit mijn code).

Mijn puzzle input is

code:

234208-765869

1 van de voorwaarden van het password is dat er 2 achtereenvolgende digits gelijk zijn, iets wat in deze puzzle input nergens voorkomt.

234444 is in die range het eerste password wat correct is.

spoiler:

voor part 1, voor part 2 is dat 234455

Lees nog even goed de criteria door, moet minimaal een dubbele inzitten en digits mogen niet aflopen

diabolofan schreef op woensdag 11 december 2019 @ 22:52:
Bedankt @alain en @dataghost voor het meedenken! Maar concluderend lijkt het er dus op dat ik het wel goed doe, maar toch niet de juist output krijg... Ik zet hem dus inderdaad in een 'wachtmodus' na een output (ik voer de chain verder uit, zodat hij vanzelf weer bij de die amplifier uit komt met een nieuwe input. De amplifier gaat dan weer verder waar hij gebleven was, en als hij dan een 3 tegen komt gebruikt hij die nieuwe input).

spoiler:

Ik heb een gevoel dat het niet helemaal lekker gaat met het bijhouden van de outputs. Ik hou zelf een lijst bij per amplifier, iedere amplifier heeft dus zn eigen plekje waar zn output staat en zn eigen counter. Bijvoorbeeld bij A->B als ik in A een 4 tegenkom, hoog ik de huidige output counter van B met 1 op en zet ik de waarde in het geheugen van B. Daarna kan A verder tot deze een 3 (wait) of een 99 (stop) tegenkomt. Uiteindelijk staat, als alle amplifiers een 99 (zou E als laatste moeten zijn) hebben gehad, je uitkomst dan in het geheugen van A. Hopelijk heb je iets aan mn gebrabbel. Zo niet, het is al middernacht Krijg je trouwens met de voorbeeld programma's/settings wel het goede antwoord?

[ Voor 39% gewijzigd door FrankMennink op 12-12-2019 00:04 ]

[BSTNjitRam]

FrankMennink schreef op woensdag 11 december 2019 @ 23:44:
[...]
234444 is in die range het eerste password wat correct is.

spoiler:

voor part 1, voor part 2 is dat 234455

Lees nog even goed de criteria door, moet minimaal een dubbele inzitten en digits mogen niet aflopen

Zie mijn edit, ik had mijn brainfart door
Ik was in de string "234208-765869" aan het zoeken naar passwords die valide waren ipv het te zien als een reeks aan getallen.

[FrankMennink]

Dag 12 in Python 3

Eerste stap was vrij simpel, tweede stap had ik toch een hint (in spoilers voor anderen die vast zitten) voor nodig van het Internet.

spoiler:

Every coordinate is it's own dimension, also LCM

[Daanoz]

Bij mij is het muntje voor deel 2 nog niet gevallen, helaas kan ik vanavond na het werk pas weer verder... Intussen draait de code als naïeve bruteforce implementatie, mogelijk komt er een antwoord uit .

[GeertenVink]

Voor mijn antwoord zou het met miljoen simulatiestappen per milliseconde in ieder geval nog lang niet klaar zijn als ik naar mijn werk heen en weer ging.

[FrankMennink]

Daanoz schreef op donderdag 12 december 2019 @ 10:50:
Bij mij is het muntje voor deel 2 nog niet gevallen, helaas kan ik vanavond na het werk pas weer verder... Intussen draait de code als naïeve bruteforce implementatie, mogelijk komt er een antwoord uit .

voor mijn input kwam er een antwoord uit van 324 triljoen stappen, hopelijk heb je even geduld

[bakkerjangert]

FrankMennink schreef op donderdag 12 december 2019 @ 10:46:
Dag 12 in Python 3

Eerste stap was vrij simpel, tweede stap had ik toch een hint (in spoilers voor anderen die vast zitten) voor nodig van het Internet.

spoiler:

Every coordinate is it's own dimension, also LCM

Ik had zelf al wel bedacht hoe ik deel 2 wilde aanpakken, maar heb er alsnog wel even over gedaan, metname doordat ik door een domme programeer fout in de verkeerde richting ging denken.

spoiler:

In eerste instantie had ik de LCM verkeerd berekend, en in plaats van die te debuggen dacht ik dat het wel eens kan zijn dat de herhaling niet vanaf time[0] start (en dus verschillend kan zijn voor x, y, en z). Dus ik de intiele tijd vanaf waar herhaald wordt per richting bepaald, maar daar volgde dus 3 x 0 uit. En ik maar denken; waar zit de fout dat KAN nooit goed zijn, 3 x 0. Blijkt dus wel te kloppen voor de puzzle input in het algemeen, dank voor de uitleg hieronder!

[ Voor 8% gewijzigd door bakkerjangert op 12-12-2019 11:38 ]

[FrankMennink]

bakkerjangert schreef op donderdag 12 december 2019 @ 11:24:
[...]


Ik had zelf al wel bedacht hoe ik deel 2 wilde aanpakken, maar heb er alsnog wel even over gedaan, metname doordat ik door een domme progremeer fout in de verkeerde richting ging denken.

spoiler:

In eerste instantie had ik de LCM verkeerd berekend, en in plaats van die te debuggen dacht ik dat het wel eens kan zijn dat de herhaling niet vanaf time[0] start (en dus verschillend kan zijn voor x, y, en z). Dus ik de intiele tijd vanaf waar herhaald wordt per richting bepaald, maar daar volgde dus 3 x 0 uit. En ik maar denken; waar zit de fout dat KAN nooit goed zijn, 3 x 0. Blijkt dus wel te kloppen voor de puzzle input . Waarschijnlijk omdat anders het antwoord veel lastiger te bepalen is. Zo zie je maar, het had nog ingwikkelder kunnen zijn als time[0] niet het punt zou zijn waarop wordt herhaald.

spoiler:

Omdat je werkt met periodes van herhaling zal het punt waarop de herhaling optreedt altijd punt 0 zijn, Als dat op punt X is dan is namelijk punt X+1 gelijk aan punt 1, X+2 aan punt 2 etc totdat je bij 2X aanbelandt, dan is het weer hetzelfde als punt 0

[Boudewijn]

Ik ben achter mijn denkfout gekomen in 6, door met een sed expressie de file om te zetten in een dot bestand en dat te renderen...


Hmm meerdere parents.

[Hydra]

DataGhost schreef op woensdag 11 december 2019 @ 21:05:
Sure thing. Waarom heb je dan überhaupt regels 29 t/m 37 staan, als je gewoon

code:

var p = rads[199].second.removeAt(0)

had kunnen gebruiken voor hetzelfde resultaat? Wordt 'ie nog sneller van ook.

Omdat ik geen onbeperkte tijd heb de beste oplossing te vinden. Als ik het antwoord heb schoon ik de code op en that's it.

Wat is dit, een ondervraging?

FrankMennink schreef op donderdag 12 december 2019 @ 10:46:
Dag 12 in Python 3

Eerste stap was vrij simpel, tweede stap had ik toch een hint (in spoilers voor anderen die vast zitten) voor nodig van het Internet.

Same here. En ik heb 't ook nog niet geimplementeerd en het ziet er naar uit dat dat ook wel even gaat duren nog. Geen tijd meer gehad vandaag overdag, en vanavond heb ik na 't sporten waarschijnlijk geen zin meer.

[ Voor 36% gewijzigd door Hydra op 12-12-2019 15:59 ]

[BernardV]

Boudewijn schreef op donderdag 12 december 2019 @ 11:51:
Ik ben achter mijn denkfout gekomen in 6, door met een sed expressie de file om te zetten in een dot bestand en dat te renderen...
[Afbeelding]

Hmm meerdere parents.

Weet je zeker dat het niet andersom is? Als ik SS - GD6 - 42 bij je bekijk zou dat een opzichzelfstaand trio zijn.. dat lijkt me ook niet te kloppen.

//EDIT: Part 2 van vandaag valt me zwaar, ik heb wel een aantal ideeën, maar tot nu toe duurt het te lang..

[ Voor 9% gewijzigd door BernardV op 12-12-2019 20:13 ]

[P_Tingen]

Hydra schreef op donderdag 12 december 2019 @ 15:57:
[...]
Same here. En ik heb 't ook nog niet geimplementeerd en het ziet er naar uit dat dat ook wel even gaat duren nog. Geen tijd meer gehad vandaag overdag, en vanavond heb ik na 't sporten waarschijnlijk geen zin meer.

In Progress 4GL (waarin ik werk) kon ik dag 12, deel 2 niet zo makkelijk oplossen (brute force: ~5000 iteraties per seconde ), dus heb ik een externe site erbij gebruikt.

spoiler:

Je moet de fasen opzoeken van X,Y en Z en die in deze site gooien: https://www.calculatorsoup.com/calculators/math/lcm.php en wat er uitkomt is je antwoord

[MerijnB]

P_Tingen schreef op donderdag 12 december 2019 @ 20:21:
[...]

In Progress 4GL (waarin ik werk) kon ik dag 12, deel 2 niet zo makkelijk oplossen (brute force: ~5000 iteraties per seconde ), dus heb ik een externe site erbij gebruikt.

spoiler:

Je moet de fasen opzoeken van X,Y en Z en die in deze site gooien: https://www.calculatorsoup.com/calculators/math/lcm.php en wat er uitkomt is je antwoord

Dat moet in elke taal 😉

Lcm uitrekenen kan je trouwens ook makkelijk vanuit code doen.

[P_Tingen]

Geloof ik graag, maar ik ben daar te lui niet wiskundig genoeg voor.

[ppx17]

Vandaag was niet zo zeer een lastige, maar het eindresultaat ziet er echt leuk uit.

spoiler:

Mits je rond elk input request de map rendered en je autopilot aan het werk ziet natuurlijk.

[ Voor 40% gewijzigd door ppx17 op 13-12-2019 07:45 ]

[Hydra]

Dag 13 in Kotlin

Volledig triviaal en weer IntCode. Meh.

[bakkerjangert]

ppx17 schreef op vrijdag 13 december 2019 @ 07:43:
Vandaag was niet zo zeer een lastige, maar het eindresultaat ziet er echt leuk uit.

spoiler:

Mits je rond elk input request de map rendered en je autopilot aan het werk ziet natuurlijk.

Ziet er inderdaad wel leuk uit. Heb een filmpje van de eerste seconden van mijn run gemaakt. Gebruik gemaakt van Powershell en Powerpoint, exuses voor de kwaliteit. Code is in python 3.7.

https://1drv.ms/v/s!AhHHybHxW427g8kXv8kDhcHfmFqQig?e=qoWlBg

[Ethikka]

Niet al te moeilijk vandaag

spoiler:

Ik patch een muur op de rij van de paddle in mn intcode, gevolg, nooit bewegen met de paddle en toch goede output =)

[veldsla]

Ethikka schreef op vrijdag 13 december 2019 @ 11:46:
Niet al te moeilijk vandaag

spoiler:

Ik patch een muur op de rij van de paddle in mn intcode, gevolg, nooit bewegen met de paddle en toch goede output =)

Dat is ook een goeie hack. Er was in ieder geval weinig slims nodig om te spelend the winnen:

spoiler:

sign(ball[1] - paddle[1])

En wat natuurlijk wel positief is dat we geen veld hoeven parsen, daar werd ik vorig jaar een beetje moe van.

[ProAce]

Kan het kloppen dat niet elke output de positie van de ball weergeeft?
Zonee dan gaat er bij mij iets fout

[armageddon_2k1]

@ProAce Als je in Part 2 bent dan geeft de output ook een score mee.

Ik vond hem erg leuk vandaag en was niet al te moeilijk. Blijft leuk dat mijn IntComputer goed blijft werken.

spoiler:

Ik dacht eerst ik ga hem zelf uitspelen met een scherm, maar toch geen zin in. Simpel de paddle de bal laten volgen.

@Ethikka Dat is een mooie hack!

Wie gaat er trouwens even een compiler maken voor C ofzo met de IntComputer als compilation target?

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

[veldsla]

ProAce schreef op vrijdag 13 december 2019 @ 12:31:
Kan het kloppen dat niet elke output de positie van de ball weergeeft?
Zonee dan gaat er bij mij iets fout

Wel de bal, niet de paddle.

[FrankMennink]

Dag 13 in Python3

was weer een lekker "oh, duh" momentje toen ik eenmaal doorhad hoe ik de paddle moest bewegen. Voor de rest een prima puzzle voor tijdens de lunch

ProAce schreef op vrijdag 13 december 2019 @ 12:31:
Kan het kloppen dat niet elke output de positie van de ball weergeeft?
Zonee dan gaat er bij mij iets fout

Ja dat kan kloppen, lees het stukje met de segment display nog eens door.

[ProAce]

FrankMennink schreef op vrijdag 13 december 2019 @ 13:30:
Dag 13 in Python3
[...]


Ja dat kan kloppen, lees het stukje met de segment display nog eens door.

Ik haal de score er uit, maar zie niet helemaal wat dat te maken heeft met de bal.

So far krijg ik dit er uit, doordat de bal alleen op het laatst zijn positie update gaat het een beetje mis

[ThaStealth]

ProAce schreef op vrijdag 13 december 2019 @ 12:31:
Kan het kloppen dat niet elke output de positie van de ball weergeeft?
Zonee dan gaat er bij mij iets fout

Volgens mij zit een 'bug' in de output (wat volgens mij expres is):

spoiler:

Ik merkte dit bij het verwerken van de resultaten, in een 'iteratie' word de positie van de bal gezet, maar daarna overschreven door een volgend resultaat.

Ik had in eerste instantie het bepalen van de locatie van de bal tijdens het verwerken van iedere losse x,y,val set. Naderhand wilde ik dit eruit halen en de bal in mijn data na iedere volledige verwerking van alle coördinaten, waarbij ik tegen het probleem liep dat de bal soms niet te vinden is, en het batje niet snel genoeg verplaatst kan worden nadat de bal weer zichtbaar word.

ProAce schreef op vrijdag 13 december 2019 @ 14:19:
[...]


Ik haal de score er uit, maar zie niet helemaal wat dat te maken heeft met de bal.

spoiler:

Hij bedoelt dat je niet iedere keer een volledig nieuw frame krijgt, maar alleen de veranderde 'pixels', met de bal heeft dit niets te maken, wel met het batje als je een 0 gestuurd hebt bij de vorige iteratie

[ Voor 22% gewijzigd door ThaStealth op 13-12-2019 14:25 ]

[ProAce]

ThaStealth schreef op vrijdag 13 december 2019 @ 14:22:
[...]

Volgens mij zit een 'bug' in de output (wat volgens mij expres is):

spoiler:

Ik merkte dit bij het verwerken van de resultaten, in een 'iteratie' word de positie van de bal gezet, maar daarna overschreven door een volgend resultaat.

Ik had in eerste instantie het bepalen van de locatie van de bal tijdens het verwerken van iedere losse x,y,val set. Naderhand wilde ik dit eruit halen en de bal in mijn data na iedere volledige verwerking van alle coördinaten, waarbij ik tegen het probleem liep dat de bal soms niet te vinden is, en het batje niet snel genoeg verplaatst kan worden nadat de bal weer zichtbaar word.

spoiler:

als ik over mijn output heen loop krijg ik maar twee keer een ball positie binnen (start en af), terwijl als ik kijk naar de oplossingen van anderen dan lijkt het zo te zijn dat die voor elke vraag om input een nieuwe ball positie krijgen.

spoiler:

Hij bedoelt dat je niet iedere keer een volledig nieuw frame krijgt, maar alleen de veranderde 'pixels', met de bal heeft dit niets te maken, wel met het batje als je een 0 gestuurd hebt bij de vorige iteratie

spoiler:

Ah op die manier, dat word al netjes afgehandeld. Heb een map met alle elementen, hiervan update ie alleen de punten die in de laatste output staan.

[ThaStealth]

ProAce schreef op vrijdag 13 december 2019 @ 14:28:
[...]

spoiler:

als ik over mijn output heen loop krijg ik maar twee keer een ball positie binnen (start en af), terwijl als ik kijk naar de oplossingen van anderen dan lijkt het zo te zijn dat die voor elke vraag om input een nieuwe ball positie krijgen.

[...]

spoiler:

Ah op die manier, dat word al netjes afgehandeld. Heb een map met alle elementen, hiervan update ie alleen de punten die in de laatste output staan.

spoiler:

De bal komt in het begin ieder frame (in ieder geval tot je het eerste blokje geraakt hebt). Zeker weten dat je niet bal en batje omgedraaid hebt?

[ProAce]

ThaStealth schreef op vrijdag 13 december 2019 @ 14:31:
[...]

spoiler:

De bal komt in het begin ieder frame (in ieder geval tot je het eerste blokje geraakt hebt). Zeker weten dat je niet bal en batje omgedraaid hebt?

spoiler:

Pretty sure, misschien dat iemand mijn input zou kunnen testen om te kijken of het dan wel werkt . https://github.com/ProAce...2019/Day_13/Challenge%202

[diabolofan]

Dag 13 ook klaar. Ook een visualisatie van het board in de console laten printen, maar daar hield ik steeds een paar blocks over terwijl het intcode programma een 99 had. Dus ik dacht dat er iets nog niet goed zat. Toen ik niet kon vinden toch maar gewoon geprobeerd om de score die ik op dat moment had in te voeren als antwoord, en dit bleek gewoon goed te zijn.. Is bij jullie wel heel het bord leeg neem ik aan? En heb ik dus nog een bugje in mijn visualisatie?

Edit:
Sowieso zit er wel iets vreemds in: Ik tel het aantal blokken wat er initieel geplaatst wordt, en wanneer ik een block verwijder trek ik deze van het aantal af. Aan het eind staat dit aantal alleen nog lang niet op nul (maar op 195) terwijl het bord er nog maar 5 toont. Dus er lijken diverse stappen geskipped te worden.

[ Voor 26% gewijzigd door diabolofan op 13-12-2019 14:43 ]

[DataGhost]

ProAce schreef op vrijdag 13 december 2019 @ 14:37:
[...]

spoiler:

Pretty sure, misschien dat iemand mijn input zou kunnen testen om te kijken of het dan wel werkt . https://github.com/ProAce...2019/Day_13/Challenge%202

Kijk eens wat voor outputs je allemaal krijgt na een input. Je vergeet ergens iets te doen. Not sure of dat je hele probleem is maar het is een begin. Ik vind het dan wel raar dat je de visualisatie eruit krijgt die je eruit hebt gekregen. Door een unrelated bug in mijn eerste code deed ik een (blijkt) onterechte aanname.
Ik begrijp ook niet helemaal waarom je opcode 3 in elkaar zit zoals 'ie in elkaar zit, maar dat zou denk ik niet uit mogen maken als je netjes inputs stuurt op de momenten dat het nodig is.

[ Voor 12% gewijzigd door DataGhost op 13-12-2019 17:25 ]

[veldsla]

ProAce schreef op vrijdag 13 december 2019 @ 14:37:

spoiler:

Pretty sure, misschien dat iemand mijn input zou kunnen testen om te kijken of het dan wel werkt . https://github.com/ProAce...2019/Day_13/Challenge%202

Geen idee waarom je input.txt url een spoiler is, maar hij doet het bij mij prima.

edit
Sowieso is de spoiler implementatie van het forum nogal...ehm...slecht. Een dossier van de belastingdienst is er niks bij

[ Voor 14% gewijzigd door veldsla op 13-12-2019 14:57 ]

[ProAce]

DataGhost schreef op vrijdag 13 december 2019 @ 14:46:
[...]

Kijk eens wat voor outputs je allemaal krijgt na een input. Je vergeet ergens iets te doen. Not sure of dat je hele probleem is maar het is een begin. Ik vind het dan wel raar dat je de visualisatie eruit krijgt die je eruit hebt gekregen. Ik begrijp ook niet helemaal waarom je opcode 3 in elkaar zit zoals 'ie in elkaar zit, maar dat zou denk ik niet uit mogen maken als je netjes inputs stuurt op de momenten dat het nodig is.

Fixed it, for some reason had had ik aan het begin bedacht dat ik niet over de laatste drie indexes van mijn output heen zou moeten lopen, en daar stond de bal in.

[Daanoz]

Ik vond dit wel een toffe dag, misschien niet super ingewikkeld, maar wel leuk om te zien dat je met een dergelijke IntCodeProcessor toch daadwerkelijk dingen gebouwd krijgt. Ook trouwens wel respect voor degene die dit in "IntCode" gebouwd heeft... Iemand die nog een uitdaging zoekt? Los dan de volgende puzzels maar op in "IntCode" .

Owja, en natuurlijk: https://github.com/daanoz...ob/master/TS/13/partb.gif

[Vuikie]

YAY, de eerste dag volbracht, 2 sterren verdient

[TomsDiner]

Daanoz schreef op vrijdag 13 december 2019 @ 21:09:
Ik vond dit wel een toffe dag, misschien niet super ingewikkeld, maar wel leuk om te zien dat je met een dergelijke IntCodeProcessor toch daadwerkelijk dingen gebouwd krijgt. Ook trouwens wel respect voor degene die dit in "IntCode" gebouwd heeft... Iemand die nog een uitdaging zoekt? Los dan de volgende puzzels maar op in "IntCode" .

Dit is precies wat ik dacht. Ze laten je zelf een computertje bouwen met momenteel ik geloof negen commando's.

Ik ben een verwend joch met allemaal moderne talen om te gebruiken. Mijn vader werkte met oa assembler en met ponskaarten systemen vanaf de jaren '70, die vind het weer heel logisch dat dit soort zaken kunnen, maar ikzelf sta er toch even van te kijken.

Ik heb dag 1 - 13 in php opgelost, en eigenlijk wilde ik dit spel ook wel even in werking zien. Ik heb zelfs overwogen om de intcomputer een dump mogelijkheid te geven (alle variabelen en geheugen in een string), deze mee te zenden naar de browser, en in een volgende "zet" de string weer in te laten lezen door de intcomputer (vanuit de browser), zodat deze exact weer verder gaat waar die gebleven was.

Ik heb het niet gedaan, maar omdat we statistisch om de dag een opgave met de intcomputer krijgen is de kans vrij groot dat er binnenkort echte userinteractie nodig is, en dan is bovenstaande oplossing denk ik noodzakelijk voor php.

[Hydra]

diabolofan schreef op vrijdag 13 december 2019 @ 14:37:
Is bij jullie wel heel het bord leeg neem ik aan?

Geen idee, ik heb uberhaupt geen visualisatie gemaakt en in deel twee ook de blokken niet geteld.

Daanoz schreef op vrijdag 13 december 2019 @ 21:09:
Ik vond dit wel een toffe dag, misschien niet super ingewikkeld, maar wel leuk om te zien dat je met een dergelijke IntCodeProcessor toch daadwerkelijk dingen gebouwd krijgt. Ook trouwens wel respect voor degene die dit in "IntCode" gebouwd heeft...

De maker heeft het niet direct in intcode gebouwd. IntCode is, zoals bytecode dat voor Java is, de output van een compiler.

[ Voor 48% gewijzigd door Hydra op 13-12-2019 23:54 ]

[Daanoz]

Hydra schreef op vrijdag 13 december 2019 @ 23:53:
De maker heeft het niet direct in intcode gebouwd. IntCode is, zoals bytecode dat voor Java is, de output van een compiler.

Ah ja, dat klinkt wel logisch. Zou mooi zijn als hij daar een stukje van zou laten zien.

Hoe hebben jullie deel 2 vandaag gedaan?

spoiler:

In theorie zou je deel 1 andersom kunnen implementeren, maar dat leek mij relatief veel werk, dus heb uiteindelijk gewoon bruteforce met de functionaliteit van deel 1, deel 2 berekend (eg. hoeveel ore heb ik nodig voor x fuel)... Met wat trucs nog steeds in ~65ms.

[armageddon_2k1]

Hmm.... ik kom er niet helemaal uit vandaag. Vaag, want het lijkt me niet zo'n moeilijke...... De eerste tests gaan goed, maar die laatste test niet. Ik zit elke keer te hoog.

spoiler:

Ik moet natuurlijk rekening houden met hoeveelheden die overblijven.... Bedenk ik me nu

[ Voor 24% gewijzigd door armageddon_2k1 op 14-12-2019 12:33 ]

[FrankMennink]

Dag 14 in Python 3

Over beide stukken toch wel een goed halfuurtje gedaan per stuk.

spoiler:

Deel 2 proberen te brute-forcen door elke keer 1 fuel uit te rekenen en dan de leftovers te houden. Was opzich niet zo heel handig en zou veel te lang duren. Uiteindelijk opgelost door de echte hoeveelheid ore die nodig is te berekenen ipv hele reacties. Daardoor werd het een simpele deling

waardoor mn programma deel 2 berekent in minder dan 1ms

[Soultaker]

Hydra schreef op vrijdag 13 december 2019 @ 23:53:
De maker heeft het niet direct in intcode gebouwd. IntCode is, zoals bytecode dat voor Java is, de output van een compiler.

Ik denk dat 'ie inderdaad niet direct in intcode werkt, maar dat betekent niet per se dat hij een compiler voor een high-level taal als Java geschreven heeft. De code is vrij compact. Hij kan dus ook gewoon een soort assembler geschreven hebben, en redelijk dicht bij de intcode-machine blijven.

De programma's die we tot nu toe gezien hebben waren ook relatief eenvoudig. Ik denk dus niet dat hij recursie gebruikt, of lokale variabelen, en dan kan alles vrij simpel blijven. (Maar ik moet zeggen dat ik niet in detail naar de gegenereerde intcode heb gekeken.)

Daanoz schreef op zaterdag 14 december 2019 @ 10:40:
Hoe hebben jullie deel 2 vandaag gedaan?

spoiler:

Binary search.

(code). Dat leek me de snelste manier om de bestaande oplossing voor deel 1 uit te breiden.

[diabolofan]

FrankMennink schreef op zaterdag 14 december 2019 @ 12:56:

spoiler:

Deel 2 proberen te brute-forcen door elke keer 1 fuel uit te rekenen en dan de leftovers te houden. Was opzich niet zo heel handig en zou veel te lang duren. Uiteindelijk opgelost door de echte hoeveelheid ore die nodig is te berekenen ipv hele reacties. Daardoor werd het een simpele deling waardoor mn programma deel 2 berekent in minder dan 1ms

spoiler:

Hoe ga je dan om met je restproducten die je de volgende cycle weer moet gebruiken? De echte hoeveelheid ore per FUEL kan ik namelijk naar mijn idee niet zo makkelijk uitrekenen. Of sla je dit op als kommagetallen per chemical oid?

[Soultaker]

FrankMennink schreef op zaterdag 14 december 2019 @ 12:56:

spoiler:

Deel 2 proberen te brute-forcen door elke keer 1 fuel uit te rekenen en dan de leftovers te houden. Was opzich niet zo heel handig en zou veel te lang duren. Uiteindelijk opgelost door de echte hoeveelheid ore die nodig is te berekenen ipv hele reacties. Daardoor werd het een simpele deling

Toch is dit niet correct.

Bijvoorbeeld bij deze invoer is het juiste antwoord 100 (voor deel 2), maar jouw oplossing zegt 133.

[FrankMennink]

diabolofan schreef op zaterdag 14 december 2019 @ 13:29:
[...]

spoiler:

Hoe ga je dan om met je restproducten die je de volgende cycle weer moet gebruiken? De echte hoeveelheid ore per FUEL kan ik namelijk naar mijn idee niet zo makkelijk uitrekenen. Of sla je dit op als kommagetallen per chemical oid?

spoiler:

Er blijven na de reactie geen restproducten over omdat ik kommagetallen gebruik om de effectieve ORE kost te berekenen van de hele reactie. Er zijn meerdere methodes om dit te doen, ik heb gekozen om de reactie X keer uit te voeren. Voor deel 1 rond ik deze af naar boven, voor deel 2 gebruik ik het fractionele getal. In theorie (ongetest) zou je ook de reacties terug kunnen rekenen naar xA, yB => 1C en deze dan gebruiken als reactie set, maar dat was meer werk

Soultaker schreef op zaterdag 14 december 2019 @ 13:32:
[...]

Toch is dit niet correct.

Bijvoorbeeld bij deze invoer is het juiste antwoord 100 (voor deel 2), maar jouw oplossing zegt 133.

Het juiste antwoord voor die input is niet 100.

spoiler:

Je gebruikt 0,01+0,01+0,01A voor elke fuel. Even nullen weghalen, krijg je 25ORE voor 1A. Als je dan 100 ORE hebt, kan je 4 keer A maken. Elke fuel gebruikt 0,03A. 4/0,03 afgerond naar beneden (want je kan alleen maar hele FUEL objecten maken) is 133

[ Voor 4% gewijzigd door FrankMennink op 14-12-2019 14:02 . Reden: typo ]

[Soultaker]

FrankMennink schreef op zaterdag 14 december 2019 @ 13:54:
Het juiste antwoord voor die input is niet 100.

Welles

spoiler:

Je gebruikt 0,01+0,01+0,01A voor elke fuel.

Daar zit je al fout.

spoiler:

Je kunt geen 1 FUEL maken met 0,03 A. Je kunt alleen 100 FUEL maken met 3 A.

Bekijk het van de andere kant. Met 1.000.000.000.000 ORE kun je 4 A maken (en niets anders). Met 3 A kun je vervolgens 100 B, 100 C en 100 D maken, en daarmee kun je weer 100 FUEL maken. Daarna heb je 1 A over, maar die kun je niet verdelen over B, C en D, zoals jij wil. Je kunt dus óf 100 B, óf 100 C, óf 100 D maken, maar niet 33 van elk.

In de opdracht staat specifiek:

spoiler:

Each reaction gives specific quantities for its inputs and output; reactions cannot be partially run, so only whole integer multiples of these quantities can be used.

[ Voor 3% gewijzigd door Soultaker op 14-12-2019 14:42 ]

[DataGhost]

Dat je in een geval de juiste output krijgt wil niet zeggen dat je algoritme correct is

[FrankMennink]

DataGhost schreef op zaterdag 14 december 2019 @ 14:48:
Dat je in een geval de juiste output krijgt wil niet zeggen dat je algoritme correct is

niet alleen in 1 geval, de 3 voorbeelden gaan ook prima. Ik zie meerdere mensen dit ook zo oplossen. Zal wel iets in de generator van de puzzel zitten dat t mogelijk maakt

[DataGhost]

Juist met dit soort challenges worden de voorbeelden vaak zo gemaakt dat naïeve, foute oplossingen toch een goed antwoord geven waarop de uiteindelijke testinvoer alle vage randgevallen/uitzonderingen bevat en een verkeerd resultaat oplevert. Bij AoC is dat wat minder het geval maar dat komt misschien doordat je de uiteindelijke testinvoer ook zelf te zien krijgt en daar dus op kan debuggen. Maar ik ben gewend dat je programma gewoon gedraaid wordt op voor jou onbekende invoer, en je alleen maar te zien krijgt of je antwoord klopt of niet. Daarom is het belangrijk de opdracht goed te lezen zodat je niet per ongeluk shortcuts neemt (zoals deze) die eigenlijk niet kunnen werken.

[diabolofan]

Day 12 op een oscilloscope: https://twitter.com/vcazacov/status/1205261123244695552

En iemand heeft de Intcode reverse-engineerd dmv Excel: https://www.reddit.com/r/...d_to_the_creators_of_aoc/

[ Voor 49% gewijzigd door diabolofan op 14-12-2019 17:48 ]

[armageddon_2k1]

Eindelijk dag 14 afgerond. Vond hem niet relax, omdat mijn brein gewoon niet werkte.

spoiler:

Part 2 uiteindelijk gedaan met een lineaire interpolatie. Eerst Ore voor Fuel = 1 en voor Fuel = 10000 uitgerekend. Toen gewoon gegokt waar je uit moet komen en vanaf daar de fuel met stapjes van 1 of -1 veranderen....

[GeertenVink]

Hoera, global leaderboard punten vandaag. (#90/108). Lag vermoed ik vooral aan een goede opzet van mijn IntCode machine, waardoor sommige dingen makkelijk te doen zijn.

spoiler:

Ik kon gewoon BFS doen waar elke "plek" in het doolhof een eigen kopie van het IntCode programma had, dat gewoon door kan draaien vanaf die plek. Feitelijk branch ik de executie van het programma gewoon, en heb ik uiteindelijk een soort extreem multithreaded IntCode waar elke thread een stap doet.

Voor part 2 heb ik gewoon het programma op de eindplek gepakt, en nog een keer BFS gedraaid het hele doolhof door. Laatste in de queue is degene die het langst gelopen heeft dus de path length naar die plek is het antwoord.

[ Voor 5% gewijzigd door GeertenVink op 15-12-2019 08:09 ]

[veldsla]

Ben ook weer bij. Dag 14 zat ik toch wel een tijdje te prutsen met de condities om te queuen, maar ben er wel uitgekomen. Vandaag ook getwijfeld of ik mijn Intcode runner zou aanpassen

spoiler:

om the kunnen forken, maar uiteindelijke toch maar aan backtracking gedaan.
En inderdaad bfs voor deel 2

[DRaakje]

armageddon_2k1 schreef op zaterdag 14 december 2019 @ 20:08:
Eindelijk dag 14 afgerond. Vond hem niet relax, omdat mijn brein gewoon niet werkte.

spoiler:

Sneller is een binary search

[JeroenTheStig]

Mijn achterstand is weer bijna weggewerkt. Zojuist part 1 van vandaag (dag 15) opgelost. Wel erg tof om te zien dat ik na de eerste keer starten slechts één bug heb moeten wegwerken. Bij het bepalen van de fewestSteps begin ik altijd op Long.MAX_VALUE. Als je dan verderop in de code 1 er bij op telt, dan krijg je een long overflow en gaat de code zijn eigen leven leiden.

Nu op naar part 2.

[armageddon_2k1]

DRaakje schreef op zondag 15 december 2019 @ 18:42:
[...]

spoiler:

Sneller is een binary search

Dat kan best wezen maar ik zit toch al dik onder de 100ms,dus dan vind ik het wel welletjes

[GeertenVink]

Hot damn wat een probleem vandaag. Ik heb het idee dat er een hoop meer wiskundekennis gevraagd wordt dit jaar. (En die heb ik niet echt). Gelukkig was het ook zonder wiskunde op te lossen.

[Hydra]

Meh. Deel 1 van dag 16 werkt bij mij op alle input, alleen niet op m'n echte input. Geen idee waarom. Zucht.

[Sjaaky]

Heb ik ook regelmatig last van. Meestal omdat ik de newline aan het einde - '0' doe en als -38 aan mijn input toevoeg.

[FrankMennink]

Dag 16 in Python3

Eerste deel brute force opgelost, dat kon nog wel, daarna de * 10000 gezien voor het tweede deel. Geprobeerd deel 1 wat sneller te maken, uiteindelijk gelukt dat ie binnen een seconde het antwoord er uit gooit. Het tweede deel daarentegen krijg ik niet beter dan ongeveer een minuut. Vind het voor nu wel prima Edit: Na quick inspection mn code toch nog iets sneller gekregen, doet nu 250-275ms over deel 1, 12-13 seconden over deel 2.

[ Voor 25% gewijzigd door FrankMennink op 16-12-2019 16:54 ]

[armageddon_2k1]

Deel twee echt geen idee hoe ik die efficiënt kan doen nog...

spoiler:

Vanwege de aard van het pattern kan je natuurlijk wel afschatten dat de eerste .... (afhankelijk van de eerste 7 digits van je input) totaal niet mee doen en de laatste .... ook niet.

Maar m'n brein werkt niet meer na een dag werken.

[ Voor 68% gewijzigd door armageddon_2k1 op 16-12-2019 16:57 ]

[FrankMennink]

armageddon_2k1 schreef op maandag 16 december 2019 @ 16:23:
Deel twee echt geen idee hoe ik die efficiënt kan doen nog...

spoiler:

Vanwege de aard van het pattern kan je natuurlijk wel afschatten dat de eerste .... (afhankelijk van de eerste 7 digits van je input) totaal niet mee doen en de laatste .... ook niet.

Maar m'n brein werkt niet meer na een dag werken.

spoiler:

Je bent al een behoorlijk stuk in de goede richting aan het denken qua het eerste.

[DataGhost]

Ik had dus voor het eerst de opgave niet goed gelezen, en dacht dat

spoiler:

de 7 offset-digits uit de output moesten komen ipv de input.

Dat maakt toch een significant verschil vwb implementatie.

[CMG]

Vandaag eindelijk weer eens een simpele deel 1 dan, deel twee wordt volgens mij weer erg tricky, maar daar heb ik vanavond pas weer tijd voor

[ThaStealth]

Ik kon me vandaag wel op mijn kop slaan bij deel 1, ik kreeg iedere keer het foute antwoord uit, op een gegeven moment zoveel variaties geprobeerd dat ik niet meer wist wat de goede oplossing was. Ik heb uiteindelijk 'gecheat' door iemand zijn anders zijn oplossing te pakken en mijn input te gebruiken, om te kijken wat de goede waarde moest zijn (heb de waarde pas ingevuld toen ik ook in mijn applicatie de uitkomst kreeg). De uitkomst van de andere implementatie bleek zover van mijn antwoord af te liggen dat ik beide maar naast elkaar heb laten lopen om te kijken wat de plaatjes waren die eruit kwamen (en waar mijne de mist inging).

Wat bleek nu,

spoiler:

de IntCodeVM van mij heeft een Stack<long> als "outputbuffer". Onderdeel van een stack is natuurlijk dat het een FILO buffer is, terwijl ik in mijn code ervanuit ging dat het een FIFO buffer aan het gebruiken was.... Oftwel, mijn "camerabeeld" was geflipped en gemirrored waardoor de X * Y berekening dus ook mis ging...

Een simpele Reverse() en

daarna werkte mijn versie ook.

Ben wel een beetje klaar met die IntCode opdrachten, denk dat die van overmorgen wel een IntCode applicatie zal zijn die te traag loopt als je hem in de VM draait, waardoor je zelf door de instructies moet gaan spitten om te kijken wat het ding nu aan het doen is en daar een applicatie voor schrijven ipv de VM te gebruiken

[ Voor 13% gewijzigd door ThaStealth op 17-12-2019 14:46 ]

[CMG]

Ik heb deel 2 maar even met de hand gedaan; code geschreven om de instructies te laten berekenen en daarna met de hand de ABC routine uitgesplitst. Als ik een keer meer tijd heb, ga ik dat ook nog wel maken denk ik.

spoiler:

Tipje: bij mij moest ik een lagere herhalende routine in 2e splitsen omdat een sub-onderdeel vaker terug kwam dan de hele grote herhaling om alles met ABC te kunnen doen.

[veldsla]

CMG schreef op dinsdag 17 december 2019 @ 15:01:
Ik heb deel 2 maar even met de hand gedaan; code geschreven om de instructies te laten berekenen en daarna met de hand de ABC routine uitgesplitst. Als ik een keer meer tijd heb, ga ik dat ook nog wel maken denk ik.

* veldsla is hier ook schuldig aan