Advent of Code 2018

[Daanoz]

Wederom komt december eraan, voor de puzzel fanaten is de Advent of Code er dus weer! Van 1 tot en met 25 december zijn er elke dag 2 puzzels beschikbaar, om zo het grote raadsel van dit jaar op te lossen. De raadsels zijn zo opgezet dat ze het beste met een stuk programmatuur kunnen worden opgelost. Uiteindelijk krijg je elke dag jou eigen unieke input, waarbij één bepaalde output hoort.

Een puzzel is gebruikelijk in een soort verhaal vorm geschreven. Een goed voorbeeld, ook om te oefenen vind je hier.

Ook in 2015, 2016 en 2017 deed de Tweakers community mee, dus ook dit jaar kunnen we weer aan de slag:
Advent of Code 2015
Advent of Code 2016
Advent of Code 2017 Leaderboard

Je kan je aanmelden via website: https://www.adventofcode.com. Op de website is er weer een tweakers leaderboard. Dit is dezelfde als vorig jaar, meld je hier aan met code:

Members only: Leaderboard code

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Discussie over de puzzels mag, maar probeer niets te spoilen voor de rest! (of gebruik de spoiler tag)

Members only: Deelnemerslijst

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Stuur Daanoz even een PM om ook in de lijst te komen. Zet hierbij de link naar de code en de taal/talen die je gebruikt.

edit:
20-11: Na overleg deelnemers lijst members only gemaakt

Snapshot leaderboard (8-12-2019):

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 32% gewijzigd door Daanoz op 08-12-2019 20:14 ]

[winkbrace]

Ah cool. Ik zie dat ik nog in het leaderbord sta van vorig jaar.

Maar dit jaar ga ik er ook echt aan meedoen!

[boe2]

code:

That isn't a recognized sponsor join code.

[steveman]

Ohja! Was nog met die van 2016 bezig

[Daanoz]

boe2 schreef op maandag 19 november 2018 @ 15:06:

code:

That isn't a recognized sponsor join code.

Hmm, strange. De code zou ok moeten zijn... Geen spaties o.i.d. er achter?

[boe2]

Nee, extra goed op gelet, maar hij wil het echt niet accepteren.

*edit* ooow, private leaderboard != sponsored group. Het werkt

[ Voor 34% gewijzigd door boe2 op 19-11-2018 21:43 ]

[Daos]

Bij mij werkt het wel. Zit je wel op de juiste pagina? Je moet hier zijn: https://adventofcode.com/2018/leaderboard/private

[MerijnB]

Is het alweer zover, ben benieuwd wat ze nu weer allemaal bedacht hebben :-)

[Swedish Clown]

Ik ga me best doen om mee te doen en bij te blijven. Meestal haak ik af vanwege vakanties maar dit jaar blijf ik in Zweden hangen dus we gaan het zien

Uiteraard in Erlang

Erlang:

fun() -> io:format("Let's do this!~n") end.

[Camulos]

Veel zin in!
Ik vraag me af of ik dit keer wel tot het einde ga halen

[Anoniem: 159174]

Vorig jaar C (was leuk tot op zekere hoogte), nu Python 3 (want daarmee bezig). Ga nu toch voor optimaliseren developmenttime ipv runtime, denk ik...

[RoadRunner84]

Ik ga denk ik mee doen in C(++) met nadruk op TDD

[Daanoz]

Hmm, dat lijkt me een goede uitdaging met TDD. In mijn normale werk, werk ik vanaf een enigzins bekend of verwachte antwoord / output terug naar de implementatie. In dit geval mist natuurlijk het (uiteindelijke) antwoord, dus veel kleinere incrementele stapjes?

[Hydra]

Ben nu ff een beetje bezig met Rust maar ik merk wel dat ik op dit moment het memory management gewoon niet goed genoeg in de vingers heb. Tijd om me daar eerst ff in te verdiepen. Maar 't kan goed zijn dat ik alsnog eerst de opdrachten in Kotlin doe en ze daarna naar Rust ga vertalen. Ben nu nog wat te roestig

[MerijnB]

Hydra schreef op vrijdag 23 november 2018 @ 16:01:
Ben nu ff een beetje bezig met Rust maar ik merk wel dat ik op dit moment het memory management gewoon niet goed genoeg in de vingers heb. Tijd om me daar eerst ff in te verdiepen. Maar 't kan goed zijn dat ik alsnog eerst de opdrachten in Kotlin doe en ze daarna naar Rust ga vertalen. Ben nu nog wat te roestig

Beetje rusty lijkt me de ideale state of mind om met Rust aan de gang te gaan ;-)

[ElkeBxl]

Ik ga poging doen mee te doen En ik ga een oude geliefde van mij bovenhalen: Racket (ooit DrScheme). Heb ik op unief in leren programmeren. Jaren geleden dat ik die taal nog eens aanraakte, ik heb zin om eens nostalgisch te doen

[Ryada]

Ik doe ook wer mee, hopelijk lukt het me dit jaar wel om hem volledig af te maken.
Net als vorig jaar gewoon weer in C# ^^ Heb er zin in.

[Camulos]

Ryada schreef op maandag 26 november 2018 @ 10:30:
Net als vorig jaar gewoon weer in C# ^^ Heb er zin in.

Nice ook een C#'er ben benieuwd hoe jij ze oplost!

[Ryada]

Camulos schreef op donderdag 29 november 2018 @ 10:36:
[...]


Nice ook een C#'er ben benieuwd hoe jij ze oplost!

