Advent of Code 2018

[Gropah]

heuveltje schreef op dinsdag 11 december 2018 @ 11:40:
Even zeker weten dat ik vraag 11. deel 1 goed begrijp.
puzzel input is dus een 5 cijferig getal.

Dus eerst genereer je uit dat getal , een array van 300*300 met de individuele celwaardes.
En dan ga je binnen dat array zoeken naar het 3x3 blok met de hoogste totaal som ?

Yup, klopt. Maar het getal hoeft niet 5 groot te zijn. Ik kan ook zeker aanraden om de voorbeelden uit de vraag te gebruiken om te controleren of je programma klopt

[heuveltje]

Gropah schreef op dinsdag 11 december 2018 @ 11:45:
[...]

Yup, klopt. Maar het getal hoeft niet 5 groot te zijn. Ik kan ook zeker aanraden om de voorbeelden uit de vraag te gebruiken om te controleren of je programma klopt

Dank je , en dat ga ik ook zeker doen.
Maar om een of andere reden kreeg ik de vraagstelling niet helemaal duidelijk in mijn hoofd, de eerste 20 keer dat ik het las.Dus ik denk voor ik 3 uur verder ben, en dan erachter kom dat ik het alsnog verkeerd geinterpreteerd had

[ppx17]

bernardV schreef op dinsdag 11 december 2018 @ 10:27:
[...]

Hij werkt niet goed bij mijn input '5468'.

spoiler:

Part 1 is goed, part 2 niet, dat moet zijn: 90,101,15 en je code geeft 237,249,11

spoiler:

Ik heb een aanname gedaan dat het grootste powergrid niet groter kan zijn dan de wortel van de gridsize (300), tot nu toe lijkt dat goed, maar ik kan het niet wiskundig onderbouwen.

spoiler:

Inderdaad, de code gaat uit dat de square 1 omslagpunt heeft en vanaf daar alleen maar kleiner wordt, maar als ik hem met jouw input draai is dat niet zo. Na 11 word hij even kleiner om vervolgens bij 14 weer groter te worden. Even kijken hoe de code vlot blijft en dit kan handelen..

Size: 1 Highest 4
Size: 2 Highest 16
Size: 4 Highest 35
Size: 5 Highest 43
Size: 6 Highest 47
Size: 7 Highest 64
Size: 8 Highest 68
Size: 9 Highest 76
Size: 10 Highest 86
Size: 11 Highest 92
Size: 12 Highest 91
Size: 13 Highest 81
Size: 14 Highest 83
Size: 15 Highest 119
Size: 16 Highest 106
Size: 17 Highest 100
Part 2: 90,101,15

[veldsla]

Hmm, brute force over alles op 0.8s Voor nu ok. SAT versie ook gemaakt. 18ms elegant algoritme, had ik eigenlijk zelf moeten bedenken

[ Voor 64% gewijzigd door veldsla op 11-12-2018 20:37 ]

[BernardV]

Summed area table versie in PHP: https://pastebin.com/sJEGYcJR

spoiler:

Input: 5468
Resultaat:
Part 1: 243,64
Part 2: 90,101,15
This process used 262 ms for its computations
It spent 1 ms in system calls

[emnich]

Mooi @bernardV !

[Hydra]

Dag 11 in Kotlin

Moet alleen nog ff m'n brute-force aanpak omschrijven, deel 2 duurt nu 58s. Misschien heb ik daar vanavond tijd voor.

[BernardV]

Wat mij wel opviel over de input is

spoiler:

Dat alleen de laatste 3 cijfers er toe doen, doordat je het 100-tal moet pakken. Dus als je alleen de laatste 3 cijfers van je input pakt is het identiek aan een groter getal waarbij de laatste cijfers gelijk zijn.
Dus 5468 is identiek aan 468

spoiler:

Ik kan zeggen dat mijn aanname om te wortel te nemen niet correct is. Serial 3 heeft het grootste powergrid en serial 20 het kleinste.

Resultaten voor serial 0-999: https://pastebin.com/M70uYSnG
Wat opvalt is dat voor part 1 x er slechts 21 verschillende resultaten zijn.

[ Voor 33% gewijzigd door BernardV op 11-12-2018 15:47 ]

[ProAce]

Beetje laat, maar ik ben vandaag ook begonnen. Inmiddels tot dag 3 opgelost in Go.
Eens kijken hoever ik kom, zonder de belemmering van jaren codeer ervaring (codeer nu 2 maanden in Go)

https://github.com/ProAce/Advent-of-code-18

[Anoniem: 1004565]

