Advent of Code 2018

[Liveshort]

farlane schreef op maandag 3 december 2018 @ 23:41:
[...]

Tot nu toe heb ik LibreOffice Calc gebruikt om meteen arrays van objecten te concatten icm text to columns, scheelt weer parse code

On another note : Waarom heeft men in Rust niet een C achtige for loop genomen? Of anders, wat is de Rustian break-early-out-of-nested-for-loop? (breaks met labels lezen als goto's )

In C kun je om uit een nested loop te breaken toch ook niet heel veel anders dan een goto gebruiken zonder je in rare bochten te wringen om absoluut maar geen goto te gebruiken? Ben zelf AoC aan het aangrijpen om Rust een beetje te leren, en Google voorziet me eigenlijk alleen maar van loops met labels waar je vervolgens naar verwijst in je break. Lijkt me op zich ook geen hele gekke oplossing.

[ZieglerNichols]

Dag 4 in Matlab: https://pastebin.com/Sx870uxM
Was even goed nadenken wat er precies gevraagd werd! Later de code nog maar eens opschonen om het beter leesbaar te maken .

edit: i.p.v. meer leesbaar ben ik de code eens wat korter gaan maken. Dag 4 in 13 regels code: https://pastebin.com/A1v8qhU5 . Hoe kort kan dit in andere talen?

[ Voor 31% gewijzigd door ZieglerNichols op 04-12-2018 08:46 ]

[emnich]

Ik vond hem wel meevallen vandaag.

[Daanoz]

Zucht, blijft lastig goed lezen in de vroege ochtend. Deel 2 gemaakt toen ik eigenlijk deel 1 moest maken... Nadat deel 1 eindelijk het goede resultaat gaf, was deel 2 dan ook zo in de pocket .

[Hydra]

Jezus, Day 4 was wel kut zeg. Bij zowel deel 1 als 2 met een oplossing gekomen die wel op de test data werkte maar niet op de echte. Blijft lastig om 6 uur 's ochtends

Dag 4 in Kotlin

[Gropah]

Damn, ben er al te lang mee bezig, maar loop hier en daar gewoon tegen dingen aan die ik (nog) niet ken in Go. Was wel te verwachten, maar enigsinds frustrerend.

Anyways, heb part 1 nu bijna werkend. Example werkt, maar daadwerkelijk input niet Ik ga maar even wat anders doen.

[ Voor 6% gewijzigd door Gropah op 04-12-2018 09:51 ]

[Ryada]

Dag 3 helaas vandaag pas kunnen doen omdat gisteren een aardig drukke dag was. Nu op naar dag 4. Helaas had ik een hoop loops nodig (naar mijn mening) om dag 3 voor elkaar te krijgen, en moet nog steeds eens wat gaan bedenken voor input validation. Misschien dat ik dat vandaag doe nadat ik dag 4 heb gedaan.

[Hydra]

Ryada schreef op dinsdag 4 december 2018 @ 09:54:
Dag 3 helaas vandaag pas kunnen doen omdat gisteren een aardig drukke dag was. Nu op naar dag 4. Helaas had ik een hoop loops nodig (naar mijn mening) om dag 3 voor elkaar te krijgen, en moet nog steeds eens wat gaan bedenken voor input validation. Misschien dat ik dat vandaag doe nadat ik dag 4 heb gedaan.

Ik heb een paar utility functions waarmee ik input kan lezen aan de hand van jaar en dag integers. Ik heb er een waar ik ook een regex aan kan voeren die meteen de regex loslaat op die regels. Misschien een idee? Als een group in een regex [0-9]+ matched weet je meteen dat je het zonder problemen naar een Int om kan zetten.

[Ryada]

Hydra schreef op dinsdag 4 december 2018 @ 10:05:
[...]


Ik heb een paar utility functions waarmee ik input kan lezen aan de hand van jaar en dag integers. Ik heb er een waar ik ook een regex aan kan voeren die meteen de regex loslaat op die regels. Misschien een idee? Als een group in een regex [0-9]+ matched weet je meteen dat je het zonder problemen naar een Int om kan zetten.

Klinkt in principe prima, maar ik zit meer te denken om een validation functie te maken en die via een `.Select()` op de inpit array los te laten. dan kan ik per dag makkelijk een validatie toevoegen en misschien ook aan de user vertellen op welke regel(s) het fout gaat.
Regex zelf ben ik niet zo een held in (ik gebruik ook 3 `.Replace()` calls in dag 3 om te parsen

[Hydra]

Ryada schreef op dinsdag 4 december 2018 @ 10:09:
Regex zelf ben ik niet zo een held in (ik gebruik ook 3 `.Replace()` calls in dag 3 om te parsen

AoC is natuurlijk een ideaal moment om nieuwe dingen te leren. En deze relatief simpele inputs lenen zicht daar prima voor. Bijvoorbeeld voor Dag 3:

code:

#1322 @ 241,755: 16x18

Mapt naar:

#[0-9]+ @ [0-9]+,[0-9]+: [0-9]+x[0-9]+

Met haakjes kun je dan capture groups aanleggen:

#([0-9]+) @ ([0-9]+),([0-9]+): ([0-9]+)x([0-9]+)

[0-9] is een character set van alle karakters tussen 0 en 9. (Je kunt voor deze specifiek ook de shorthand \d gebruiken). + matcht met 1 of meer characters uit die character class.

Kan je zeker aanraden dit onder de knie te krijgen. Als je vragen hebt, let me know

Edit, voorbeeldje voor dag 3 in C#:

code:

        var input = "#1322 @ 241,755: 16x18";
        var regex = new Regex(@"#([0-9]+) @ ([0-9]+),([0-9]+): ([0-9]+)x([0-9]+)");
        var match = regex.Match(input);
        
        for(int i = 0;i < match.Groups.Count;i++) {
            Console.WriteLine("Group " + i + ", value: " + match.Groups[i].Value);
        }

[ Voor 17% gewijzigd door Hydra op 04-12-2018 10:29 ]

[Camulos]

Hydra schreef op dinsdag 4 december 2018 @ 10:18:
[...]


AoC is natuurlijk een ideaal moment om nieuwe dingen te leren. En deze relatief simpele inputs lenen zicht daar prima voor. Bijvoorbeeld voor Dag 3:

code:

#1322 @ 241,755: 16x18

Mapt naar:

#[0-9]+ @ [0-9]+,[0-9]+: [0-9]+x[0-9]+

Met haakjes kun je dan capture groups aanleggen:

#([0-9]+) @ ([0-9]+),([0-9]+): ([0-9]+)x([0-9]+)

Ben zelf niet heel kapot van RegEx (stijle leercurve, en foutgevoelig) en gelukkig in C# vaak ook niet nodig. Voor dag 3 had ik deze:

C#:

line.Split(new char[] { '#', ' ', '@', ',', ':', 'x' }, StringSplitOptions.RemoveEmptyEntries)

Waarbij je een array van strings krijgt, en aangezien bij AoC de input relatief clean en hetzelfde is werkt dit prima. Om het meteen te converteren naar integers kan je in C# direct bovenstaande meteen parsen

C#:

int[] data = Array.ConvertAll(line.Split(new char[] { '#', ' ', '@', ',', ':', 'x' }, StringSplitOptions.RemoveEmptyEntries), int.Parse);

en dit is natuurlijk voor @Ryada

[ElkeBxl]

Utidagende puzzel die dag 4, zeker gezien ik het eerst niet echt door had En weer veel lijnen code nodig gehad. Maar heerlijk die nostalgie die ik krijg bij het gebruiken van Racket Ik lijk terug op de schoolbanken te zitten.

[ Voor 13% gewijzigd door ElkeBxl op 04-12-2018 10:25 ]

[Ryada]

Hydra schreef op dinsdag 4 december 2018 @ 10:18:
[...]


AoC is natuurlijk een ideaal moment om nieuwe dingen te leren. En deze relatief simpele inputs lenen zicht daar prima voor. Bijvoorbeeld voor Dag 3:

code:

#1322 @ 241,755: 16x18

Mapt naar:

#[0-9]+ @ [0-9]+,[0-9]+: [0-9]+x[0-9]+

Met haakjes kun je dan capture groups aanleggen:

#([0-9]+) @ ([0-9]+),([0-9]+): ([0-9]+)x([0-9]+)

[0-9] is een character set van alle karakters tussen 0 en 9. (Je kunt voor deze specifiek ook de shorthand \d gebruiken). + matcht met 1 of meer characters uit die character class.

Kan je zeker aanraden dit onder de knie te krijgen. Als je vragen hebt, let me know

Edit, voorbeeldje voor dag 3 in C#:

code:

        var input = "#1322 @ 241,755: 16x18";
        var regex = new Regex(@"#([0-9]+) @ ([0-9]+),([0-9]+): ([0-9]+)x([0-9]+)");
        var match = regex.Match(input);
        
        for(int i = 0;i < match.Groups.Count;i++) {
            Console.WriteLine("Group " + i + ", value: " + match.Groups\[i].Value);
        }

Hmmm ziet er wel goed uit om eens te gaan proberen idd
Zelf had ik deze (slechte) parsing

code:

                var text = line.Replace("#", string.Empty)
                    .Replace("@", string.Empty)
                    .Replace(":", string.Empty);
                var values = text.Split(' ', StringSplitOptions.RemoveEmptyEntries);
                var claimId = int.Parse(values[0]);
                var xCoordinate = int.Parse(values[1].Split(',')[0]);
                var yCoordinate = int.Parse(values[1].Split(',')[1]);
                var width = int.Parse(values[2].Split('x')[0]);
                var height = int.Parse(values[2].Split('x')[1]);

Camulos schreef op dinsdag 4 december 2018 @ 10:24:
[...]


Ben zelf niet heel kapot van RegEx (stijle leercurve, en foutgevoelig) en gelukkig in C# vaak ook niet nodig. Voor dag 3 had ik deze:

C#:

line.Split(new char[] { '#', ' ', '@', ',', ':', 'x' }, StringSplitOptions.RemoveEmptyEntries)

Waarbij je een array van strings krijgt, en aangezien bij AoC de input relatief clean en hetzelfde is werkt dit prima. Om het meteen te converteren naar integers kan je in C# direct bovenstaande meteen parsen

C#:

int[] data = Array.ConvertAll(line.Split(new char[] { '#', ' ', '@', ',', ':', 'x' }, StringSplitOptions.RemoveEmptyEntries), int.Parse);

Je zou ook een

code:

line.Split(new char[] { '#', ' ', '@', ',', ':', 'x' }, StringSplitOptions.RemoveEmptyEntries).Select(int.Parse);
// of
line.Split(new char[] { '#', ' ', '@', ',', ':', 'x' }, StringSplitOptions.RemoveEmptyEntries).Cast<int>();

kunnen doen als we toch bezig zijn

[ Voor 22% gewijzigd door Ryada op 04-12-2018 10:39 ]

[Hydra]

Voorbeeldje van Regex parsing/capturing in Kotlin:

code:

val regex = "point: (\\d+),(\\d+)".toRegex()
val input = sequenceOf("point: 123,456", "point: 456,789")

val result = input.mapNotNull { regex.matchEntire(it)?.groupValues?.drop(1) }
        .map { it[0].toInt() to it[1].toInt() }
        .toList()

assertThat(result).contains(Pair(123, 456), Pair(456,789))

Je komt dus heel snel van een list tekstregels naar een lijst objecten.

Camulos schreef op dinsdag 4 december 2018 @ 10:24:
Ben zelf niet heel kapot van RegEx (stijle leercurve, en foutgevoelig) en gelukkig in C# vaak ook niet nodig. Voor dag 3 had ik deze:

Mja. Je moet het zelf weten Ik ben het er nogal mee oneens dat regexes foutgevoelig zijn (het matcht of het matcht niet), en die leercurve zul je als professionele dev toch doorheen moeten. My 2 cents.

[ Voor 33% gewijzigd door Hydra op 04-12-2018 11:00 ]

[DRaakje]

Camulos schreef op dinsdag 4 december 2018 @ 10:24:
[...]
Ben zelf niet heel kapot van RegEx (stijle leercurve, en foutgevoelig) en gelukkig in C# vaak ook niet nodig.

Regex ziet er altijd een beetje imposant uit, maar eigenlijk erg simpel in gebruik, als je eenmaal de syntax kent. Ik gebruik altijd https://regexr.com/ om een query te schrijven. Zie je meteen wat je regex doet en of ie werkt of niet.

[Radiant]

Als je regex wil leren moet je eens kijken naar de oplossingen van askalski op de AOC-reddit, die gast lost gewoon de hele puzzels op in regex

Voorbeeld

[Trolladelaar]

Hydra schreef op dinsdag 4 december 2018 @ 10:18:

code:

#1322 @ 241,755: 16x18

Mapt naar:

#[0-9]+ @ [0-9]+,[0-9]+: [0-9]+x[0-9]+

Met haakjes kun je dan capture groups aanleggen:

#([0-9]+) @ ([0-9]+),([0-9]+): ([0-9]+)x([0-9]+)

Ik kwam er zelf ook pas later achter, maar bij dag 3 heb je genoeg aan "/\d+/" om alle cijfers uit de string te matchen. De rest van de data heb je niet nodig.

[veldsla]

Dag 4...Advent of parsing. Meh, niet echt leuk.

[Gropah]

Nou, ik ben er uit. Mijn sorting werd niet op het goede moment gedaan waardoor aannames fout gingen En toen ik dat eenmaal goed had was deel 1 klaar en deel 2 was 2 minuten later oid.

Ik heb zelf 2 regexen gebruikt, 1 om de tijd er uit te halen en 1 om de ID uit de string na verwijdering van de tijd proberen te halen.

Performant zal het wel niet zijn, maar meh:

639769 ns => 0.640 ms voor beide delen.

[Woy]

Hydra schreef op dinsdag 4 december 2018 @ 10:48:
Mja. Je moet het zelf weten Ik ben het er nogal mee oneens dat regexes foutgevoelig zijn (het matcht of het matcht niet), en die leercurve zul je als professionele dev toch doorheen moeten. My 2 cents.

Je moet vooral niet alles met een Regex proberen op te lossen. Dingen als HTML parsen e.d. is gewoon niet fijn, al kun je er best deelproblemen mee oplossen.

Voor iets simpels als dit probleem vindt ik Regexen ook erg fijn, en leesbaar, ik probeer wel zo veel mogelijk gebruik te maken van named capture groups, dat maakt het nog wat leesbaarder.

[Hydra]

Trolladelaar schreef op dinsdag 4 december 2018 @ 12:53:
Ik kwam er zelf ook pas later achter, maar bij dag 3 heb je genoeg aan "/\d+/" om alle cijfers uit de string te matchen. De rest van de data heb je niet nodig.

Ja klopt, maar ik gebruik de 'hele' regex ook meteen om te valideren dat ik de input correct lees. Dat heeft me vorig jaar ook al een keer winst opgeleverd.

Woy schreef op dinsdag 4 december 2018 @ 15:21:
Je moet vooral niet alles met een Regex proberen op te lossen.

Dat zeg ik toch helemaal niet?

[ Voor 51% gewijzigd door Hydra op 04-12-2018 15:46 ]

[Woy]

Hydra schreef op dinsdag 4 december 2018 @ 15:44:
[...]
Dat zeg ik toch helemaal niet?

Nee dat was meer een aanvulling op jouw reactie op Camulos

[Ryada]

Dag 4 afgemaakt, heb net zoals Gropah 2 regexen gebruikt voor exact dezelfde doeleinden.
Ben wel echt totaal ontevreden over hoe de code er uiteindelijk uitziet (architectuur/design wise) en over hoe mijn variables genoemd zijn.
Maar ik heb iig weer 2 gouden sterretjes erbij \o/
Voor mensen die de slechte code willen zien: https://github.com/RyadaP...ewModels/Day4ViewModel.cs

[Anoniem: 1004565]

farlane schreef op maandag 3 december 2018 @ 23:41:
[...]

Tot nu toe heb ik LibreOffice Calc gebruikt om meteen arrays van objecten te concatten icm text to columns, scheelt weer parse code

On another note : Waarom heeft men in Rust niet een C achtige for loop genomen? Of anders, wat is de Rustian break-early-out-of-nested-for-loop? (breaks met labels lezen als goto's )

'a: while break 'a {}

In Rust kan je handmatig breaken uit loops, dmv een label. Echter is ook netjes om Iterators te maken, en te combineren, zodat je geen handmatige breaks nodig hebt!

[BernardV]

Ik dacht dag 4 eens te doen in php met de zoveel mogelijk array functies:
Even in spoiler tags ipv code voor degenen die niets willen zien.

https://pastebin.com/1Rzjf1zc

[ Voor 87% gewijzigd door BernardV op 04-12-2018 17:50 ]

[Hydra]

Je kunt 't beter als gist of op pastebin posten. Die code is op deze manier onleesbaar.

[BernardV]

Hydra schreef op dinsdag 4 december 2018 @ 17:48:
Je kunt 't beter als gist of op pastebin posten. Die code is op deze manier onleesbaar.

Aangepast, goed punt!

[Lye]

Hydra schreef op dinsdag 4 december 2018 @ 10:48:
[code]

val result = input.mapNotNull { regex.matchEntire(it)?.groupValues?.drop(1) }
.map { it[0].toInt() to it[1].toInt() }
.toList()

Ik vind het zelf altijd handiger om destructuring declarations te gebruiken:

code:

.map { (first, second) -> Pair(first.toInt(), second.toInt()) }

---

Niet zo blij met vandaag, het ziet er gewoon chaotisch uit. Desondanks, prima executietijden met 10-20ms voor deel 1 en 20-30ms voor deel 2.

spoiler:

Ik heb wel de aanname gedaan dat een guard nooit meer dan een uur slaapt. Misschien dat ik hier ooit nog wat aan ga doen maar voor nu vind ik dat niet interessant genoeg.

[BernardV]

@Lye Als reactie op je spoiler, dat klopt ook. Staat ook in de tekst.

spoiler:

Because all asleep/awake times are during the midnight hour (00:00 - 00:59), only the minute portion (00 - 59) is relevant for those events.

[Lye]

bernardV schreef op dinsdag 4 december 2018 @ 18:41:
@Lye Als reactie op je spoiler, dat klopt ook. Staat ook in de tekst.

spoiler:

Because all asleep/awake times are during the midnight hour (00:00 - 00:59), only the minute portion (00 - 59) is relevant for those events.

In dat geval moet ik vooral beter leren lezen denk ik

[MerijnB]

diabolofan schreef op maandag 3 december 2018 @ 20:36:
[...]


Ik kopieer de input in mijn code in een List<string>. Dus dat is sneller dan file uitlezen, maar deze parse ik dus inderdaad wel binnen die tijd. Deze tijd is wel zonder de JIT compilatie tijd. Met JIT compilatie tijd is het 46 ms. Zie https://github.com/gercob...b/master/Day03/Program.cs.

Ik had m'n oplossing blijkbaar wat over engineered, ik had een multimap van coordinaat naar welke claim id's daarop zaten, het invullen van die multimap duurde langer dan ik had verwacht, als je de boel in een plat 2d array douwt is het idd veel sneller, nu voor beide < 10ms inclusief lezen en parseren

[farlane]

Liveshort schreef op dinsdag 4 december 2018 @ 00:57:
[...]
In C kun je om uit een nested loop te breaken toch ook niet heel veel anders dan een goto gebruiken zonder je in rare bochten te wringen om absoluut maar geen goto te gebruiken?

Valt mee als je een "found" variabele als loop voorwaarde gebruikt. IIg heb ik het laatste decennium geen goto hoeven te gebruiken.

Ben zelf AoC aan het aangrijpen om Rust een beetje te leren, en Google voorziet me eigenlijk alleen maar van loops met labels waar je vervolgens naar verwijst in je break. Lijkt me op zich ook geen hele gekke oplossing.

Is het ook niet. Het leest alleen raar.

[bwerg]

farlane schreef op dinsdag 4 december 2018 @ 20:46:
[...]

Valt mee als je een "found" variabele als loop voorwaarde gebruikt. IIg heb ik het laatste decennium geen goto hoeven te gebruiken.

Behalve dat je het deel van de loop body ná de break dan ook moet voorzien van een if (!found) { ... }.

Ik heb genoeg gevallen gezien waar de programmeur héél trots was dat hij geen breaks nodig had, maar dat het met breaks een stuk leesbaarder was geweest. Ik snap die aversie tegen overzichtelijk geplaatste breaks niet.

[DRaakje]

C# Day 04

Code is efficient, 3ms and 0ms. Ik denk dat de hoeveelheid code kleiner kan, maar ik hou ervan om het leesbaar te houden

[ Voor 2% gewijzigd door DRaakje op 04-12-2018 21:14 . Reden: code != url ]

[Rips10]

Zat bij het tweede deel van vandaag nog even te kijken waarom mijn implementatie niet werkt, zat er een guard tussen die gewoon niet in slaap valt dus ook geen 'slaap-data' had.
Solution Day 4 c#

[Anoniem: 1004565]

veldsla schreef op dinsdag 4 december 2018 @ 13:33:
Dag 4...Advent of parsing. Meh, niet echt leuk.

Wattan? Rust's Chrono library heeft gewoon een mooie functie hiervoor! Heb niet eens een regex nodig!

Mijn stukje parsing is dit:

https://pastebin.com/PJb54hYi

[Hydra]

Lye schreef op dinsdag 4 december 2018 @ 18:34:
Ik vind het zelf altijd handiger om destructuring declarations te gebruiken:

Nice! Ik ken ze wel en gebruik ze ook, maar nog niet op die manier gedaan. Goeie tip!

[Alain]

Bij dag 4, puzzle 1:

Klopt het dat je de ID moet vinden van de guard die het meeste geslapen heeft en deze vermenigvuldigd met de minuut waarin deze het meeste geslapen heeft?

[Lye]

Alain schreef op dinsdag 4 december 2018 @ 23:59:
Bij dag 4, puzzle 1:

Klopt het dat je de ID moet vinden van de guard die het meeste geslapen heeft en deze vermenigvuldigd met de minuut waarin deze het meeste geslapen heeft?

Precies dat ja.

[Alain]

Lye schreef op woensdag 5 december 2018 @ 00:03:
[...]


Precies dat ja.

Ok, dan snap ik werkelijk niet waarom mijn antwoord fout is

[Gropah]

Alain schreef op woensdag 5 december 2018 @ 00:04:
[...]


Ok, dan snap ik werkelijk niet waarom mijn antwoord fout is

Glazenbol kijken: maar ga je er van uit dat de input gesorteerd is zoals in het voorbeeld? Want dat is bij je gegeven input niet het geval.

[Alain]

Gropah schreef op woensdag 5 december 2018 @ 00:12:
[...]


Glazenbol kijken: maar ga je er van uit dat de input gesorteerd is zoals in het voorbeeld? Want dat is bij je gegeven input niet het geval.

Dat weet ik. Maar om eerlijk te zijn heb ik tijdens het schrijven meer aandacht besteed aan mijn vriendin dan aan mijn code. Morgen nog eens rustig naar kijken en vriendin op mute.

[emnich]

Vandaag kan je er wel een mooie regex op los laten

[Hydra]

Dag 5 in Kotlin

Stuk simpeler dan Dag 4. Brute force implementatie is wel traag, misschien later eens kijken of ik een snellere manier kan bedenken.

[Daanoz]

emnich schreef op woensdag 5 december 2018 @ 06:40:
Vandaag kan je er wel een mooie regex op los laten

Dan ben ik benieuwd hoe , geprobeerd, niet gelukt, of in ieder geval niet zodanig dat het heel nuttig was...

[Camulos]

Dag 5 ook opgelost (C#). Geen slimmigheden, gewoon bruteforce.

Een string van 50K karakters is nu ook weer niet zo spannend.
Vond Part2 dan wel een leuke variatie.. vanavond kijken of we het kunnen optimaliseren

Edit:

spoiler:

Ik zag op de solution-thread mensen een Stack gebruiken! super smart.. vanmiddag kijken hoeveel dat uitmaakt tov bruteforce en meermaals itereren

[ Voor 21% gewijzigd door Camulos op 05-12-2018 09:33 ]

[emnich]

@Daanoz Haha, mij is het uiteindelijk ook niet gelukt om er iets snels van te maken maar ik dacht dat het aan mijn regex skills lag

Voor degene hierboven:

spoiler:

Is een text replace in jullie talen niet gewoon sneller dan door de hele string lopen? Ik zal het zo eens in PHP proberen maar ik kan het me niet voorstellen dat het zelf doen sneller is?

[BernardV]

emnich schreef op woensdag 5 december 2018 @ 10:09:
Voor degene hierboven:

spoiler:

Is een text replace in jullie talen niet gewoon sneller dan door de hele string lopen? Ik zal het zo eens in PHP proberen maar ik kan het me niet voorstellen dat het zelf doen sneller is?

spoiler:

Zo heb ik het wel gedaan inderdaad. Combinaties maken in een loopje 0..25 chr(i+65) en chr(i+97) en andersom.
dan een str_replace($combinations, '', $input, $count); en een while($count>0).
Dit is redelijk snel.

[emnich]

@bernardV Zo heb ik het ook. Ik heb het net geprobeerd om het op de andere manier te doen maar dat is ruim 10x zo langzaam. Deel 2 heb ik nu in 260ms, vanavond misschien nog kijken of het sneller kan.

[DRaakje]

C# Day 05

Leuke dag, part 1 was easy, part 2 zat ik even te stoeien om het acceptabel snel te krijgen. Eerste poging was 27 sec, daarna naar 5. Uiteindelijk 2ms en 62ms. Goed genoeg...

spoiler:

Poging 1: Lijst met alle mogelijke combos en string replace.
Poging 2: Linked List
Poging 3: Char array, waarbij ik dingen door null verving en dan keek of -1 en +1 daarbuiten niet toevallig vervangen kon worden.
De methode voor kijken of het een pair was vond ik uiteindelijk wel mooi:

Math.Abs(arr[i] - arr[j]) == 32

[ Voor 3% gewijzigd door DRaakje op 05-12-2018 10:39 ]

[BernardV]

DRaakje schreef op woensdag 5 december 2018 @ 10:39:

spoiler:

Poging 1: Lijst met alle mogelijke combos en string replace.
Poging 2: Linked List
Poging 3: Char array, waarbij ik dingen door null verving en dan keek of -1 en +1 daarbuiten niet toevallig vervangen kon worden.
De methode voor kijken of het een pair was vond ik uiteindelijk wel mooi:

Math.Abs(arr[i] - arr[j]) == 32

spoiler:

Je zou de tijd denk ik nog wel iets lager kunnen krijgen door Math.abs te verwijderen en te vervangen door iets als:
(X > 0 ? X : -X) == 32
Of:
((X ^ (X >> 31)) - (X >> 31)) == 32

[Ryada]

Dag 5 in C#

Heb veel te lang met de eerste opdracht vandaag lopen kloten omdat ik dacht dat je uiteindelijk maar 10 characters over moest houden. Na wat koffie erachter gekomen dat ik al meer dan een half uur de goede oplossing had. En opdracht 2 was best makkelijk om te maken erna.
Tot nu toe vind ik het wel leuke challenges, vanavond maar eens een refactor over de hele code van dag 1 t/m 5 gooien.

[Daanoz]

emnich schreef op woensdag 5 december 2018 @ 10:09:

spoiler:

Is een text replace in jullie talen niet gewoon sneller dan door de hele string lopen? Ik zal het zo eens in PHP proberen maar ik kan het me niet voorstellen dat het zelf doen sneller is?

spoiler:

Nou, je hoeft uiteindelijk maar één keer door de volledige string te lopen. Voor elk karakter (n) en het volgende karakter (n+1) check je of de charCode verschil heeft van 32 (A-Z = 65-90, a-z = 97-122), als dat zo is, verwijder je de 2 karakters, en check je op (n-1) of daar een nieuw setje is ontstaan...

[veldsla]

Kijk dit was wel leuk. Mijn eerste optimalisatie bracht me van 3.7s naar 3.7s...woei.
Wat overbodig geschuif in een vector geëlimineerd en woppa: 5a 0.4ms, 5b: 9.4ms.

[Lye]

Camulos schreef op woensdag 5 december 2018 @ 08:59:
Dag 5 ook opgelost (C#). Geen slimmigheden, gewoon bruteforce.

Een string van 50K karakters is nu ook weer niet zo spannend.
Vond Part2 dan wel een leuke variatie.. vanavond kijken of we het kunnen optimaliseren

Edit:

spoiler:

Ik zag op de solution-thread mensen een Stack gebruiken! super smart.. vanmiddag kijken hoeveel dat uitmaakt tov bruteforce en meermaals itereren

spoiler:

Een stack was ook mijn eerste ingeving. Op het moment dat je iteratief strings gaat concatten doe je 99 van de 100 keer iets fout.

Opzich vond ik vandaag wel prima gaan, ~10ms en ~60ms als tijden.

[ Voor 7% gewijzigd door Lye op 05-12-2018 13:20 ]

[Hydra]

Lye schreef op woensdag 5 december 2018 @ 12:59:
Opzich vond ik vandaag wel prima gaan, ~10ms en ~60ms als tijden.

Doh! Goeie.

[ElkeBxl]

Day 5 was echt makkelijk in vergelijking met andere dagen

[ppx17]

Hmm vond day 5 best een uitdagende voor PHP, 5 verschillende implementaties gedaan, uiteindelijk bleek deze het snelste (467 ms)

spoiler:

Heb het ook geprobeerd met maar 1x door de string (lijst) heen te gaan, maar array_splice kopieert de hele array steeds over dus was heel traag en unset() laat gaten in de index ontstaan. Iemand hier misschien een oplossing voor?

[BernardV]

ppx17 schreef op woensdag 5 december 2018 @ 14:04:
Hmm vond day 5 best een uitdagende voor PHP, 5 verschillende implementaties gedaan, uiteindelijk bleek deze het snelste (467 ms)

spoiler:

Heb het ook geprobeerd met maar 1x door de string (lijst) heen te gaan, maar array_splice kopieert de hele array steeds over dus was heel traag en unset() laat gaten in de index ontstaan. Iemand hier misschien een oplossing voor?

Slim om die 20% mee te nemen, heb ik overheen gelezen.
Ik ben zo vrij geweest om je react_str_replace functie enigzins aan te passen naar de implementatie die ik had.
https://pastebin.com/JRKpkFGD
Met mijn input is dit 30% sneller, dit is dan wel gebasseerd op de rest van jouw code.

[veldsla]

Holy.

spoiler:

Het resultaat van a gebruiken als input voor b geeft een flinke speedup!

5a: 0.39ms, 5b: 0.95ms

[ppx17]

veldsla schreef op woensdag 5 december 2018 @ 15:29:
Holy.

spoiler:

Het resultaat van a gebruiken als input voor b geeft een flinke speedup!

5a: 0.39ms, 5b: 0.95ms

Damn dat ik daar niet aan gedacht had, dat scheelt zeker gigantisch.

@bernardV Die scheelt in inderdaad nog eens 30%.

spoiler:

Interessante aanpak om een string als buffer in te zetten, had alleen maar met array's geprobeerd nog.

Als ik deze twee combineer kom ik nu op 195 34ms.

[Soultaker]

bernardV schreef op woensdag 5 december 2018 @ 11:29:

spoiler:

Je zou de tijd denk ik nog wel iets lager kunnen krijgen door Math.abs te verwijderen en te vervangen door iets als:
(X > 0 ? X : -X) == 32
Of:
((X ^ (X >> 31)) - (X >> 31)) == 32

Nog simpeler:

spoiler:

(x ^ y) == 32

[sjakie02]

Ah, had het begin gemist. Net maar even de eerste 5 gemaakt. Ik hoop dat ik het volhoud tot het einde, vorig jaar op 23 december afgehaakt vanwege familieverplichtingen

[farlane]

bwerg schreef op dinsdag 4 december 2018 @ 20:59:
[...]

Behalve dat je het deel van de loop body ná de break dan ook moet voorzien van een if (!found) { ... }.

In dat geval doe ik het niet.

Ik heb genoeg gevallen gezien waar de programmeur héél trots was dat hij geen breaks nodig had, maar dat het met breaks een stuk leesbaarder was geweest. Ik snap die aversie tegen overzichtelijk geplaatste breaks niet.

Het is voor mij geen doel op zich, maar als ik kan kiezen tussen een extra voorwaarde in de for( ... ) en een break neem ik de eerste. Ik schaam me echter niet voor een break of continue zelfs.

[Boudewijn]

Zo, ik heb 1a en 1b vandaag opgelost. 1b was best traag, omdat ik de bestaande resultaten in een list zetten. Heel veel lookups, lekker traag.

Daarna een set als datastructuur gebruikt...

code:

python3 oude-versie.py
real    2m27.631s
user    2m26.967s
sys 0m0.360s

python3 nieuw-versie.py
real    0m0.140s
user    0m0.123s
sys 0m0.012s

Lekker verschil . Dit is dus ~140k lookups in een lijst die eerst een lengte heeft van 1 en uiteindelijk ~140k-1 . Dat zijn dus serieus veel lookups.

Heb de exacte getallen even weggelaten om geen hints te geven.

[ Voor 21% gewijzigd door Boudewijn op 05-12-2018 23:03 ]

[Rips10]

Camulos schreef op woensdag 5 december 2018 @ 08:59:

spoiler:

Ik zag op de solution-thread mensen een Stack gebruiken! super smart.. vanmiddag kijken hoeveel dat uitmaakt tov bruteforce en meermaals itereren

Een stack, daar had ik niet aan gedacht, is natuurlijk een stuk efficienter.
Mijn code (C#) meteen maar even aangepast.

[Anoniem: 1004565]

Part 1: 439.308µs,
Part 2: 15.077524ms

part 1: https://github.com/DutchG.../master/day05/src/main.rs
part 2: https://github.com/DutchG...aster/day05_2/src/main.rs

Voor part 2 kan ik de stack de hele tijd hergebruiken !

[ Voor 11% gewijzigd door Anoniem: 1004565 op 06-12-2018 00:01 ]

[ZieglerNichols]

Lekker is dat Door een bug op de site werd mijn antwoord voor deel 2 eerst niet goedgekeurd. Nu wordt hetzelfde antwoord wel geaccepteerd als correct. Was blijkbaar niet voor iedereen een bug. https://twitter.com/ericwastl/status/1070563771339411457

[ Voor 12% gewijzigd door ZieglerNichols op 06-12-2018 07:34 ]

[emnich]

pff, veel te lang mee bezig geweest omdat ik blijkbaar niet kan lezen

[Daanoz]

spoiler:

Deze had van mij wel wat lastiger gemogen, uiteindelijk met 'bruteforce' minder dan 100ms. In eerste instantie begonnen met een Wikipedia: Quadtree implementatie maar bleek helemaal niet nodig te zijn...

[Camulos]

Rips10 schreef op woensdag 5 december 2018 @ 23:50:
[...]
Een stack, daar had ik niet aan gedacht, is natuurlijk een stuk efficienter.
Mijn code (C#) meteen maar even aangepast.

Ja ik heb dat gisteravond ook nog gefixed waarbij mijn runtime van 8500ms naar 126ms ging (totale tijd voor part01 en part02 samen) is maar ruim 60x zo snel
Had jij ook zoveel verschil?

[Hydra]

Day 6 in Kotlin

spoiler:

Voor part 2 eerst een recursieve floodfill gebouwd die niet werkte omdat hij te diep ging, daarna een stack-based floodfill. Blijkt er maar 1 area te zijn en kun je dus prima met gewoon een count af

[BernardV]

Daanoz schreef op donderdag 6 december 2018 @ 08:03:

spoiler:

Deze had van mij wel wat lastiger gemogen, uiteindelijk met 'bruteforce' minder dan 100ms. In eerste instantie begonnen met een Wikipedia: Quadtree implementatie maar bleek helemaal niet nodig te zijn...

spoiler:

Inderdaad, ik heb ook 'bruteforce' gebruikt. Om het toch iets sneller te maken heb ik bij elk punt gekeken wat de 4 dichtstbijzijnde punten zijn in de 90graden kwadranten om het punt heen mbv atan2. Zo kun je een min en max voor je x en y gebied bepalen waarin je moet 'zoeken'.

[Satom]

Goed, day 3 ook maar eens afgemaakt. Ik loop nog maar enkele dagen achter, maar ik moet zeggen dat mijn ruimtelijk inzicht best wel schaars is. De oplossing is dan ook niet echt om mooi te noemen

Voor de geïnteresseerden: https://github.com/Sotam/AdventOfCode2018

[veldsla]

Ik heb vrijwel hetzelfde gedaan als @Hydra.

spoiler:

Maar is het eigenlijk niet logisch dat het 1 regio is. Wat zouden de voorwaarden kunnen zijn dat er twee regios ontstaan? Dan moet er dus een punt zijn op een lijn tussen een coordinaat in regio1 en een coordinaat in regio2 die ergens boven de maxdist uitkomt en er vervolgens weer onder duikt. Dat kan dus niet want de afstand op die lijn neemt altijd toe omdat het de som(dist(allepunten)) is (0 lukt misschien ook).

Er is nog wel een mogelijk probleem dat je bounding box niet groot genoeg is als er een cluster aan de rand ligt. Die heb ik maar als panic! ingebouwd

[DRaakje]

C# Day

55ms en 25ms.

[ElkeBxl]

Wat heb ik zitten zweten op part 1... Ik zat lang vast op het bepalen van welke regio's nu infinite zijn, tot de frank plots viel. Maar eer die viel... En daarna dan lang zitten sukkelen op iets in mijn boolean logica. Maar bon, day 6 in Racket in veel te verbose code is done

[Hydra]

veldsla schreef op donderdag 6 december 2018 @ 12:25:
Ik heb vrijwel hetzelfde gedaan als @Hydra.

spoiler:

Maar is het eigenlijk niet logisch dat het 1 regio is.

Volkomen logisch. Je moet er alleen wel ff op komen. En da's bij mij meestal het probleem Dit soort dingen 'zien' is niet bepaald m'n sterkte punt

[Soultaker]

Ligt het aan mij of klopt het voorbeeld van dag 6 niet?
Ligt aan mij, ik kan niet tellen

aaaaa1cccc
aAaaa.cccc
aaaddecccc
aadddeccCc
..dDdeeccc
bb.deEeecc
bBb.eeee..
bbb2eeefff
bbb3eeffff
bbb.ffffFf

De punten die ik met cijfers 1, 2, 3 heb gemarkeerd, zijn in het voorbeeld leeg ('.'). Maar 1 ligt dichter bij A dan C, en 2 en 3 dichter bij B dan E, dus volgens mij hadden die punten ingekleurd moeten zijn.

[ Voor 8% gewijzigd door Soultaker op 06-12-2018 16:36 ]

[Lye]

Soultaker schreef op donderdag 6 december 2018 @ 16:22:
Ligt het aan mij of klopt het voorbeeld van dag 6 niet?

aaaaa1cccc
aAaaa.cccc
aaaddecccc
aadddeccCc
..dDdeeccc
bb.deEeecc
bBb.eeee..
bbb2eeefff
bbb3eeffff
bbb.ffffFf

De punten die ik met cijfers 1, 2, 3 heb gemarkeerd, zijn in het voorbeeld leeg ('.'). Maar 1 ligt dichter bij A dan C, en 2 en 3 dichter bij B dan E, dus volgens mij hadden die punten ingekleurd moeten zijn.

Voor punt 1 geldt dat A en E even ver weg liggen (beide 5). Voor 2 en 3 geldt dan weer dat ze even ver van B en D liggen.

[Soultaker]

Lye schreef op donderdag 6 december 2018 @ 16:32:
Voor punt 1 geldt dat A en E even ver weg liggen (beide 5). Voor 2 en 3 geldt dan weer dat ze even ver van B en D liggen.

Je hebt gelijk! Ik had me verteld. (Kun je ook beter aan de computer overlaten.)

[Lye]

Poeh, vandaag wel redelijk snel opgelost met een hele naïeve oplossing (Duurde ook zeker 10 seconden om te draaien). Na enkele optimalisaties leek dit beter te gaan, maar toen bleek deel 2 niet meer te kloppen voor een andere input.

Mijn bounding box bleek veel te klein, simpelweg de minimale en maximale waarden pakken lijkt voor de gegeven input te kloppen, echter voor andere inputs totaal niet.

Ik heb nu executietijden van ~150ms voor deel 1 en ~160ms voor deel 2, dit bezint mij totaal niet maar ik zou niet weten waar ik verder kan optimaliseren...

[ Voor 10% gewijzigd door Lye op 06-12-2018 23:08 ]

[farlane]

Godnondeju fuck Rust ...... ik geef het op.

[Anoniem: 1004565]

Eindelijk snapte ik het probleem, en was het redelijk te doen in Rust!


https://github.com/DutchG.../master/day06/src/main.rs , 133.507897ms
https://github.com/DutchG...aster/day06_2/src/main.rs, 7.603355ms

[ Voor 16% gewijzigd door Anoniem: 1004565 op 06-12-2018 22:19 ]

[Boudewijn]

Ik ben met dag 4 begonnen, jeetje wat een lelijk probleem. Als het telkens complexer wordt ben je op dag 25 wel even bezig met je parser .

[Lye]

Anoniem: 1004565 schreef op donderdag 6 december 2018 @ 22:16:
Eindelijk snapte ik het probleem, en was het redelijk te doen in Rust!


https://github.com/DutchG.../master/day06/src/main.rs , 133.507897ms
https://github.com/DutchG...aster/day06_2/src/main.rs, 7.603355ms

Jouw deel 2 gaat mank op de volgende input:

1, 1

zou als output 199980001 moeten hebben. Hetzelfde probleem had ik dus ook

[Alain]

Boudewijn schreef op donderdag 6 december 2018 @ 22:43:
Ik ben met dag 4 begonnen, jeetje wat een lelijk probleem. Als het telkens complexer wordt ben je op dag 25 wel even bezig met je parser .

Dag 5 is een makkie Boudewijn.

[Anoniem: 1004565]

Lye schreef op donderdag 6 december 2018 @ 22:51:
[...]


Jouw deel 2 gaat mank op de volgende input:

1, 1

zou als output 199980001 moeten hebben. Hetzelfde probleem had ik dus ook

Komt 1, 1 voor in een input? Als dat het geval is, heb ik geluk gehad. haha

[Hydra]

Jezus. Dit duurde ff...

Dag 7 in Kotlin

Heel lang met deel 2 bezig geweest, gewoon omdat ik de instructies tot 2 keer toe niet goed gelezen had en een belangrijk detail gemist heb. Genant

Boudewijn schreef op donderdag 6 december 2018 @ 22:43:
Ik ben met dag 4 begonnen, jeetje wat een lelijk probleem. Als het telkens complexer wordt ben je op dag 25 wel even bezig met je parser .

Het wisselt een beetje. Ik vermoed ook dat 'ie de meer complexere in de weekended doet, dus ik verwacht een 'leuke' komend weekend.

[ Voor 37% gewijzigd door Hydra op 07-12-2018 08:16 ]

[ppx17]

Was best een leuke, oplossing draait in 0.5 ms dus voel niet echt een noodzaak om verder te optimaliseren.

Day 7 in PHP

[Woy]

Boudewijn schreef op donderdag 6 december 2018 @ 22:43:
Ik ben met dag 4 begonnen, jeetje wat een lelijk probleem. Als het telkens complexer wordt ben je op dag 25 wel even bezig met je parser .

Mwah, ik parse hem gewoon met 1 Regex

spoiler:

[code=regex]
^\[\d+-\d+-\d+ \d+:(?<minutes>\d+)\] (?<type>Guard|wakes|falls) (#(?<guardNum>\d+))?
[/code]
Ik sorteer eerst gewoon string based, dus de datum interesseert me verder niet meer, maar die kan je natuurlijk ook gewoon helemaal parsen.

Het kan zelfs nog wel wat simpeler, want je kan natuurlijk ook gewoon een switch op col 20 van de string doen voor het type. Alleen als het een 'G' is hoef je het Guardnum te parsen, en als het een 'w' of 'f' is moet je de minutes parsen.

[ Voor 17% gewijzigd door Woy op 07-12-2018 09:03 ]

[heuveltje]

Waarom zie ik dit topic nu pas ?

Ben mezelf c# aan het leren, dus dit zijn leuke vingeroefeningen.
Alleen of ik doe iets fout, of ik snap vraag 1 dag 2 al niet

Bij mij komt elke waarde maar 1 keer voor, en ben er redelijk zeker van dat dat mijn code klopt (excel vond dat ook namelijk )
Of is het de bedoeling dat je net zo vaak door die lijst blijft loopen totdat je ergens een duplicaat vind ?

[emnich]

aaargh, ik kom er niet uit vandaag. Mijn tests lopen perfect maar deel 2 krijg ik geen juist antwoord.

spoiler:

met 5 workers bedoelen ze toch 5 workers, en niet 6?

[edit]
never mind, zie de fout denk ik al.

[ Voor 11% gewijzigd door emnich op 07-12-2018 10:26 ]

[BernardV]

heuveltje schreef op vrijdag 7 december 2018 @ 10:16:
Waarom zie ik dit topic nu pas ?

Ben mezelf c# aan het leren, dus dit zijn leuke vingeroefeningen.
Alleen of ik doe iets fout, of ik snap vraag 1 dag 2 al niet

Bij mij komt elke waarde maar 1 keer voor, en ben er redelijk zeker van dat dat mijn code klopt (excel vond dat ook namelijk )
Of is het de bedoeling dat je net zo vaak door die lijst blijft loopen totdat je ergens een duplicaat vind ?

En als je de input van de pagina zelf gebruikt dan?

[Radiant]

heuveltje schreef op vrijdag 7 december 2018 @ 10:16:

Of is het de bedoeling dat je net zo vaak door die lijst blijft loopen totdat je ergens een duplicaat vind ?

Dat ja.

[SuppaTim]

Was me een dagje wel vandaag. Na 4 uur lang haren uit het hoofd hebben getrokken heb ik besloten de tekst van 2 maar eens goed te lezen. Dat hielp

[sjakie02]

Zo dag 7 was wel stuk simpeler dan dag 6

[heuveltje]

bernardV schreef op vrijdag 7 december 2018 @ 10:36:
[...]

En als je de input van de pagina zelf gebruikt dan?

Die had ik dus gebruikt .

Radiant schreef op vrijdag 7 december 2018 @ 11:06:
[...]

Dat ja.

Dat verklaart
Thuis eens opnieuw draaien met een extra loop erin

[ElkeBxl]

sjakie02 schreef op vrijdag 7 december 2018 @ 11:19:
Zo dag 7 was wel stuk simpeler dan dag 6

Ik vond dag 7 juist irritanter om goed te krijgen.

Zeker deel 2 explodeerde nogal bij mij qua lijnen code maar het werkt en dat is enige dat telt voor mij

[Woy]

sjakie02 schreef op vrijdag 7 december 2018 @ 11:19:
Zo dag 7 was wel stuk simpeler dan dag 6

Dan doe jij 6 verkeerd of ik 7, maar zeker 6 part 2 was erg eenvoudig IMHO

spoiler:

[code=c#]
var result = (from x in Enumerable.Range(0, input.Max(p=>p.x))
from y in Enumerable.Range(0, input.Max(p=>p.y))
where input.Sum(point=>Dist((x,y), point)) < 10000
select (x,y)).Count();
[/code]