Zal mijn best doen om niet teleur te stellen
Ben ook benieuwd hoe jij ze zal oplossen, meestal kan je wel wat van elkaar leren met dit soort dingen ^^

[DRaakje]

Ik ben er ook klaar voor. Deze keer met automatisch ophalen van de input en het submitten van het antwoord. Verder in linqpad ipv Visual Studio.

Misschien dat ik f# ga proberen, maar c# als fallback gebruik.

C#:

var aoc = new AdventOfCode(2018, 1);

//do stuff

aoc.SubmitAnswer(12, Part.A);

[ Voor 19% gewijzigd door DRaakje op 29-11-2018 11:05 ]

[Anoniem: 1004565]

Ik doe ook weer mee! In Rust, en Zig!
Zig is een nieuwe taal dat nog niet heel bekend is, en het zit nu op versie 0.3.

Zig is gecompileerd, en zit ongeveer op het zelfde niveau kwa runtime als Rust.

Het heeft het features die erg leuk zijn, zoals compiletime evaluation, compiletime loopunrolling, en pattern matching (helaas is dat laatste niet zo sterk als in Rust).

Dit is de website: https://ziglang.org/ ,
En hier wat video's naar de persoon die de taal bedacht heeft: YouTube: Andrew Kelley

[Knutselsmurf]

DRaakje schreef op donderdag 29 november 2018 @ 11:03:
Ik ben er ook klaar voor. Deze keer met automatisch ophalen van de input en het submitten van het antwoord. Verder in linqpad ipv Visual Studio.

Misschien dat ik f# ga proberen, maar c# als fallback gebruik.

C#:

var aoc = new AdventOfCode(2018, 1);

//do stuff

aoc.SubmitAnswer(12, Part.A);

Is dat een zelf geschreven class? Of heb je die ergens vandaan?

[Radiant]

DRaakje schreef op donderdag 29 november 2018 @ 11:03:
Ik ben er ook klaar voor. Deze keer met automatisch ophalen van de input en het submitten van het antwoord. Verder in linqpad ipv Visual Studio.

Misschien dat ik f# ga proberen, maar c# als fallback gebruik.

C#:

var aoc = new AdventOfCode(2018, 1);

//do stuff

aoc.SubmitAnswer(12, Part.A);

Zorg wel dat je de input cachet na 1x opvragen, ik zie de maker daar op reddit vaak voor waarschuwen.. Anders kost het 'm veel dataverkeer en krijg je misschien een ban.

[Hydra]

Zoals gewoonlijk een eenvoudige dag. Heb het wel eerst in Kotlin gedaan omdat ik met Rust nog te veel met de syntax aan 't klooien ben (hoewel je type inference hebt is 'ie minder 'slim' dan in Kotlin).

Kotlin versie
Rust versie

[ElkeBxl]

Zonet opgelost. My god wat zijn mijn Racket skills roestig geworden... En direct te merken dat Racket niet de meest snelle is maar het werkt gelukkig wel

[Radiant]

We zijn weer begonnen, nice

Deel 1 met slaapdronken harses in Google Sheets opgelost en voor deel 2 toch maar Python erbij gepakt

Hopelijk kan ik dit jaar nog meer Python leren

[veldsla]

Hydra schreef op zaterdag 1 december 2018 @ 08:34:
Zoals gewoonlijk een eenvoudige dag. Heb het wel eerst in Kotlin gedaan omdat ik met Rust nog te veel met de syntax aan 't klooien ben (hoewel je type inference hebt is 'ie minder 'slim' dan in Kotlin).

Kotlin versie
Rust versie

Bedoel je de hint op de sum adaptor? Die zit er met een reden. Verder kan de type annotation op de hashset weg en die to_string is ook niet nodig want dat doet de println! macro ook al. (al zal die er wel zitten vanwege je nog(?) niet gebruikte trait definitie in je lib).

Niemand gevallen over de eerste test van part 2?

Mijn rust versie met volledige testset en error handling. Ziet er braaf uit, maar eigenlijk heb ik dit gebruikt om te submitten :

spoiler:

cat input.txt |perl -ne '$a+=$_; print "$a\n";' |tail -1
while true; do cat input.txt; done | perl -ne '$a += $_; print "$a\n" if exists $h{$a}; $h{$a}=0' |head

[ Voor 10% gewijzigd door veldsla op 01-12-2018 14:41 ]

[Ryada]

Eerste dag af, was best prima te doen.
Voor de grap ook eens een UWP app ervan gemaakt.
Als mensen intresse hebben hier is de repo: https://github.com/RyadaProductions/AdventOfCode2018

[ Voor 35% gewijzigd door Ryada op 01-12-2018 12:56 ]

[diabolofan]

Ook gemaakt. Duurde even voordat ik doordat hoe ze nu die tweede bedoelde.

spoiler: title

Blijkbaar begon die alleen maar opnieuw aan het einde van de lijst, ik dacht eerst dat hij ook in het midden van de lijst opnieuw zou kunnen beginnen.

[Gropah]

diabolofan schreef op zaterdag 1 december 2018 @ 12:58:
Ook gemaakt. Duurde even voordat ik doordat hoe ze nu die tweede bedoelde.

spoiler: title

Blijkbaar begon die alleen maar opnieuw aan het einde van de lijst, ik dacht eerst dat hij ook in het midden van de lijst opnieuw zou kunnen beginnen.

Ik had hem in het begin ook niet helemaal door

Heb me ook maar aangemeld voor het leaderbord, maar ik weet niet of ik het ga volhouden. Ach ik zie wel. Code houd ik liever prive, want is echt niet om over naar huis te schrijven op dit moment. Gebruik het om Go een beetje beter onder de knie te krijgen. Misschien dat het later nog openbaar word.