Wat krijgen jullie voor de input `4842` bij deel 2?
met mn eigen programma krijg ik `237, 281, 10`, dit is fout. (https://github.com/DutchG...aster/day11_2/src/main.rs )
Met iemand anders zn programma (https://www.reddit.com/r/...utions/ebjoinm/?context=3) krijg ik `236, 280, 10`, en dit is ook fout.

Het gekke is dat mijn programma wel met de juiste outputs komt voor de voorbeelden.

[ Voor 23% gewijzigd door Anoniem: 1004565 op 11-12-2018 16:50 ]

[emnich]

@Anoniem: 1004565 Ik krijg ook 237,281,10. In je antwoord die je hier plaatst zit nog een spatie voor de 10. Ik weet niet of dat uit maakt?

[Anoniem: 1004565]

EDIT: HET ANTWOORD MOET ZONDER SPATIES (@*&$(*&@#$

[Hydra]

Wel duf dat 'ie dat er niet ff uithaalt...

[BernardV]

@Anoniem: 1004565 dank voor je input van 4842
Dat bevestigd nogmaals mijn bevinding dat alleen de laatste 3 getallen belangrijk zijn. Uit de lijst die ik een paar posts hierboven heb geplaatst:

842 : p1: 20,83 p2: 237,281,10

[Soultaker]

bernardV schreef op dinsdag 11 december 2018 @ 17:52:
Dat bevestigd nogmaals mijn bevinding dat alleen de laatste 3 getallen belangrijk zijn.

Dat is logisch. De formule voor de hoeveelheid brandstof is te "versimpelen" tot:

spoiler:

(x*x*y + 20*x*y + + 100*y + serial_no*x + 10*serial_no)%1000 // 100 - 5

(waarbij % de modulus-operator is, die de rest na deling geeft, en // deelt met afronden naar beneden).

Het eerste deel van de expressie kun je herschrijven tot:
• (a + b*serial_no)%1000 (waarbij a en b alleen van x en y afhankelijk zijn)
Vervolgens kun je serial_no schrijven als:
• serial_no = 1000*c + d (waarbij 0 ≤ d < 1000)
En dan:
• (a + b*serial_no)%1000 = (a + b*(1000*c + d))%1000 = (a + 1000*b*c + b*d)%1000 = (a + b*d)%1000.

Vandaar dat alleen de laatste drie cijfers van serial_no er toe doen.

[Lye]

Vandaag was leuk.

spoiler:

Ik had het summed-area table idee zelf ook al bedacht (wist alleen niet dat het zo genoemd werd).

Mijn eerste implementaties waren echter niet echt om over naar huis te schrijven en waren met 1,5 seconden nog steeds vrij traag. Een beetje optimaliseren hier en daar en het draait als een zonnetje .

[ZieglerNichols]

Dag 12 in Matlab: https://pastebin.com/P4P5qt8z

spoiler:

Ik had gelukkig snel door dat deel 2 niet te brute forcen was, dus maar even naar de trend gekeken

Hier een visualisatie van mijn plantjes: https://imgur.com/a/TO30QYQ

[ Voor 17% gewijzigd door ZieglerNichols op 12-12-2018 08:41 ]

[BernardV]

Mijn oplossing in PHP: https://pastebin.com/2sVi7CHq

spoiler:

Ik heb net als @ZieglerNichols naar de trend gekeken, deze wordt constant na een tijdje.

//EDIT: Nieuwe paste, optimalisatie.

[ Voor 14% gewijzigd door BernardV op 12-12-2018 09:10 ]

[emnich]

Day 12 in PHP. Misschien niet het mooiste maar het werkt

spoiler:

Ik heb niet naar de diff gekeken maar of de string veranderd. Als deze niet veranderd is in een generatie (behalve misschien opgeschoven) dan zal hij ook in de toekomstige generaties niet veranderen.

[ Voor 45% gewijzigd door emnich op 12-12-2018 09:11 ]

[BernardV]

@emnich Mooie oplossing voor de padding!

[Hydra]

Ugh. Compleet vastgelopen op Dag 12 part 2, verkeerde oplossingsrichting uitgedacht. Pas door oplossingen van anderen te bekijken kwam ik eruit. Bah.

Dag 12 in Kotlin

[ZieglerNichols]

Ik vond de vraagstelling niet heel duidelijk vandaag:

spoiler:

Het is vreemd dat ze in de echte puzzel-input voor dag 12 ook de regels geven voor combinaties die leiden tot geen plant, zoals '#.##. => .'
Ik heb al deze regels eruit gegooid en gezegd dat als er geen matchende rule is dat de plant dan verdwijnt. Dat werkt ook prima, net zoals in het voorbeeld. Scheelt ook weer wat rekentijd.

[Soultaker]

ZieglerNichols schreef op woensdag 12 december 2018 @ 13:10:
Ik vond de vraagstelling niet heel duidelijk vandaag: Het is vreemd dat ze in de echte puzzel-input voor dag 12 ook de regels geven voor combinaties die leiden tot geen plant, zoals '#.##. => .'

(Zonder spoiler tags want dit lijkt me niet echt spoiler-waardig.) Dat stond duidelijk zo in de tekst:

For brevity, in this example, only the combinations which do produce a plant are listed. (Your input includes all possible combinations.)

Alleen de patronen die een plant produceren geven had ook gekund, maar dan heb je het deel rechts van de pijl ook niet nodig.

Trouwens (spoiler voor deel 2):

spoiler:

voor mijn invoer repeteerde het patroon met een periode van 1, wat het makkelijk maakte om het patroon te zien. Gold dat voor iedereen of heb ik mazzel gehad?

[ Voor 3% gewijzigd door Soultaker op 12-12-2018 13:17 ]

[Gropah]

Soultaker schreef op woensdag 12 december 2018 @ 13:17:
[...]

Trouwens (spoiler voor deel 2):

spoiler:

voor mijn invoer repeteerde het patroon met een periode van 1, wat het makkelijk maakte om het patroon te zien. Gold dat voor iedereen of heb ik mazzel gehad?

spoiler:

Bij mij was dat ook zo en heb meer mensen gezien voor wie dat zo was. Maar het vinden van een periode is ansich niet zo heel moeilijk, wel berekeningsintensief.

[ZieglerNichols]

Soultaker schreef op woensdag 12 december 2018 @ 13:17:
[...]

Alleen de patronen die een plant produceren geven had ook gekund, maar dan heb je het deel rechts van de pijl ook niet nodig.

Dat is precies wat ik verwarrend vond. Waarom extra regels meegeven t.o.v. het voorbeeld als je die regels vervolgens helemaal niet nodig hebt? Maar ja, het is uiteindelijk wel gelukt, en nog vrij snel ook ;-)

[Hydra]

Dag 11 gerefactored naar een eigen implementatie van Summed-area table, van 60 sec naar 300ms. Nice

[Boudewijn]

ik doe het rustig aan met op dit moment 8 sterren. ben wel blij dat het grote parsing feest een beetje over lijkt te zijn.
Ben nu 7b aan het schrijven .

[Hydra]

Boudewijn schreef op woensdag 12 december 2018 @ 19:17:
ik doe het rustig aan met op dit moment 8 sterren. ben wel blij dat het grote parsing feest een beetje over lijkt te zijn.

Oh sweet summer child...

[farlane]

code:

error[E0596]: cannot borrow immutable indexed content as mutable

Gdvrgdmfckndie...

[Anoniem: 159174]

farlane schreef op woensdag 12 december 2018 @ 21:32:

code:

error\[E0596]: cannot borrow immutable indexed content as mutable

Gdvrgdmfckndie...

Zou er dan toch een reden zijn dat de ene programmmeertaal populairder is dan de andere

[Radiant]

farlane schreef op woensdag 12 december 2018 @ 21:32:

code:

error\[E0596]: cannot borrow immutable indexed content as mutable

[Afbeelding]
Gdvrgdmfckndie...

Geeft je weinig rust, zo te zien

[ZieglerNichols]

Dag 13 was weer erg leuk. Hier mijn rommelige Matlab code: https://pastebin.com/K0YeKHSP Nu maar eens alles opschonen.

Edit: Opgeschoonde versie https://pastebin.com/qwKxyty8

[ Voor 20% gewijzigd door ZieglerNichols op 13-12-2018 08:51 ]

[ppx17]

Bleh, zojuist 3 kwartier extra aan het debuggen geweest voor dag 13. Test input ging prima, mijn input gaf foute antwoord.

spoiler:

Was de modulus op regel 111 vergeten. -_-'

[ Voor 16% gewijzigd door ppx17 op 13-12-2018 08:44 ]

[heuveltje]

Zo, dag 4.1 afgerond
in dit tempo ben ik ergens rond hemelvaart ook wel klaar met de kalender

Is wel een leuke manier om te leren programeren dit. Wel met geweldige DOH momentjes af en toe.

ik had vier losse functies geschreven die met for loopjes de x,y etc uit #123 @ 3,2: 5x4 haalde
werkte prima, maar wel ruim 50 regels code voor dat alleen al*. Zie ik het iemand hier gewoon met een string split doen daarna ook maar zo opnieuw geschreven.

En bij 3.2 heeft het me maar 20 min gekost, om uit te zoeken dat dat mijn antwoord eigenlijk goed was was, maar "int+1.tostring()" niet helemaal deed wat ik verwachte

* heuveltje *heeft 1 blik op regex geworpen, en bedacht dat dat voorlopig nog maar even chinees moet blijven

[ Voor 16% gewijzigd door heuveltje op 13-12-2018 11:06 ]

[Gropah]

heuveltje schreef op donderdag 13 december 2018 @ 11:00:
Zo, dag 4.1 afgerond
in dit tempo ben ik ergens rond hemelvaart ook wel klaar met de kalender

Is wel een leuke manier om te leren programeren dit. Wel met geweldige DOH momentjes af en toe.

ik had vier losse functies geschreven die met for loopjes de x,y etc uit #123 @ 3,2: 5x4 haalde
werkte prima, maar wel ruim 50 regels code voor dat alleen al*. Zie ik het iemand hier gewoon met een string split doen daarna ook maar zo opnieuw geschreven.

En bij 3.2 heeft het me maar 20 min gekost, om uit te zoeken dat dat mijn antwoord eigenlijk goed was was, maar "int+1.tostring()" niet helemaal deed wat ik verwachte

*/me heeft 1 blik op regex geworpen, en bedacht dat dat voorlopig nog maar even chinees moet blijven

Welke taal gebruik je? Want veel talen hebben ook een sscanf achtige call, waarbij je een string kunt geven waarop spul gematched word a la een regex, maar dan een stuk makkelijk om zelf in elkaar te zetten, imo. Kan nog wel eens handig worden bij latere opdrachten Meer info kan gevonden worden op veel plekken, en het verschilt soms een beetje per taal, maar http://www.cplusplus.com/reference/cstdio/scanf/ geeft wel een redelijk idee volgens mij.

[heuveltje]

Gropah schreef op donderdag 13 december 2018 @ 11:10:
[...]


Welke taal gebruik je? Want veel talen hebben ook een sscanf achtige call, waarbij je een string kunt geven waarop spul gematched word a la een regex, maar dan een stuk makkelijk om zelf in elkaar te zetten, imo. Kan nog wel eens handig worden bij latere opdrachten Meer info kan gevonden worden op veel plekken, en het verschilt soms een beetje per taal, maar http://www.cplusplus.com/reference/cstdio/scanf/ geeft wel een redelijk idee volgens mij.

Thanks.
Ik gebruik c# (waarom ?, omdat je toch iets moet kiezen )
Die heeft blijkbaar geen ingebouwd equivalent (al kun je met split wat beperktere dingen oppakken).
Maar ik ga eens kijken of dit kan implementeren
Heb het idee dat die de volgende opgave ook nog wel eens nuttig kan zijn., ipv zelf het wiel elke keer opnieuw uitvinden

[Radiant]

heuveltje schreef op donderdag 13 december 2018 @ 11:00:
Zo, dag 4.1 afgerond
in dit tempo ben ik ergens rond hemelvaart ook wel klaar met de kalender

Is wel een leuke manier om te leren programeren dit. Wel met geweldige DOH momentjes af en toe.

ik had vier losse functies geschreven die met for loopjes de x,y etc uit #123 @ 3,2: 5x4 haalde
werkte prima, maar wel ruim 50 regels code voor dat alleen al*. Zie ik het iemand hier gewoon met een string split doen daarna ook maar zo opnieuw geschreven.

En bij 3.2 heeft het me maar 20 min gekost, om uit te zoeken dat dat mijn antwoord eigenlijk goed was was, maar "int+1.tostring()" niet helemaal deed wat ik verwachte

* heuveltje *heeft 1 blik op regex geworpen, en bedacht dat dat voorlopig nog maar even chinees moet blijven

Regex is wel enorm handig om te kennen, vooral omdat het in bijna elke taal te gebruiken is.
Om het simpel te houden kan je beginnen met het matchen van getallen met (\d+) en woorden met (\w+). Dat is voor (bijna) alle opgaven wel genoeg.

[Soultaker]

Zo, ik zat wel even vast op deel 2 van dag 13.

Wat ik verkeerd deed was dat ik

spoiler:

alle karretjes 1 stap vooruit liet doen, en dan keek of er twee op dezelfde plek staan. Dat werkte toevallig voor beide voorbeelden en deel 1, maar bij deel 2 mis je dan botsingen tussen "><" , die rijden dan door elkaar heen.

Duurde wel even om dat uit te vinden bij gebrek aan voorbeelden waar het mis ging, en het aantal implementatie-details waar het mis kon gaan. Uiteindelijk wel gelukt (Python code).

[emnich]

Mijn dag is ook weer klaar in php.

@ppx17 Ik krijg een verkeerd antwoord met jouw code als ik mijn input draai

[ Voor 41% gewijzigd door emnich op 13-12-2018 15:05 ]

[veldsla]

Zo ik ben ook weer bij. Dag 13..tsja een maze achtig iets, dat zit er ook elk jaar wel in. Zouden we de computer aan het einde ook weer krijgen? (proggen in je wrist device of zo)

[DRaakje]

veldsla schreef op donderdag 13 december 2018 @ 15:21:
Zo ik ben ook weer bij. Dag 13..tsja een maze achtig iets, dat zit er ook elk jaar wel in. Zouden we de computer aan het einde ook weer krijgen? (proggen in je wrist device of zo)

Vast wel, dag 23 van vorig jaar was ook erg leuk!

[woutertje]

Heb me vandaag maar weer eens gewaagd aan een visualisatie :-).

[Hydra]

Beetje laat maar hier Dag 13 in Kotlin

[Gropah]

Ik ben ook laat, maar ik krijg niet het goede antwoord uit mijn programma voor deel 2... grmbl

Eerst had ik wel de goede output bij het example, maar dat was toeval omdat ik een bepaalde move niet goed deed maar het dan een stap later wel goed ging. Dat is er nu uit, en ik doe het example stap voor stap goed met het goede antwoord, maar voor mijn eigen input gaat het nog niet goed Ik ga maar even wat anders doen en er later met een frisse blik naar kijken.

[SuppaTim]

Vandaag liet uni helaas wat weinig tijd over voor AoC. Toch eerst maar gewerkt aan dag 11 (heb mezelf voorgenomen deze sneller te laten lopen icm OpenCL), na wat proberen iets aan de praat gekregen wat het een stuk sneller laat lopen op de gpu. Code ziet er helaas niet uit.
Mocht er iemand veel verstand hebben van OpenCL en optimalizatie ervan hoor ik het graag!

[BernardV]

heuveltje schreef op donderdag 13 december 2018 @ 11:00:
* heuveltje *heeft 1 blik op regex geworpen, en bedacht dat dat voorlopig nog maar even chinees moet blijven

Wat wel een goede manier is om regex te leren is testen op sites als dit: https://regexr.com

Ik gebruik dit ook regelmatig, ik plaats de input van een dag hier en ga kijken. Door je muis op de positie van een regel te zetten zie je gelijk wat je “matches” zijn.

[diabolofan]

Niet al te veel tijd gehad afgelopen dagen, dus ben nu bij dag 12. Heb alleen een vraagje. In het voorbeeld van deel 1 staat het volgende:

code:

                 1         2         3     
       0         0         0         0     
 0: ...#..#.#..##......###...###...........
 1: ...#...#....#.....#..#..#..#...........
 2: ...##..##...##....#..#..#..##..........
 3: ..#.#...#..#.#....#..#..#...#..........
 4: ...#.#..#...#.#...#..#..##..##.........
 5: ....#...##...#.#..#..#...#...#.........
 6: ....##.#.#....#...#..##..##..##........
 7: ...#..###.#...##..#...#...#...#........
 8: ...#....##.#.#.#..##..##..##..##.......
 9: ...##..#..#####....#...#...#...#.......
10: ..#.#..#...#.##....##..##..##..##......
11: ...#...##...#.#...#.#...#...#...#......
12: ...##.#.#....#.#...#.#..##..##..##.....
13: ..#..###.#....#.#...#....#...#...#.....
14: ..#....##.#....#.#..##...##..##..##....
15: ..##..#..#.#....#....#..#.#...#...#....
16: .#.#..#...#.#...##...#...#.#..##..##...
17: ..#...##...#.#.#.#...##...#....#...#...
18: ..##.#.#....#####.#.#.#...##...##..##..
19: .#..###.#..#.#.#######.#.#.#..#.#...#..
20: .#....##....#####...#######....#.#..##.

Daaronder vermelden ze dan dat de som van alle planten 325 moet zijn. Maar ik kom uit op 264 en een find -> replace van de # in Notepad++ zegt ook dat hij er dan 264 vervangt.. Dus hoe komen ze nou aan die 325?

[emnich]

diabolofan schreef op donderdag 13 december 2018 @ 19:28:
Niet al te veel tijd gehad afgelopen dagen, dus ben nu bij dag 12. Heb alleen een vraagje. In het voorbeeld van deel 1 staat het volgende:

code:

                 1         2         3     
       0         0         0         0     
 0: ...#..#.#..##......###...###...........
 1: ...#...#....#.....#..#..#..#...........
 2: ...##..##...##....#..#..#..##..........
 3: ..#.#...#..#.#....#..#..#...#..........
 4: ...#.#..#...#.#...#..#..##..##.........
 5: ....#...##...#.#..#..#...#...#.........
 6: ....##.#.#....#...#..##..##..##........
 7: ...#..###.#...##..#...#...#...#........
 8: ...#....##.#.#.#..##..##..##..##.......
 9: ...##..#..#####....#...#...#...#.......
10: ..#.#..#...#.##....##..##..##..##......
11: ...#...##...#.#...#.#...#...#...#......
12: ...##.#.#....#.#...#.#..##..##..##.....
13: ..#..###.#....#.#...#....#...#...#.....
14: ..#....##.#....#.#..##...##..##..##....
15: ..##..#..#.#....#....#..#.#...#...#....
16: .#.#..#...#.#...##...#...#.#..##..##...
17: ..#...##...#.#.#.#...##...#....#...#...
18: ..##.#.#....#####.#.#.#...##...##..##..
19: .#..###.#..#.#.#######.#.#.#..#.#...#..
20: .#....##....#####...#######....#.#..##.

Daaronder vermelden ze dan dat de som van alle planten 325 moet zijn. Maar ik kom uit op 264 en een find -> replace van de # in Notepad++ zegt ook dat hij er dan 264 vervangt.. Dus hoe komen ze nou aan die 325?

Het gaat niet om het aantal. De plant in pot 1 telt voor 1, in pot 2 voor 2.... Pot 5 voor 5 etc.

[diabolofan]

emnich schreef op donderdag 13 december 2018 @ 19:31:
[...]


Het gaat niet om het aantal. De plant in pot 1 telt voor 1, in pot 2 voor 2.... Pot 5 voor 5 etc.

Thanks, dag 12 af Tijden post ik niet meer aangezien dat in de seconden begint te lopen

Dag 13 was weer beter te doen. Hou wel van zulke logica die erg duidelijk (en dus onderhoudbaar) is dmv wat enums: https://github.com/gercob...entOfCode/ProgramDay13.cs

[ Voor 29% gewijzigd door diabolofan op 13-12-2018 21:17 ]

[Anoniem: 1004565]

Dag 13... Toen ik het voorbeeld input pakte, stond er een "\n" als eerste line in mn input..dus ik skipte de eerste regel...en mij mn echte input ook, terwijl daar *geen* "\n" als eerste line in stond...de hele tijd was mn antwoord fout en ik snapte niet waarom hahaha.

Ook jammer dat je in Rust geen mutable borrow naar een element uit een Vec, kan hebben, dat casten naar een shared borrow, en dan gewoon over de lijst heen loopen...je moet met indexen werken

https://github.com/DutchG.../master/day13/src/main.rs
https://github.com/DutchG...aster/day13_2/src/main.rs

[Camulos]

Dag 13... veel te lange lap code gemaakt.
Het werkt en doet er minder dan 200 ms over

Vooral bij deel 2 was het goed lezen geblazen -> deel 2 gaat altijd van boven naar beneden
En had net als anderen dat ik ->-<- wel goed deed maar -><- niet

C# - https://github.com/flutte...dventOfCode/2018/Day13.cs

[BernardV]

Dag 14 in PHP: https://pastebin.com/cNHqxRsj

spoiler:

Ik had constant foute recipies en maar zoeken.. na een paar koppen koffie kwam ik tot de conclusie dat ik een domme fout had gemaakt door de positie steeds uit te rekenen, maar niet op te tellen bij de huidige positie

code:

time php p1.php
Part 1: 583287310618
Part 2: 2027370816

real    0m6.027s
user    0m5.979s
sys     0m0.041s

Valt me nog niet tegen voor brute force...

[ Voor 23% gewijzigd door BernardV op 14-12-2018 10:22 ]

[emnich]

Mijn dag 14 in PHP. Performance is verschrikkelijk...

[ProAce]

Een aantal dagen overgeslagen omdat ik er (nog) niet uitkom. Net mijn implementatie voor dag 11 omgebouwd naar een SAT table na hier op het idee gebracht te worden, van 2m30 naar 40ms

[veldsla]

Er zijn voor dag 14 vast slimme dingen te bedenken(?) maar ik heb er nog niet naar gekeken en I got nothing. ~350ms (230ms met native cpu optimalisaties), ik vind het prima. Hoewel, als ik aan het einde de tijden van alle dagen ga optellen is dit wel mijn slechtste...

[ Voor 9% gewijzigd door veldsla op 14-12-2018 13:25 ]

[Soultaker]

veldsla schreef op vrijdag 14 december 2018 @ 11:23:
Er zijn voor dag 14 vast slimme dingen te bedenken(?)

spoiler:

In talen die native code genereren, zoals Rust, kun je de laatste zes cijfers coderen als een int die je elke iteratie update. Zie bijvoorbeeld deze Python code. In Python hielp dat niet (simpelweg elke iteratie de laatste zes elementen slicen en vergelijken is sneller) waarschijnlijk vanwege interpreter overhead.

De modulo-operatie is op verschillende manieren weg te optimaliseren maar ik weet niet of dat de moeite waard is in de praktijk.

Een andere mogelijkheid is om een de doel-string als state machine te coderen, of een string search algoritme te implementeren zoals KMP, maar aangezien de gezochte substring erg kort is is de winst die daarmee te behalen valt bescheiden.

edit:
Deze oplossing in C doet er ongeveer 125 ms over. Dat lijkt me ongeveer de ondergrens voor het brute-force algoritme (op micro-optimalisaties/verschillen in hardware na). Dan is 230-350 ms voor de Rust versie ook best netjes.

Ik ben nog wel benieuwd of er een fundamenteel sneller algoritme is.

[ Voor 14% gewijzigd door Soultaker op 14-12-2018 14:17 ]

[ProAce]

Ik loop stuk op deel 2 van dag 14, als ik de voorbeelden invul werkt het perfect. Maar als ik mijn eigen input invul dan klopt de uitkomst niet meer

Ik lees het toch goed dat de uitkomst de lengte van het totale scoreboard - de lengte van de te vinden waardes?

[Soultaker]

ProAce schreef op vrijdag 14 december 2018 @ 14:04:
Ik loop stuk op deel 2 van dag 14, als ik de voorbeelden invul werkt het perfect. Maar als ik mijn eigen input invul dan klopt de uitkomst niet meer

In de vraagstelling wordt dit voorbeeld gegeven:

spoiler:

Voor de invoer 515891 is het juiste antwoord 9 (bij deel 2).

Weet je zeker dat jouw code daar het goede antwoord geeft? Ik denk van niet, en ik ga ervan uit dat je zelf uit kunt vinden waarom

[ Voor 11% gewijzigd door Soultaker op 14-12-2018 14:25 ]

[veldsla]

Soultaker schreef op vrijdag 14 december 2018 @ 13:56:
Ik ben nog wel benieuwd of er een fundamenteel sneller algoritme is.

Ik had een backtracker die stukke matches kon doorschuiven al getest. Was langzamer (pattern te kort dus).
Nu de bitshifter en de test op een getal gemaakt en die is marginaal sneller op de pattern van 6 (~210ms optimized, 290ms normaal)

Jouw C versie op mijn bak met gcc 8.2.1 met -O3 -march native doet ook 290ms. je hebt een snelle machine dus of een betere compiler (clang ook getest, geen verschil) I suck. 140ms inderdaad, 130 als ik die divisions eruit haal.

Wak! Als ik de modulo eruit haksel met dat while construct kriijg ik deel2 de rust versie naar 110ms. Lang leve de micro-optimalisaties Waarom fixt de compiler dat niet gewoon voor mij?

[ Voor 34% gewijzigd door veldsla op 14-12-2018 15:44 ]

[ProAce]

Soultaker schreef op vrijdag 14 december 2018 @ 14:23:
[...]

In de vraagstelling wordt dit voorbeeld gegeven:

spoiler:

Voor de invoer 515891 is het juiste antwoord 9 (bij deel 2).

Weet je zeker dat jouw code daar het goede antwoord geeft? Ik denk van niet, en ik ga ervan uit dat je zelf uit kunt vinden waarom

spoiler:

Het gegeven voorbeeld is 51589 en die returned 9 bij mij, net als dat alle andere voorbeelden de correcte waarden teruggeven.

[ZieglerNichols]

ProAce schreef op vrijdag 14 december 2018 @ 14:04:
Ik loop stuk op deel 2 van dag 14, als ik de voorbeelden invul werkt het perfect. Maar als ik mijn eigen input invul dan klopt de uitkomst niet meer

Ik lees het toch goed dat de uitkomst de lengte van het totale scoreboard - de lengte van de te vinden waardes?

spoiler:

Als je na elke iteratie de laatste 6 elementen van je scorelijst checkt (als je puzzelinput 6 lang is), let er dan op dat je soms 2 scores toevoegt. Als je na die 2 scores toevoegen de laatste 6 checkt, dan mis je misschien net het juiste antwoord als dit voorkomt na het toevoegen van de eerste score van de twee. Dan moet je ook de -7 tot -1 elementen vanaf het einde checken.

[BernardV]

ZieglerNichols schreef op vrijdag 14 december 2018 @ 14:52:
[...]

spoiler:

Als je na elke iteratie de laatste 6 elementen van je scorelijst checkt (als je puzzelinput 6 lang is), let er dan op dat je soms 2 scores toevoegt. Als je na die 2 scores toevoegen de laatste 6 checkt, dan mis je misschien net het juiste antwoord als dit voorkomt na het toevoegen van de eerste score van de twee. Dan moet je ook de -7 tot -1 elementen vanaf het einde checken.

Nu ik dit lees zie ik ook een fout in mijn code, hij werkt prima, maar doet meer iteraties dan nodig. Helaas nu geen computer in de buurt het aan te passen en te testen.

//EDIT: wat betreft de input als int beschouwen en ook de laatste 6 cijfers als int gebruiken zou mis kunnen gaan. Ik heb op reddit iemand gezien die een input had die begon met 0

[ Voor 11% gewijzigd door BernardV op 14-12-2018 15:12 ]

[ProAce]

ZieglerNichols schreef op vrijdag 14 december 2018 @ 14:52:
[...]

spoiler:

Als je na elke iteratie de laatste 6 elementen van je scorelijst checkt (als je puzzelinput 6 lang is), let er dan op dat je soms 2 scores toevoegt. Als je na die 2 scores toevoegen de laatste 6 checkt, dan mis je misschien net het juiste antwoord als dit voorkomt na het toevoegen van de eerste score van de twee. Dan moet je ook de -7 tot -1 elementen vanaf het einde checken.

Thanks! Dat was de fout, zo had ik het niet begrepen uit de uitleg.

[veldsla]

bernardV schreef op vrijdag 14 december 2018 @ 15:09:
[...]
//EDIT: wat betreft de input als int beschouwen en ook de laatste 6 cijfers als int gebruiken zou mis kunnen gaan. Ik heb op reddit iemand gezien die een input had die begon met 0

Waarom?

[BernardV]

veldsla schreef op vrijdag 14 december 2018 @ 15:26:
[...]


Waarom?

Brainfart;-) Ik dacht even aan het vergelijken van 012345 op bv 112345 maar dat is helemaal niet aan de orde mits je de lengte van 6 aanhoudt. Als je de lengte van je input zou pakken (na int casting) is het wel mogelijk dat het mis gaat. Maar goed, zoals jij het omschrijft maakt het inderdaad niet uit. Al zou er 000001 staan.

[ElkeBxl]

ZieglerNichols schreef op vrijdag 14 december 2018 @ 14:52:
[...]

spoiler:

Als je na elke iteratie de laatste 6 elementen van je scorelijst checkt (als je puzzelinput 6 lang is), let er dan op dat je soms 2 scores toevoegt. Als je na die 2 scores toevoegen de laatste 6 checkt, dan mis je misschien net het juiste antwoord als dit voorkomt na het toevoegen van de eerste score van de twee. Dan moet je ook de -7 tot -1 elementen vanaf het einde checken.

Die fout had ik ook gemaakt! Was te verdacht dat hij bij mij gewoon maar bleef doorgaan zonder ooit een match te vinden...

[Anoniem: 1004565]

veldsla schreef op vrijdag 14 december 2018 @ 14:36:
[...]


Ik had een backtracker die stukke matches kon doorschuiven al getest. Was langzamer (pattern te kort dus).
Nu de bitshifter en de test op een getal gemaakt en die is marginaal sneller op de pattern van 6 (~210ms optimized, 290ms normaal)

Jouw C versie op mijn bak met gcc 8.2.1 met -O3 -march native doet ook 290ms. je hebt een snelle machine dus of een betere compiler (clang ook getest, geen verschil) I suck. 140ms inderdaad, 130 als ik die divisions eruit haal.

Wak! Als ik de modulo eruit haksel met dat while construct kriijg ik deel2 de rust versie naar 110ms. Lang leve de micro-optimalisaties Waarom fixt de compiler dat niet gewoon voor mij?

grappig, voor de gein heb ik jouw versie ook genomen, en gebenched.

Bij mij was de gewone normale versie sneller dan dan fancy versie die usizes gebruikt als pattern:

running 2 tests
test tests::solve_slow ... bench: 716,606,775 ns/iter (+/- 27,580,270)
test tests::solve_usize ... bench: 726,809,125 ns/iter (+/- 12,597,471)

test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured; 0 filtered out


https://github.com/DutchG...aster/day14_2/src/main.rs

[veldsla]

Je roept solve_fast aan in de bench van solve_slow?

In jouw geval zal waarschijnlijk de constructie van de iterator en de implementatie daarvan de beperkende factor zijn.

Als ik mijn functie toevoeg als solve_ori en die solve_fast naar solve fix dan zie ik het volgende:

code:

running 3 tests
test tests::solve_ori   ... bench:  88,609,721 ns/iter (+/- 533,493)
test tests::solve_slow  ... bench: 370,334,303 ns/iter (+/- 1,804,489)
test tests::solve_usize ... bench: 322,144,548 ns/iter (+/- 1,453,769)

test result: ok. 0 passed; 0 failed; 0 ignored; 3 measured; 0 filtered out

[ Voor 109% gewijzigd door veldsla op 14-12-2018 18:58 ]

[Soultaker]

ProAce schreef op vrijdag 14 december 2018 @ 14:44:
Het gegeven voorbeeld is 51589 en die returned 9 bij mij, net als dat alle andere voorbeelden de correcte waarden teruggeven.

Ik noemde 515891 als voorbeeld (ik had inderdaad verkeerd gezien dat dat al als voorbeeld was genoemd) en als je die had uitgeprobeerd had je gezien dat je daar het verkeerde antwoord geeft.

[ProAce]

Soultaker schreef op vrijdag 14 december 2018 @ 20:12:
[...]

Ik noemde 515891 als voorbeeld (ik had inderdaad verkeerd gezien dat dat al als voorbeeld was genoemd) en als je die had uitgeprobeerd had je gezien dat je daar het verkeerde antwoord geeft.

Acheraf snap ik hem ja, alleen ik was gefixeerd op het feit dat het antwoord in de allerlaatste digits moest zitten.

[Soultaker]

veldsla schreef op vrijdag 14 december 2018 @ 14:36:
Wak! Als ik de modulo eruit haksel met dat while construct kriijg ik deel2 de rust versie naar 110ms. Lang leve de micro-optimalisaties Waarom fixt de compiler dat niet gewoon voor mij?

Post je code eens?

In het algemeen zal de compiler code als:

code:

x = y%z

niet herschrijven naar:

code:

x = y;
while (x >= z) x -= z;

Ook al kan het sneller zijn, de compiler kan niet voorspellen dat x meestal klein genoeg is.

Verder kan een 32-bits integer deling herschreven worden naar een 64-bits integer vermenigvuldiging. Als z een constante is kan de compiler dat voor je doen, maar als het geen constante is, moet je dat zelf implementeren.

Verder hoef je bij dit probleem überhaupt geen deling te gebruiken als je de zes cijfers in b.v. base 16 codeert (denk: BCD). Dan kun je met een shift en een bitmask toe i.p.v. vermenigvuldigen en delen.

[veldsla]

Soultaker schreef op vrijdag 14 december 2018 @ 20:19:
[...]

Post je code eens?

de match fun. Ik gebruik nu 4 bits per getal en kan dus een pattern tot 16 aan. De u64 reduceren tot u32 gaf geen echte snelheidswinst.

In het algemeen zal de compiler code als:
[..]
niet herschrijven naar:
[..]
Ook al kan het sneller zijn, de compiler kan niet voorspellen dat x meestal klein genoeg is.

Ik had het zelf inderdaad ook al bedacht, maar vond het verschil in snelheid toch wel erg groot.

[ Voor 4% gewijzigd door veldsla op 14-12-2018 20:30 ]

[ZieglerNichols]

veldsla schreef op vrijdag 14 december 2018 @ 20:27:
[...]

de match fun. Ik gebruik nu 4 bits per getal en kan dus een pattern tot 16 aan. De u64 reduceren tot u32 gaf geen echte snelheidswinst.

[...]

Ik had het zelf inderdaad ook al bedacht, maar vond het verschil in snelheid toch wel erg groot.

Leuk om de Rust oplossingen te zien. Ik ben nog niet fluent genoeg om AoC in Rust te doen, maar ik leer wel veel van jullie code! De compiler en ik hebben weleens oneenigheid

[ Voor 3% gewijzigd door ZieglerNichols op 14-12-2018 20:47 ]

[Soultaker]

veldsla schreef op vrijdag 14 december 2018 @ 20:27:
de match fun.

Ik ken Rust niet echt, maar die unsafe blokken zien er niet echt elegant uit. Als je elf_1 en elf_2 als size_t (of unsigned) declareert, en de while loops naar het begin van de lus haalt (zodat de compiler kan zien dat ze < v.len() zijn) dan kan de compiler misschien de boundary checks zelf wegoptimalizeren?

[veldsla]

Oh die unsafes. Dat was nog een testje om te kijken wat het scheelt en laatste druppeltje performance eruit te halen. Het verschil was maar een paar procent. elf_1 en 2 worden automatisch ge-inferred als usize (platform afhankelijk word size unsigend integer) omdat ik ze gebruik om een vec mee te indexeren.

Er is ook niks mis met unsafe en het is ook niet perse niet-idiomatisch. In dit geval is het bewijs dat het safe is vrij triviaal.

[ Voor 20% gewijzigd door veldsla op 14-12-2018 21:07 ]

[Anoniem: 1004565]

Soultaker schreef op vrijdag 14 december 2018 @ 20:51:
[...]

Ik ken Rust niet echt, maar die unsafe blokken zien er niet echt elegant uit. Als je elf_1 en elf_2 als size_t (of unsigned) declareert, en de while loops naar het begin van de lus haalt (zodat de compiler kan zien dat ze < v.len() zijn) dan kan de compiler misschien de boundary checks zelf wegoptimalizeren?

`unsafe` betekend meer iets in de zin als "Ik weet wat ik doe, vertrouw mij, compiler"

[veldsla]

Soultaker schreef op vrijdag 14 december 2018 @ 20:51:
[...]
Als je elf_1 en elf_2 als size_t (of unsigned) declareert, en de while loops naar het begin van de lus haalt (zodat de compiler kan zien dat ze < v.len() zijn) dan kan de compiler misschien de boundary checks zelf wegoptimalizeren?

Ok, eigenlijk snap ik hier te weinig van om er echt iets over te zeggen, maar denk dat het inderdaad kan:
https://godbolt.org/z/9UZh2i
De while op regel 4 geeft een ander resultaat dan de while op regel 7

Bench lijkt het inderdaad te bevestigen: gist. -edit- maar het is natuurlijk niet zo, want dan zou een logic error (bv while pos > data.len()) een compile error moeten geven. En dat gebeurt niet, er komt gewoon een out-of-bounds

[ Voor 21% gewijzigd door veldsla op 15-12-2018 09:24 ]

[Soultaker]

Even filosofisch over unsafe:

veldsla schreef op vrijdag 14 december 2018 @ 21:01:
Er is ook niks mis met unsafe en het is ook niet perse niet-idiomatisch. In dit geval is het bewijs dat het safe is vrij triviaal.

Anoniem: 1004565 schreef op vrijdag 14 december 2018 @ 21:02:
`unsafe` betekend meer iets in de zin als "Ik weet wat ik doe, vertrouw mij, compiler"

Het punt van compile time checks (zeker in een taal als Rust, die de ambitie heeft een "veiliger soort C++" te zijn) is dat bepaalde veiligheidseigenschappen gegarandeerd worden door de compiler. Als je unsafe gebruikt verlies je die garantie.

In de praktijk moet je bij het schrijven van code een compromis vinden tussen leesbaarheid, prestaties en veiligheid. Als je maximale prestaties wil, dan zul je soms unsafe code moeten schrijven (die wel veilig kan zijn, maar waarvan de compiler dat niet kan garanderen). Daarom ben ik het met jullie eens dat unsafe niet taboe is. Maar áls je je code kunt schrijven zónder het gebruik van unsafe, op zo'n manier dat noch de leesbaarheid, noch de prestaties er onder lijden, dan is dat te prefereren.

In andere woorden: mijns inziens zou je unsafe alleen moeten gebruiken als er geen andere manier is om hetzelfde effect te bereiken.

veldsla schreef op vrijdag 14 december 2018 @ 22:12:
Ok, eigenlijk snap ik hier te weinig van om er echt iets over te zeggen, maar denk dat het inderdaad kan:
https://godbolt.org/z/9UZh2i
De while op regel 4 geeft een ander resultaat dan de while op regel 7

1. Ik wist niet dat Godbolt ook Rust ondersteunt. Cool!

2. Je code is incorrect. Je moet while pos >= data.len() schrijven (>= i.p.v. >). (pos % data.len() == 0, niet data.len()). Dan zul je zien dat je geen out-of-bounds error krijgt, en dat de compiler de bounds check weg kan optimaliseren.

[ Voor 5% gewijzigd door Soultaker op 15-12-2018 14:35 ]

[ZieglerNichols]

Dag 15 eindelijk af: https://pastebin.com/Dw48G36k . Was vooral weer goed lezen en de voorbeelden gebruiken.

[Soultaker]

Ja inderdaad. Niet m'n favoriete soort probleem: veel werk, weinig creativiteit.

spoiler:

Ik vond de manier om rondes te tellen ook niet heel logisch, maar gelukkig werd dat in de voorbeelden verduidelijkt.

[ZieglerNichols]

Soultaker schreef op zaterdag 15 december 2018 @ 16:54:
Ja inderdaad. Niet m'n favoriete soort probleem: veel werk, weinig creativiteit.

spoiler:

Ik vond de manier om rondes te tellen ook niet heel logisch, maar gelukkig werd dat in de voorbeelden verduidelijkt.

Het enige stukje dat misschien nog beetje creatief kon was het bepalen van de afstanden naar de targets.

spoiler:

Ik begin met een logische matrix met alleen de target op true. Daarna deze iteratief in alle 4 richtingen 1 hokje verschuiven en de resultaten daarna over elkaar heen te leggen en de geblokkeerde cellen te elimineren. Omdat het voor Matlab niet uitmaakt wat voor type er precies gebruikt wordt, kun je ook gelijk de afstand bijhouden per iteratie. Zo heb je in een paar stappen een matrix met afstanden vanaf elke cel tot aan de target.

[veldsla]

Nou.....ik zal wel niet kunnen lezen. Alle eindposities zijn goed. Alle hp sums in orde op alle tests, maar de rounds zijn op test1 na off-by-one. Op mijn input heb ik zowel rounds*hp als rounds-1 * hp geprobeerd, maar die zijn beide fout.

[Soultaker]

veldsla schreef op zaterdag 15 december 2018 @ 17:30:
Nou.....ik zal wel niet kunnen lezen. Alle eindposities zijn goed. Alle hp sums in orde op alle tests, maar de rounds zijn op test1 na off-by-one.

Dat probleem had ik dus ook. Het gaat om de interpretatie van dit deel:

spoiler:

You need to determine the outcome of the battle: the number of full rounds that were completed (not counting the round in which combat ends) [..] (Combat only ends when a unit finds no targets during its turn.)

En in het eerste voorbeeld:

spoiler:

Before the 48th round can finish, the top-left Goblin finds that there are no targets remaining, and so combat ends. So, the number of full rounds that were completed is 47

Met andere woorden (grote spoiler):

spoiler:

Je moet niet eens per ronde checken of de simulatie voorbij is, maar voor de actie van elke unit. Als een unit aan de beurt is terwijl er geen vijanden meer over zijn, dan eindigt de simulatie meteen en geldt de huidige ronde als incompleet en telt dus niet mee.

Anders gezegd, als de laatste Elf sterft in ronde X, dan maakt het uit of hij wordt verslagen door de laatste Goblin die in die ronde aan de beurt komt. Zo ja, dan telt X mee als volledige ronde, zo nee, dan is X-1 het aantal volledige ronden.

[ Voor 3% gewijzigd door Soultaker op 15-12-2018 18:36 ]

[veldsla]

Zover was ik oook gekomen, hoewel ik dat nog even moet inbouwen. Alleen dit zit me nog dwars:

veldsla schreef op zaterdag 15 december 2018 @ 17:30:
Op mijn input heb ik zowel rounds*hp als rounds-1 * hp geprobeerd, maar die zijn beide fout.

Lijkt toch aan te geven dat er iets mis is met de movement wat niet door de tests gecovered wordt.

Aargh. Ik had hetzelfde als deze persoon, iets aangepast en nu gaat die goed (nare map met 103 iteraties), maar mijn input nog steeds niet

[ Voor 24% gewijzigd door veldsla op 15-12-2018 20:04 ]

[Soultaker]

veldsla schreef op zaterdag 15 december 2018 @ 18:39:
Lijkt toch aan te geven dat er iets mis is met de movement wat niet door de tests gecovered wordt.

Klinkt waarschijnlijk. Misschien ben je een van de tiebreak criteria vergeten?

[ZieglerNichols]

veldsla schreef op donderdag 13 december 2018 @ 15:21:
Zo ik ben ook weer bij. Dag 13..tsja een maze achtig iets, dat zit er ook elk jaar wel in. Zouden we de computer aan het einde ook weer krijgen? (proggen in je wrist device of zo)

Je voorspelling is uitgekomen Ik zat er ook al op te wachten.

Dag 16: https://pastebin.com/Hu6J0iRn

spoiler:

Het vinden van de juiste opcode nummers heb ik handmatig gedaan door naar een aantal samples te kijken waar meerdere mogelijkheden zijn. Gewoon even de opties opschrijven en elimineren wanneer bekend is dat een nummer bij een ander instructie hoort

[BernardV]

Dag 16 in PHP: https://pastebin.com/FvYrm8Pe (is nog ruw, nog geen zin gehad het netter te maken en op te ruimen).

spoiler:

Ik heb net als @ZieglerNichols de opcode nummers handmatig gezocht met behulp van part 1, door de output daar aan te passen kun je zo zien welke nummers werken voor het gegeven input nummer. Voor sommige codes is dat slechts 1 mogelijkheid en vanuit daar ga je elimineren.

//EDIT: Nu Naar dag 15, gisteren helaas geen tijd gehad.

[ Voor 16% gewijzigd door BernardV op 16-12-2018 10:24 ]

[Hydra]

Begin er wel een beetje klaar mee te worden dat part 1 weer zonder problemen werkt maar part 2 niet en dat er gewoon geen ENKEL aanknopingspunt is om erachter te komen wat er mis is zonder naar andermans code te kijken

[veldsla]

Na een dramatische dag 15 (nog steeds een bug te gaan) vond ik 16 wel leuk.

Mijn aanpak met boxed closures gaf wel aanleiding tot strijd met de borrowchk. Maar uiteindelijk heeft hij me er doorheen geholpen. Gek genoeg door een heleboel lifetime informatie te verwijderen.

[Hydra]

Ligt het aan mij of is dag 15 ook gewoon enorm veel werk?

[BernardV]

Hydra schreef op zondag 16 december 2018 @ 15:17:
Ligt het aan mij of is dag 15 ook gewoon enorm veel werk?

Nee dat ligt niet aan jou, ben vandaag aan dag 15 begonnen en ben nog (lang) niet klaar. Alle andere dagen tot nu toe gingen heel veel sneller.

[ZieglerNichols]

Hydra schreef op zondag 16 december 2018 @ 15:17:
Ligt het aan mij of is dag 15 ook gewoon enorm veel werk?

Het was best veel werk ja vergeleken met de eerdere dagen, maar niet echt moeilijk.

[Hydra]

bernardV schreef op zondag 16 december 2018 @ 15:43:
Nee dat ligt niet aan jou, ben vandaag aan dag 15 begonnen en ben nog (lang) niet klaar. Alle andere dagen tot nu toe gingen heel veel sneller.

Heb net ff de leaderboard bekeken en zat dat de nummer 100 er 2 en een half uur over gedaan heeft.

Da's gewoon te veel.

[BernardV]

ZieglerNichols schreef op zondag 16 december 2018 @ 15:45:
[...]


Het was best veel werk ja vergeleken met de eerdere dagen, maar niet echt moeilijk.

Dat het niet moeilijk is ben ik met je eens, alle logica is voor de hand liggend. Alleen voordat je alles geïmplementeerd hebt..

[ZieglerNichols]

Hydra schreef op zondag 16 december 2018 @ 15:45:
[...]


Heb net ff de leaderboard bekeken en zat dat de nummer 100 er 2 en een half uur over gedaan heeft.

Da's gewoon te veel.

Ik vind het juist wel leuk dat er ook wat langere opdrachten tussen zitten, zolang ze die maar niet op maandagochtend zetten

[Hydra]

ZieglerNichols schreef op zondag 16 december 2018 @ 15:49:
Ik vind het juist wel leuk dat er ook wat langere opdrachten tussen zitten, zolang ze die maar niet op maandagochtend zetten

Een uur is prima voor een weekenddag maar als je ziet dat de nummer 100 alleen al 2 en een half uur bezig is geweest, dan is dit gewoon echt te lang.

[Gropah]

Het heeft mij ook heel erg gedemotiveerd toen ik dat zag. Ik denk dat ik het uberhaupt een beetje laat voor wat het is. Merk gewoon dat het mij redelijk wat tijd en moeite kost en er zit een drukke week aan te komen. Misschien dat ik het in de vakantie afmaak

[BernardV]

Ik ben voor dag 15 bezig met een eigen A* implementatie. Het kan vast sneller of ik zou de code kunnen lenen (genoeg implementaties te vinden), maar dat maak het ook weer leuk.

A*: Wikipedia: A* search algorithm

spoiler:

Het lijkt mij handig A* te gebruiken, je kunt gewicht aan posities geven en dan zal de implementatie de kortst mogelijke route kiezen op basis van "gewicht". Door muren een zodanig hoge weight te geven zal er nooit door een muur gegaan worden.

[ppx17]

bernardV schreef op zondag 16 december 2018 @ 16:01:
Ik ben voor dag 15 bezig met een eigen A* implementatie. Het kan vast sneller of ik zou de code kunnen lenen (genoeg implementaties te vinden), maar dat maak het ook weer leuk.

A*: Wikipedia: A* search algorithm

spoiler:

Het lijkt mij handig A* te gebruiken, je kunt gewicht aan posities geven en dan zal de implementatie de kortst mogelijke route kiezen op basis van "gewicht". Door muren een zodanig hoge weight te geven zal er nooit door een muur gegaan worden.

spoiler:

Volgens mij ga je dan de fout in als er geen route is naar een enemy bijvoorbeeld omdat deze geblokkeerd word door een muur. Dan zal hij alsnog de dure route door de muur kiezen.

Overigens eens met de reacties hierboven, wat een werk is day15 zeg. 16 was vanmorgen even snel gedaan, nu weer door met 15...

[BernardV]

@ppx17

spoiler:

Daar heb ik ook aan gedacht, maar dat is wel op te lossen door een weight > x te negeren als "niet mogelijk".
Immers weet je je grid size en als je muren bijvoorbeeld een weight van x*y + 1 geeft weet je dat het groter is dan de langst mogelijke route op je grid.