[diabolofan]

Geen idee of dit een spoiler is, maar dus maar voor de zekerheid..

spoiler:

Gebruik van een Dictionary<int, bool> om de al bereikte waarden op te slaan is in ieder geval een stuk sneller dan wanneer je deze bereikte waarden opslaat in een List<int>. Performance van List<int> is 13584ms, met een Dictionary 48 ms. Uiteraard logisch, maar werk toch vaak uit automatisme met List's.

[Hydra]

veldsla schreef op zaterdag 1 december 2018 @ 10:29:
Niemand gevallen over de eerste test van part 2?

De beschrijving was onduidelijk, ik heb goed gegokt kwa interpretatie. Vorig jaar op iets soortgelijks hard vastgezeten (best frustrerend ook) maargoed, hij doet z'n best

[Hydra]

diabolofan schreef op zaterdag 1 december 2018 @ 13:19:
Geen idee of dit een spoiler is, maar dus maar voor de zekerheid..

spoiler:

Gebruik van een Dictionary<int, bool> om de al bereikte waarden op te slaan is in ieder geval een stuk sneller dan wanneer je deze bereikte waarden opslaat in een List<int>. Performance van List<int> is 13584ms, met een Dictionary 48 ms. Uiteraard logisch, maar werk toch vaak uit automatisme met List's.

spoiler:

*kuch*HashSet*kuch*

[diabolofan]

Hydra schreef op zaterdag 1 december 2018 @ 13:31:
[...]

spoiler:

*kuch*HashSet*kuch*

Haha, kan ook, is net zo snel zie ik, alleen zal de memory usage iets minder zijn..

[Woy]

Hydra schreef op zaterdag 1 december 2018 @ 08:34:
Zoals gewoonlijk een eenvoudige dag. Heb het wel eerst in Kotlin gedaan omdat ik met Rust nog te veel met de syntax aan 't klooien ben (hoewel je type inference hebt is 'ie minder 'slim' dan in Kotlin).

Kotlin versie
Rust versie

Beide oplossingen voldoen niet 100% aan de voorwaarden, je vergeet de initiële frequentie ook mee te nemen

[Hydra]

Woy schreef op zaterdag 1 december 2018 @ 14:25:
Beide oplossingen voldoen niet 100% aan de voorwaarden, je vergeet de initiële frequentie ook mee te nemen

Die is 0?

[Woy]

Hydra schreef op zaterdag 1 december 2018 @ 14:28:
[...]


Die is 0?

Yup, maar je stop hem niet in je set, dus zal de eerste example bij jou ook het verkeerde antwoord geven

+1, -1 first reaches 0 twice.

[Hydra]

Woy schreef op zaterdag 1 december 2018 @ 14:30:
Yup, maar je stop hem niet in je set, dus zal de eerste example bij jou ook het verkeerde antwoord geven

Oh, op die fiets. Tja. Het boeit niet met de input die ik heb.

[Lye]

Ik doe ook weer mee in Kotlin. Simpele inkomer vandaag.

[ThomasG]

diabolofan schreef op zaterdag 1 december 2018 @ 13:19:
Geen idee of dit een spoiler is, maar dus maar voor de zekerheid..

spoiler:

Gebruik van een Dictionary<int, bool> om de al bereikte waarden op te slaan is in ieder geval een stuk sneller dan wanneer je deze bereikte waarden opslaat in een List<int>. Performance van List<int> is 13584ms, met een Dictionary 48 ms. Uiteraard logisch, maar werk toch vaak uit automatisme met List's.

spoiler:

Als het puur om performance gaat kun je ook een of twee integers gebruiken, en de bit posities gebruiken om bij te houden of het al voorgekomen is. Het nadeel daarvan is dat de code complexer wordt en je een limiet hebt qua invoerde waarde (ongeveer 15 tot -15 bij 32 bit int). Maar qua performance en memory footprint is het super

[Lye]

diabolofan schreef op zaterdag 1 december 2018 @ 13:34:
[...]


Haha, kan ook, is net zo snel zie ik, alleen zal de memory usage iets minder zijn..

spoiler:

Dat vind ik niet zo gek, een veel gebruikte HashSet implementatie is door intern een HashMap/Dictionary te gebruiken. In ieder geval Javas implementatie is zo.

[Hydra]

Lye schreef op zaterdag 1 december 2018 @ 14:54:
Ik doe ook weer mee in Kotlin. Simpele inkomer vandaag.

spoiler:

override fun first(input: Sequence<String>): Any = input
.map(String::toInt)
.fold(STARTING_FREQUENCY, Int::plus)

Gewoon .sum() kan ook Kotlin heeft een hoop handige extension methods afhankelijk van het type van je List of Sequence. Dus List<Int> heeft sum, avg, etc.

[Lye]

Hydra schreef op zaterdag 1 december 2018 @ 15:17:
[...]

spoiler:

override fun first(input: Sequence<String>): Any = input
.map(String::toInt)
.fold(STARTING_FREQUENCY, Int::plus)

Gewoon .sum() kan ook Kotlin heeft een hoop handige extension methods afhankelijk van het type van je List of Sequence. Dus List<Int> heeft sum, avg, etc.

Dat klopt inderdaad, maar dan mis ik dus de initiële frequentie, achteraf gezien had ik die er inderdaad net zo goed na de tijd bij op kunnen tellen.. Aan de andere kant, is er op deze manier wel enige consistentie met de tweede opdracht

[Swedish Clown]

Klaar Code staat op Github. Resultaat voor beide delen in gemiddeld 416ms. Eens zien of dat nog wat omlaag kan.

spoiler:

Dag 1 is een makkie Dag 2 had ik in eerste niet door wat ze precies verwachte en ging ik er niet vanuit dat ik meerdere malen de list zou moeten doorlopen,

[ Voor 45% gewijzigd door Swedish Clown op 01-12-2018 20:28 ]

[emnich]

Leuk, ik doe ook weer mee, hoewel ik vaak halverwege wegens tijdgebrek toch weer afhaak. Eens kijken of ik het dit jaar kan volhouden.

[Antrax]

Err mag ik die van 2016 nog even afmaken?

[Hydra]

@Daanoz kun je die van mij terugzetten naar Kotlin / https://github.com/nielsutrecht/adventofcode? Ik laat Rust nu ff 'rusten' (heh), ben te veel met de compiler aan 't vechten op dit moment om er lol van te hebben. Ga 't misschien later een keer converteren maar vind op dit moment het de tijdsinvestering niet waard.

Mijn oplossing voor dag 2 (Kotlin)

[ Voor 20% gewijzigd door Hydra op 02-12-2018 11:40 ]

[DRaakje]

Leuke voor vandaag, ik vond het wel een simpel genoege om te kijken of ik zoveel mogelijk met Linq kon oplossen.

Ik vond part 1 lastiger als part2. Ben wel blij met oplossing voor part2, die vond ik wel elegant.

Pastebin code in C#

[ Voor 9% gewijzigd door DRaakje op 02-12-2018 11:36 . Reden: Spelling ]

[Gropah]

Ik ben ook weer klaar voor vandaag. Vond de eerste naarder dan de 2e. Bij die eerste had ik schijnbaar moeite met

spoiler:

het vinden van de occurrences met een eigenlijk lelijke manier. Ben toen maar naar een meer logische manier overgeschakeld, maar bleef wel iets te lang hangen volgens mij.

Grappig om te zien dat er meer mensen zijn die Go gebruiken. Heb even door je code gekeken voor dag 1 @T.G, ziet er goed uit. Handig ook met de documentatie. Je hebt het jezelf alleen wel een beetje moeilijk gemaakt, strconv.Atoi kan namelijk prima omgaan met de + of de - er voor

Je wilt btw niet weten hoe naar het is om antwoorden in Go te vinden op reddit omdat veel mensen go neerplempen ipv golang en omdat bij alle reactie's staat X time ago, vind hij dat allemaal. De naam hadden ze wel iets beter over na mogen denken maar als taal is het wel prima

[diabolofan]

DRaakje schreef op zondag 2 december 2018 @ 11:35:
Leuke voor vandaag, ik vond het wel een simpel genoege om te kijken of ik zoveel mogelijk met Linq kon oplossen.

Ik vond part 1 lastiger als part2. Ben wel blij met oplossing voor part2, die vond ik wel elegant.

Pastebin code in C#

Ik ook dag 2 klaar. Met Linq ziet het er wel een stukje cleaner uit, ik heb het gewoon met old school forloopjes gedaan

[Swedish Clown]

Aangezien ik een nerd ben als het gaat om performance in dit soort puzzles en het voldoen van alle dagen mij niet eens zoveel interesseert, ben ik wel benieuwd wat de executie tijden zijn voor iedereen?

Parsen van input + deel 1 + deel 2. Wat zijn jullie tijden?

[Gropah]

Brakkie41 schreef op zondag 2 december 2018 @ 11:57:
Aangezien ik een nerd ben als het gaat om performance in dit soort puzzles en het voldoen van alle dagen mij niet eens zoveel interesseert, ben ik wel benieuwd wat de executie tijden zijn voor iedereen?

Parsen van input + deel 1 + deel 2. Wat zijn jullie tijden?

Geef dan zelf het goede voorbeeld

Ik heb gebenchmarkt met de ingebouwde tools van Go, puur op de berekening (io vind ik niet meetellen met benchmarks).

Deel 1: 541164 ns => .541ms
Deel 2: 487599 ns => .486ms


edit 1: Moet ik wel daadwerkelijk IO uit de benchmarks halen
edit 2: kleine optimalisatie voor deel 2. Van .624ms naar .486ms

[ Voor 14% gewijzigd door Gropah op 02-12-2018 13:12 ]

[DRaakje]

PartA: 2 ms
PartB: 44 ms

[T.G]

Gropah schreef op zondag 2 december 2018 @ 11:53:
Grappig om te zien dat er meer mensen zijn die Go gebruiken. Heb even door je code gekeken voor dag 1 @T.G, ziet er goed uit. Handig ook met de documentatie. Je hebt het jezelf alleen wel een beetje moeilijk gemaakt, strconv.Atoi kan namelijk prima omgaan met de + of de - er voor

Dat wist ik niet.. Maar ik zie nu inderdaad een voorbeeld met "-42" letterlijk in de documentatie staan (https://golang.org/pkg/strconv/).

Ik heb ook feedback gekregen op het gebruiken van een slice in combinatie met mijn "contains" function.

Ik heb begrepen dat het meer Go idiomatic is om een

code:

map[int]struct{}

te hanteren ipv een slice. Je kan dan in één keer controleren of de key in de map aanwezig is. Zou sneller zijn. Een lege struct neemt ook geen geheugen in.

AOC is in ieder geval een leuke manier om Go te leren. Als je meer feedback hebt, hoor ik 't graag.

Gropah schreef op zondag 2 december 2018 @ 11:53:
Je wilt btw niet weten hoe naar het is om antwoorden in Go te vinden op reddit omdat veel mensen go neerplempen ipv golang en omdat bij alle reactie's staat X time ago, vind hij dat allemaal. De naam hadden ze wel iets beter over na mogen denken maar als taal is het wel prima

Haha ja inderdaad, je zou 'golang' moeten gebruiken op dat soort plaatsen.

Ik ga nu beginnen aan dag 2

[Gropah]

T.G schreef op zondag 2 december 2018 @ 12:08:
[...]

Ik heb begrepen dat het meer Go idiomatic is om een

code:

map\[int]struct{}

te hanteren ipv een slice. Je kan dan in één keer controleren of de key in de map aanwezig is. Zou sneller zijn. Een lege struct neemt ook geen geheugen in.

AOC is in ieder geval een leuke manier om Go te leren. Als je meer feedback hebt, hoor ik 't graag.
[...]

slice vs map hangt denk ik erg af van het probleem waar je aan werkt en wat je prefereert. Zou best kunnen dat een map meer idiomatic is. Qua performance in dit geval waarschijnlijk ook, omdat je er niet over zal gaan loopen, tenzij je de slice gaat pre-setten met 0'en voor alle mogelijke getallen (hier dus niet mogelijk).

Weet btw niet of ik je veel tips zal kunnen geven. Ik ben wel wat bekend met Go, maar dat is voornamelijk van API's bouwen en databases er aan knopen. Erg handig daarvoor, maar wel andere koek dan dit.

[Hydra]

Brakkie41 schreef op zondag 2 december 2018 @ 11:57:
Parsen van input + deel 1 + deel 2. Wat zijn jullie tijden?

total: 113 ms part1: 2 ms part2: 111 ms

Da's overigens zonder het inlezen van de input in een list.

Edit: Dat maakt niet uit

Mijn 'part2' is trouwens extreem inefficient, m'n doel was vooral om 't volledig FP te maken, niet om de beste speed te halen.

[Swedish Clown]

Gropah schreef op zondag 2 december 2018 @ 12:00:
[...]


Geef dan zelf het goede voorbeeld

Ik heb gebenchmarkt met de ingebouwde tools van Go, puur op de berekening (io vind ik niet meetellen met benchmarks).

Deel 1: 541164 ns => .541ms
Deel 2: 624308 ns => .624ms

Point taken 😉 208ms voor input, a en b. Zit nog beetje te puzzelen met performance. Erlang is verre van ideaal als het om strings gaat helaas.

[Ryada]

Mijn benchmarks zouden veruit langzamer zijn dan de rest van jullie. Voornamelijk omdat ik er boilerplate omheen heb zitten zodat ik de UI kan updaten.
Ben helaas niet erg tevreden over hoe ik deel 2 heb gedaan, daarintegen was ik vrij vlot klaar met deel 1 vandaag.
Wel even laten zien dat ik ook echt een UI ervoor gebruik
[Video: https://i.imgur.com/W1MMsmE.gifv]

EDIT: moet alleen nog even iets bedenken voor input validation, want als ik nu perongelijk mijn input bij dag 1 invul dan gaat hij over zijn nek

[ Voor 16% gewijzigd door Ryada op 02-12-2018 12:23 ]

[diabolofan]

C#, dag 2
Part 1: 1,4125 ms
Part 2: 3,4382 ms

Dit is dan wel bij de tweede executie van de part1/part2 methodes, zodat JIT compilatie er niet bij zit... Als ik dit namelijk niet doe, dan zijn part 1 en part 2 zo goed als gelijk (varieert beetje per executie) rond de 30 ms, dus die JIT compilatie kost blijkbaar veel tijd in verhouding met de echte executie.

[ Voor 39% gewijzigd door diabolofan op 02-12-2018 12:26 ]

[emnich]

PHP dag 2
Part 1: 1.7ms
part2: 1.0ms

Part 1 heb ik niet echt geoptimaliseerd...

[edit]
Part 1 nu ook in 0.9ms

[ Voor 17% gewijzigd door emnich op 02-12-2018 12:54 ]

[Creepy]

Ryada schreef op zondag 2 december 2018 @ 12:21:
Wel even laten zien dat ik ook echt een UI ervoor gebruik
[Gifv]

Een UI? De commandline is UI genoeg Filename meegeven als parameter, uitlezen en output uitspugen naar de console.

Ik moet nog eens kijken of ik echt kan meedoen de komende dagen. Ik heb het idee opgevat om te kijken of ik het in Z80 assembly op een MSX kan doen (i.t.t. java op m'n pc) , maar ik vrees dat dat te snel te traag gaat worden of in geheugen problemen ga komen bij de latere opdrachten. De eerste 2 dagen zou prima moeten lukken als ik de eerste opdracht per dag zo bekijken

[Lye]

Mijn dag 2 is ook klaar. Opzich ben ik niet helemaal blij met mijn implementatie om de gelijke characters te houden (en te kappen als er teveel verschillen zijn) maar deze manier is stukken sneller. Ik zit nu op ~10ms voor part 1 en ~15ms voor part 2, daar kan ik wel mee leven.

Overigens heb ik wel even een functie "gestolen" uit Haskell, ik had tails nodig.

[ Voor 16% gewijzigd door Lye op 02-12-2018 13:56 ]

[Anoniem: 1004565]

Hoe benchmarken jullie? Op windows is er wel het 'Measure-Command {....}' commando, maar dit is niet echt de beste manier om te meten naar mijn idee.

Gewoon gebruik maken van de time module in de taal?

[Anoniem: 1004565]

Anoniem: 1004565 schreef op zondag 2 december 2018 @ 14:18:
Hoe benchmarken jullie? Op windows is er wel het 'Measure-Command {....}' commando, maar dit is niet echt de beste manier om te meten naar mijn idee.

Gewoon gebruik maken van de time module in de taal?

In het geval van de time module in de taal,

tussen de 500.00µs en 1000.00 µs voor part1,
2.119505ms voor part 2.

[Pinobigbird]

Ik heb al een aantal jaren meegelezen en getwijfeld om mee te doen. Ik ben geen ontwikkelaar, maar ik doe voor m'n werk aardig wat met (My)SQL. Ik heb nu voor het eerst de puzzels gemaakt in MariaDB en tot nu toe vind ik het erg leuk.
Het gaat mij nu niet om de performance of UI, ik lees de input in een tabel in, en maak dan per vraag een stored procedure. Tot nu toe heb ik alle 4 de puzzels kunnen oplossen
Vanwege de vakantie ga ik komende week sowieso missen, maar ik ga proberen die evt. later alsnog te doen.

[Lye]

Anoniem: 1004565 schreef op zondag 2 december 2018 @ 14:18:
Hoe benchmarken jullie? Op windows is er wel het 'Measure-Command {....}' commando, maar dit is niet echt de beste manier om te meten naar mijn idee.

Gewoon gebruik maken van de time module in de taal?

Ik gebruik gewoon Java's System.nanoTime. Ik wil geen door het OS aangeleverde measuring tools gebruiken (zoals Linux' times) omdat ik dan met de overhead van de JVM en mijn framework zit (die doet ook nog dingen).

Kotlin heeft ook wel een mooie standaard functie voor dit soort dingen (measureNanoTime) maar daar kan ik geen return value uitkrijgen.

[ Voor 25% gewijzigd door Lye op 02-12-2018 14:35 ]

[dcm360]

Kom ik even aanzetten met een halve seconde voor het tweede deel van vandaag Nu ben ik ook totaal niet aan het optimaliseren voor de runtime, met de nog zeer eenvoudige puzzeltjes als deze vind ik dat ook nog niet nodig.

[Gropah]

Anoniem: 1004565 schreef op zondag 2 december 2018 @ 14:18:
Hoe benchmarken jullie? Op windows is er wel het 'Measure-Command {....}' commando, maar dit is niet echt de beste manier om te meten naar mijn idee.

Gewoon gebruik maken van de time module in de taal?

Ik gebruik de benchmark mogelijkheden van golangs testing package. Erg fijn, je weet binnen en redelijke tijd de performance van specifieke delen code, als je dat wil.

[Hydra]

Anoniem: 1004565 schreef op zondag 2 december 2018 @ 14:18:
Hoe benchmarken jullie? Op windows is er wel het 'Measure-Command {....}' commando, maar dit is niet echt de beste manier om te meten naar mijn idee.

Gewoon meten van aantal ms om de functie heen. Heb een simpel [runnertje](https://github.com/nielsu...projects/advent/Runner.kt) die het meet. Een echte benchmark is het niet; hij houdt geen rekening met JIT warmup. Dan zou ik iets als JMH gaan gebruiken.

Lye schreef op zondag 2 december 2018 @ 14:35:
Kotlin heeft ook wel een mooie standaard functie voor dit soort dingen (measureNanoTime) maar daar kan ik geen return value uitkrijgen.

Gewoon zo:

code:

val time = measureNanoTime {
    Thread.sleep(500) //Voorbeeld
}

[ Voor 43% gewijzigd door Hydra op 02-12-2018 15:41 ]

[Ryada]

Creepy schreef op zondag 2 december 2018 @ 13:53:
[...]

Een UI? De commandline is UI genoeg Filename meegeven als parameter, uitlezen en output uitspugen naar de console.

De UWP UI is in principe overbodig. Maar leek mij gewoon een leuk moment om eindelijk eens mezelf over de streep te trekken om het te leren.
Normaal gebruik ik alleen maar WPF, of Winforms (de 2de alleen maar voor werk en heb ik helaas geen andere keuze)

[Lye]

Hydra schreef op zondag 2 december 2018 @ 15:38:
Gewoon zo:

code:

val time = measureNanoTime {
    Thread.sleep(500) //Voorbeeld
}

Ja, die snap ik, maar het gaat mij om values in de lambda die gemeten wordt:

code:

val timeTaken = measureNanoTime {
    val output = ...
}

output is natuurlijk niet buiten de lambda beschikbaar en omdat de compiler niet weet dat de lambda 100% zeker uitgevoerd wordt* kan zoiets ook niet:

code:

var output: Any
val timeTaken = measureNanoTime { 
    output = 1
}

*: Kotlin heeft sinds 1.3 (experimental) contracts waarbij aangegeven kan worden dat een functie zeker wordt uitgevoerd. Hiermee zou het dus mogelijk moeten zijn om bovenstaande alternatief te gebruiken, echter hebben de timing functions deze nog niet geimplementeerd.

[Hydra]

@Lye

code:

fun test() {
    var result: Int = 0

    val measure = measureNanoTime {
        result = 10
        Thread.sleep(100)
    }

    println("$result in $measure ns")
}

[Daanoz]

Hydra schreef op zondag 2 december 2018 @ 11:28:
@Daanoz kun je die van mij terugzetten naar Kotlin / https://github.com/nielsutrecht/adventofcode?

Done!

Heb er jaar tot nu minder tijd voor als vorig jaar, in de ochtend even de pc aanzwengelen, puzzelen en weer door. Optimalisaties komen later wel weer 😅.

[ElkeBxl]

Dag 2 ook net gedaan En heb voor de grap ook eens gekeken naar de tijd die nodig is, 90.3ms voor part1, 13.7ms voor part2. Racket is niet de meest snelle, ik ga me niet echt bezighouden met optimalisaties nu. Eerst focussen op het oplossen van de puzzels

[Camulos]

DRaakje schreef op zondag 2 december 2018 @ 11:35:
Ik vond part 1 lastiger als part2. Ben wel blij met oplossing voor part2, die vond ik wel elegant.

Pastebin code in C#

Maximaal gebruik maken van linq! impressive!

Zelf juist helemaal uit geprogrameerd

totale runtime voor part 1 + 2 = 40ms

[ Voor 4% gewijzigd door Camulos op 02-12-2018 21:24 ]

[farlane]

Hydra schreef op zondag 2 december 2018 @ 11:28:
@Daanoz kun je die van mij terugzetten naar Kotlin / https://github.com/nielsutrecht/adventofcode? Ik laat Rust nu ff 'rusten' (heh), ben te veel met de compiler aan 't vechten op dit moment om er lol van te hebben. Ga 't misschien later een keer converteren maar vind op dit moment het de tijdsinvestering niet waard.

Pfff ben ook in Rust bezig maar man wat zeurt dat ding Ik ga nog even proberen door te zetten ....

[Hydra]

Dag 3 in Kotlin

[DRaakje]

C# Dag 3

Teveel nested loops.

[emnich]

Dag 3:

Problem 1: xxxx
solved in : 3039.031982ms


Problem 2: xxx
solved in : 0.913143ms

Ik gebruik, deel 2 gebruikte de geparsde data van deel 1, dus de tijden zijn niet helemaal eerlijk.

Eens kijken of ik deel 1 nog sneller kan maken

[Ryada]

Ik kan helaas vanavond pas beginnen aan dag 3. Eerst een drukke dag op werk voor de boeg.

[Radiant]

spoiler:

Zo zie je maar dat je goed moet lezen.. Het heeft mij even gekost om te realiseren dat je elke overlap maar 1 keer moet tellen

[ElkeBxl]

Dag 3 done in Racket

Ik zou het zoveel korter kunnen schrijven met betere for loops (zoals ik op het einde van deel 2 door had) maar geen zin in

[Gropah]

DRaakje schreef op maandag 3 december 2018 @ 09:27:
C# Dag 3

Teveel nested loops.

Ja, dat gevoel had ik ook, maar meh, het werkt en het is niet helemaal te voorkomen met een OO taal.

Ik heb hem zelf ook net af. Had wat problemen die ik niet helemaal door had

spoiler:

dat het id van een claim niet hetzelfde is als de positie in een array klassiek foutje

Ik denk dat ik nog tegen wat cachemisses aanloop omdat ik nog nooit met 2d/3d arrays heb gewerkt in golang, maar heb de volgende tijden:

part1: 8.889ms
part2: 9.079ms

Niet geheel ontevreden. Code ga ik later wel opschonen

[Camulos]

Gropah schreef op maandag 3 december 2018 @ 12:28:
[...]
Ja, dat gevoel had ik ook, maar meh, het werkt en het is niet helemaal te voorkomen met een OO taal.

Ik vond het met 3 loops prima te doen.. ik vraag me af of het met minder kan?
- 1 loop om door je input lijst te gaan
- 2 loops om door je grid/2d-plane/tabel te gaan om de vlakken te checken

Zelf dan ook op die manier opgelost Dag 3 in C#

[ZieglerNichols]

Mijn oplossing voor dag 3 in Matlab: https://pastebin.com/TfjvYNkg

Runtime prestaties niet te vergelijken met de meeste talen hier, maar wel lekker snel programmeren en dat is belangrijk voor AOC

[curvemod]

Ik doe dit jaar ook weer mee, dus meldt me maar eens in dit topic Het is voor mij met name een oefening om m'n Kotlin skills wat te verbeteren, aangezien ik normaliter met name met Typescript werk.

Solution dag 3: https://github.com/jhuiti...2018/tree/master/src/day3

[hidde212]

Ook ik doe mee dit jaar, in Python. Heb vanochtend in drie kwartier beide sterren verdiend, met een performance die nog te verbeteren moet zijn:

code:

Runtimes:
Part 1: 237.674 ms
Part 2: 27.026 ms

[veldsla]

ZieglerNichols schreef op maandag 3 december 2018 @ 14:57:
Runtime prestaties niet te vergelijken met de meeste talen hier, maar wel lekker snel programmeren en dat is belangrijk voor AOC

Klopt, daarom gebruik ik ook vaak R (dag 2) of Perl (dag 3) als ik even wat snel wil hebben. Maar dan is de uiteindelijke nette Rust versie toch altijd wel een verassing qua performance: 3a 1.6ms, 3b: 0.34 ms, tegen dik 800ms voor de perl versie.

Jammer dat mensen de leercurve van Rust vaak (te) steil vinden en de compiler zelfs een zeur vinden. Het is waar dat de code verbose is, maar de compiler is altijd behulpzaam en de garanties die je krijgt zorgen er vaak voor dat je minder tijd kwijt bent met debuggen.

[Lye]

Dag 3 in Kotlin, draaien beiden in zo'n 30-40 ms. Lang zitten twijfelen over of ik een map, een array of helemaal een andere manier zou gebruiken om het aan te pakken. Uiteindelijk bleek de optie met een array het snelst te zijn en daarnaast ook nog makkelijk te implementeren.

[Hydra]

veldsla schreef op maandag 3 december 2018 @ 15:15:
Jammer dat mensen de leercurve van Rust vaak (te) steil vinden en de compiler zelfs een zeur vinden. Het is waar dat de code verbose is, maar de compiler is altijd behulpzaam en de garanties die je krijgt zorgen er vaak voor dat je minder tijd kwijt bent met debuggen.

Het is afhankelijk van waar je vandaan komt he. Kotlin is een brilliante taal en de tooling is erg goed. Bij Rust is het zowel de syntax als de tooling die me op dit moment een beetje tegenwerk, en een taal die je tegenwerkt gaat je op een gegeven moment ook tegenstaan.

Natuurlijk is het een deel onervarenheid en ik ben van plan er nog serieus mee aan de gang te gaan. Maar ik ben gewoon nogal verwend met IntelliJ ultimate en Kotlin; als ik het nu in Rust ga doen ben ik 3 keer zo lang bezig.

[Satom]

Even een kleine bookmark post, ondanks dat ik drie dagen achter loop ga ik een poging wagen on het in C# te doen (sinds kort fulltime C# developer)

[Anoniem: 1004565]

veldsla schreef op maandag 3 december 2018 @ 15:15:
[...]


Klopt, daarom gebruik ik ook vaak R (dag 2) of Perl (dag 3) als ik even wat snel wil hebben. Maar dan is de uiteindelijke nette Rust versie toch altijd wel een verassing qua performance: 3a 1.6ms, 3b: 0.34 ms, tegen dik 800ms voor de perl versie.

Jammer dat mensen de leercurve van Rust vaak (te) steil vinden en de compiler zelfs een zeur vinden. Het is waar dat de code verbose is, maar de compiler is altijd behulpzaam en de garanties die je krijgt zorgen er vaak voor dat je minder tijd kwijt bent met debuggen.

oeh, Ik vulde voor deel 2 ook weer gewoon de hele grid met (claim_id, value), en hield een hashset bij van claim ID's die overlapten, en om tot het antwoord te komen checkte ik welk claim_id niet voorkomt in de hashset. Ik denk dat jouw manier iets sneller is hahaha.

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

[ Voor 3% gewijzigd door Anoniem: 1004565 op 03-12-2018 16:22 ]

[MerijnB]

Voor dag 3 deel 1: 1461.85 ms
deel 2: 1831.47 ms

Beide inclusief parseren van de data

[ydderf]

Ondertussen heb ik ook dag 1-1 t/m 2-1 opgelost.
Deel 1 van dag 2 niet goed gelezen, dus daar ff mee aan het stoeien geweest.

En naderhand zag ik genoeg veel slimmere oplossingen, maar daar leren we alleen maar van als beginner/hobbyist ;-).

Voor wie interesse heeft in mijn c# oplossingen: https://github.com/ydderfBackwards/AdventOfCode2018

[Ryada]

ydderf schreef op maandag 3 december 2018 @ 18:47:
Ondertussen heb ik ook dag 1-1 t/m 2-1 opgelost.
Deel 1 van dag 2 niet goed gelezen, dus daar ff mee aan het stoeien geweest.

En naderhand zag ik genoeg veel slimmere oplossingen, maar daar leren we alleen maar van als beginner/hobbyist ;-).

Voor wie interesse heeft in mijn c# oplossingen: https://github.com/ydderfBackwards/AdventOfCode2018

Ik haat het om deze persoon te spelen maar probeer je code style consistent te houden indien mogelijk. Ik zie engels en nederlandse namen door elkaar gebruikt worden en `camelCase`, `PascalCase` door elkaar gebruikt worden.
Ik bedoel het niet om je aan te vallen maar probeer je stijl consistent te houden Dat maakt het niet alleen voor jezelf makkelijker maar ook makkelijker om je code te begrijpen.
Ik zou aanraden alleen maar engelse benamingen te gebruiken persoonlijk
Voor de rest netjes voor een beginner

[diabolofan]

Ik was lui en had wat haast, dus

spoiler:

voor deel 2 maar gewoon nogmaals door mijn 2D array heengelopen en gekeken of alle velden van de betreffende claim nog op 1 stonden.

Alsnog wel snel (31 ms) voor deel 1 en 2 samen.

[MerijnB]

diabolofan schreef op maandag 3 december 2018 @ 20:14:
Ik was lui en had wat haast, dus

spoiler:

voor deel 2 maar gewoon nogmaals door mijn 2D array heengelopen en gekeken of alle velden van de betreffende claim nog op 1 stonden.

Alsnog wel snel (31 ms) voor deel 1 en 2 samen.

Is dat inclusief parseren?

[diabolofan]

MerijnB schreef op maandag 3 december 2018 @ 20:24:
[...]

Is dat inclusief parseren?

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.

[ydderf]

Ryada schreef op maandag 3 december 2018 @ 19:33:
[...]

Ik haat het om deze persoon te spelen maar probeer je code style consistent te houden indien mogelijk. Ik zie engels en nederlandse namen door elkaar gebruikt worden en `camelCase`, `PascalCase` door elkaar gebruikt worden.
Ik bedoel het niet om je aan te vallen maar probeer je stijl consistent te houden Dat maakt het niet alleen voor jezelf makkelijker maar ook makkelijker om je code te begrijpen.
Ik zou aanraden alleen maar engelse benamingen te gebruiken persoonlijk
Voor de rest netjes voor een beginner

Geen probleem.
Als ik terug kijk in mijn code, dan kan ik me zeker vinden in je opmerkingen.
Thanks

[farlane]

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.

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 )