"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Voor deel 2 ben ik voor de brute-force methode gegaan en was verbaasd dat hij al in enkele minuten met een antwoord kwam 
Oplossing in TypeScript: https://github.com/WernerLDev/AOC2023/blob/main/day5/day5.ts
spoiler:
Om geheugenproblemen te voorkomen heb ik enkel 1 variabel bijgehouden genaamd 'lowest'. En dan gewoon met een basic for-loop door de hele range lopen zonder er eerst een lange array van te maken.
Binnen de for-loop checken of de locatie hoger of lager is dan de huidige lower en updaten als de waarde lager is.
Binnen de for-loop checken of de locatie hoger of lager is dan de huidige lower en updaten als de waarde lager is.
Oplossing in TypeScript: https://github.com/WernerLDev/AOC2023/blob/main/day5/day5.ts
Roses are red, violets are blue, unexpected '{' on line 32.
:strip_exif()/u/11775/SoulTaker.gif?f=community)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
part 1 appeltje eitje.. part 2.. ik krijg met R de interval-intersections en differences niet goed voor elkaar.... daar ga ik morgen nog even verder mee stoeien..
Conceptueel heb ik het wel scherp, maar krijg het niet vertaald
Conceptueel heb ik het wel scherp, maar krijg het niet vertaald
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Joh, maar met <1ms is de noodzaak daarvoor een beetje weg
. En ik vraag me serieus af of het sneller is in dit geval.
[ Voor 12% gewijzigd door .oisyn op 05-12-2023 20:54 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/140697/crop6180fb9103afa_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/6907/crop565ea06cc073d_cropped.jpeg?f=community)
Leuk om weer mee te doen aan AoC. Alhoewel ik professioneel developer ben, is het snel oplossen van dit soort puzzels wel even andere koek. Ik kom er wel uit, en t/m vandaag waren de antwoorden die ik in de AoC-site heb ingevoerd ook direct correct, maar het duurt vaak relatief lang voor ik een werkend geheel heb. Waarschijnlijk een kwestie van veel oefenen van dit soort puzzels en minder focussen op patterns/leesbare code
Vandaag begint het wel echt interessant te worden. Deel 1 was na het parsen van de file best eenvoudig om het antwoord te berekenen, maar deel 2 moet ik toch echt even beter m'n best voor doen. Voor deel 2 heb ik in eerste instantie een naieve brute-force oplossing gebouwd, maar die duurt echt vreselijk lang: ruim een kwartier. Aangezien ik hier tijden voorbij zie komen van minder dan een seconde, heb ik ondertussen na zitten denken of ik dit op een andere manier kan oplossen.
Vandaag begint het wel echt interessant te worden. Deel 1 was na het parsen van de file best eenvoudig om het antwoord te berekenen, maar deel 2 moet ik toch echt even beter m'n best voor doen. Voor deel 2 heb ik in eerste instantie een naieve brute-force oplossing gebouwd, maar die duurt echt vreselijk lang: ruim een kwartier. Aangezien ik hier tijden voorbij zie komen van minder dan een seconde, heb ik ondertussen na zitten denken of ik dit op een andere manier kan oplossen.
spoiler:
In plaats van alle seed ranges bij langs te crossen en door meerdere mappers heen te duwen, ben ik van plan om op basis van de boundaries van de huidige ranges en de volgende map ranges te berekenen welke nieuwe ranges ontstaan uit een input range. Dan hoef je maar een aantal waarden met elkaar te vergelijken i.p.v. een paar miljard :x. Ik denk dat dat al een enorme verbetering is. Ik zal later even in jullie spoilers kijken of het nog slimmer kan
:strip_icc():strip_exif()/u/269054/crop6064049cee9ab_cropped.jpg?f=community)
Dat hield je in het verleden niet tegen:
Joh, maar met <1ms is de noodzaak daarvoor een beetje weg
Ik heb het voor de grap nog eens geïmplementeerd in C++ en het lijkt wel iets sneller te zijn op de officiële testdata:
Parsing took 141082 ns part1 Solve1() took 4529 ns/run (100000 runs) part1 Solve2() took 3615 ns/run (100000 runs) 240320250 part2 Solve1() took 8948 ns/run (100000 runs) part2 Solve2() took 5634 ns/run (100000 runs) 28580589
Alleen jammer dat de solve-tijd gedomineerd wordt door de parse-tijd.
:strip_icc():strip_exif()/u/593726/crop5dcaa04cb6842_cropped.jpeg?f=community)
Dag 6
Hier wat interessantere invoeren (voor 31-bit, 63-bit en 127-bit respectievelijk):
Antwoord eindigt op ...123.
Antwoord eindigt op ...366.
Antwoord eindigt op ...377.
En een grote:
Eerste antwoord begint met 233404...
Tweede antwoord eindigt met ...909131
spoiler:
was gewoon te bruteforcen 
Hier wat interessantere invoeren (voor 31-bit, 63-bit en 127-bit respectievelijk):
Time: 6074001000 Distance: 9223372036854775807
Antwoord eindigt op ...123.
Time: 2878053387 Distance: 1661589816380250885
Antwoord eindigt op ...366.
Time: 16107645505445695488 Distance: 64856007359523503909674096462042349751
Antwoord eindigt op ...377.
En een grote:
Time: 942 952 879 579 439 716 41 863 672 758 528 535 560 153 302 21 54 825 153 289 705 973 442 333 168 999 367 234 632 435 51 293 69 544 616 628 540 755 620 444 827 50 155 78 745 712 796 554 840 656 753 450 382 188 741 399 700 250 402 835 930 19 994 1000 809 44 305 231 351 20 704 721 814 426 432 902 116 216 738 337 910 178 163 963 211 842 819 659 637 156 608 405 38 135 52 897 609 344 765 552 Distance: 89127 76021 135371 51132 47001 47639 377 176076 973 113909 30127 10947 65832 5791 16326 2 189 62416 1438 4972 6934 158395 19677 5785 5512 93405 20410 5896 91086 14413 111 2355 793 49942 86437 82740 2350 134755 13471 6812 121661 511 408 914 16242 32058 10848 44489 90655 76682 12890 13931 26028 4992 59719 22206 120495 14144 3100 134076 56529 40 164397 211741 143772 439 3742 308 14890 44 29613 87001 116541 7337 36803 42677 1733 1562 52054 25174 76647 5313 1346 27753 263 21555 106686 5562 8227 1231 42203 1039 317 1575 331 76109 47959 7283 14132 24485
Eerste antwoord begint met 233404...
Tweede antwoord eindigt met ...909131
Zeker, geeft me wat tijd om deel 2 van gisteren nog af te maken :-)
Oplossing voor deel 2 was zelfs heel makkelijk:
spoiler:
Ik heb letterlijk gewoon alle spaties uit de invoer weggehaald en verder precies dezelfde oplossing als deel 1 gebruikt 
. Moest alleen mijn debug statement om de tussenwaardes af te drukken even weghalen, omdat dat langer duurde dan ik geduld had om op te wachten.
. Moest alleen mijn debug statement om de tussenwaardes af te drukken even weghalen, omdat dat langer duurde dan ik geduld had om op te wachten.:
Dag 6spoiler:was gewoon te bruteforcen
Hier wat interessantere invoeren (voor 31-bit, 63-bit en 127-bit respectievelijk):
Time: 6074001000 Distance: 9223372036854775807
Antwoord eindigt op ...123.
Time: 2878053387 Distance: 1661589816380250885
Antwoord eindigt op ...366.
Time: 16107645505445695488 Distance: 64856007359523503909674096462042349751
Antwoord eindigt op ...377.
En een grote:
Time: 942 952 879 579 439 716 41 863 672 758 528 535 560 153 302 21 54 825 153 289 705 973 442 333 168 999 367 234 632 435 51 293 69 544 616 628 540 755 620 444 827 50 155 78 745 712 796 554 840 656 753 450 382 188 741 399 700 250 402 835 930 19 994 1000 809 44 305 231 351 20 704 721 814 426 432 902 116 216 738 337 910 178 163 963 211 842 819 659 637 156 608 405 38 135 52 897 609 344 765 552 Distance: 89127 76021 135371 51132 47001 47639 377 176076 973 113909 30127 10947 65832 5791 16326 2 189 62416 1438 4972 6934 158395 19677 5785 5512 93405 20410 5896 91086 14413 111 2355 793 49942 86437 82740 2350 134755 13471 6812 121661 511 408 914 16242 32058 10848 44489 90655 76682 12890 13931 26028 4992 59719 22206 120495 14144 3100 134076 56529 40 164397 211741 143772 439 3742 308 14890 44 29613 87001 116541 7337 36803 42677 1733 1562 52054 25174 76647 5313 1346 27753 263 21555 106686 5562 8227 1231 42203 1039 317 1575 331 76109 47959 7283 14132 24485
Eerste antwoord begint met 233404...
Tweede antwoord eindigt met ...909131
spoiler:
Nou weet ik niet helemaal hoe je brute forcen interpreteert, maar ik deed gewoon in eerste instantie zoeken naar de eerste waarde in de range 1 <= .. <= time waarvoor a * (time - a) > distance en dan loopt het aantal geldige altijd van a tot time - a, dus dan is het totaal aantal oplossingen time - it * 2 +1. Of 0 als het onmogelijk is.
Beginnen bij distance / time +1 in plaats van bij 1 als startwaarde voor a schaaft er bij mij nog 2ms vanaf, maar het duurde sowieso maar 20ms. Dat is nog traag, maar ik merk wel dat ik nog wel echt wat 'Kotlin fundamentals' moet leren, want filter(filterexpressie).first() vs firstOrNull(filterexpressie) betekent 1s vs 20ms.
DIt is gewoon ook een heel triviaal wiskundig vraagstuk in de vorm min(a) where a + b = time and a*b > distance.
Daar is vast nog een elegantere wiskundige oplossing voor te verzinnen, maar met 18ms voor deel 2 vind ik het verder wel best.
Beginnen bij distance / time +1 in plaats van bij 1 als startwaarde voor a schaaft er bij mij nog 2ms vanaf, maar het duurde sowieso maar 20ms. Dat is nog traag, maar ik merk wel dat ik nog wel echt wat 'Kotlin fundamentals' moet leren, want filter(filterexpressie).first() vs firstOrNull(filterexpressie) betekent 1s vs 20ms.
DIt is gewoon ook een heel triviaal wiskundig vraagstuk in de vorm min(a) where a + b = time and a*b > distance.
Daar is vast nog een elegantere wiskundige oplossing voor te verzinnen, maar met 18ms voor deel 2 vind ik het verder wel best.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/51489/heforshe_logo_detail.jpg?f=community){kind=logo}
:
Oplossing voor deel 2 was zelfs heel makkelijk:
spoiler:Ik heb letterlijk gewoon alle spaties uit de invoer weggehaald en verder precies dezelfde oplossing als deel 1 gebruikt
spoiler:
Dat had ik ook gedaan om de ster te halen. Maar toch, 330 ms vond ik te lang. Daarom maar even een hele simpele optimalisatie doorgevoerd.
Vanaf 0 proberen hoe lang de distance te laag is, en daarna vanaf de top naar beneden hetzelfde, scheelt toch tientallen miljoenen berekeningen
Ik ga het deel 2 na de koffie misschien nog wel even in een eenvoudige formule gieten zonder loopjes
Vanaf 0 proberen hoe lang de distance te laag is, en daarna vanaf de top naar beneden hetzelfde, scheelt toch tientallen miljoenen berekeningen
Ik ga het deel 2 na de koffie misschien nog wel even in een eenvoudige formule gieten zonder loopjes
[ Voor 6% gewijzigd door Dido op 06-12-2023 07:16 ]
:
[...]
spoiler:Dat had ik ook gedaan om de ster te halen. Maar toch, 330 ms vond ik te lang. Daarom maar even een hele simpele optimalisatie doorgevoerd.
Vanaf 0 proberen hoe lang de distance te laag is, en daarna vanaf de top naar beneden hetzelfde, scheelt toch tientallen miljoenen berekeningen
Ik ga het deel 2 na de koffie misschien nog wel even in een eenvoudige formule gieten zonder loopjes
spoiler:
vanaf 0 is zinloos want 0*iets = 0, dus kleiner dan 1 zal de oplossing nooit zijn.
De stap om vanaf de top naar beneden te gaan is ook zinloos, want door vanaf onder te tellen weet je het antwoord al. vanaf onder krijg je a * b en vanaf boven b * a waarbij a het aantal ms is dat je het knopje ingedrukt houdt en b het aantal ms dat je vaart. Als je weet dat a de ondergrens is, dan is de bovengrens simpelweg time - a.
De stap om vanaf de top naar beneden te gaan is ook zinloos, want door vanaf onder te tellen weet je het antwoord al. vanaf onder krijg je a * b en vanaf boven b * a waarbij a het aantal ms is dat je het knopje ingedrukt houdt en b het aantal ms dat je vaart. Als je weet dat a de ondergrens is, dan is de bovengrens simpelweg time - a.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Jammer idd, dat brute force nog werkte voor deel 2
, spoiler:
closed form oplossing is triviale middelbare school wiskunde.
:strip_exif()/u/29138/caffeine.gif?f=community)
Hilarisch dit! In een half uurtje met pen en papier aan de ontbijttafel opgelost.
Met de Android calculator (die gelukkig ook voldoende precisie had voor deel 2) op het handje uitgerekend.
spoiler:
Algemene vergelijking opgesteld voor de distance als functie van t en tmax. Die met de abc-formule omgeschreven naar de 2 vergelijkingen voor t. Laagste t naar boven afronden, hoogste naar beneden, verschil plus 1 geeft het aantal opties.
Met de Android calculator (die gelukkig ook voldoende precisie had voor deel 2) op het handje uitgerekend.
Zo scherp als een voetbal!
spoiler:
Ik zat ook binary search te overwegen, misschien dat ik het daarmee later vandaag nog ga oplossen.
Voor nu zoek ik de lowerbound door met een hold van 1 te beginnen en die op te hogen tot ik een winnende distance krijg, en hetzelfde voor de upperbound, maar dan begin ik met een hold van de racetime - 1.
Daarna is het antwoord (upperbound - lowerbound) + 1
Voor nu runt dat al in een acceptabele tijd, en ik vraag me af of een binary search het echt substantieel zal versnellen met deze kleine search space, de meeste tijd wordt toch gespendeerd aan de file I/O bij mij. Maar het is zeker een goede oefening om weer eens een binary search te implementeren
Voor nu zoek ik de lowerbound door met een hold van 1 te beginnen en die op te hogen tot ik een winnende distance krijg, en hetzelfde voor de upperbound, maar dan begin ik met een hold van de racetime - 1.
Daarna is het antwoord (upperbound - lowerbound) + 1
Voor nu runt dat al in een acceptabele tijd, en ik vraag me af of een binary search het echt substantieel zal versnellen met deze kleine search space, de meeste tijd wordt toch gespendeerd aan de file I/O bij mij. Maar het is zeker een goede oefening om weer eens een binary search te implementeren
Ah ja, dit is de juiste manier inderdaad (jullie hebben feitelijk precies dezelfde formule, wat natuurlijk ook logisch is). Mijn probleem was dat ik
spoiler:
de expressie (t**2 - 4*d)**0.5 direct probeerde af te ronden en dat werkt steeds nét niet.
Overigens heeft deze aanpak weer als nadeel dat het floating point math gebruikt waardoor 'ie niet correct werkt voor grotere invoer. Dan zou je eigenlijk isqrt() moeten gebruiken. Maakt voor de officiële testdata gelukkig niet uit.
Overigens heeft deze aanpak weer als nadeel dat het floating point math gebruikt waardoor 'ie niet correct werkt voor grotere invoer. Dan zou je eigenlijk isqrt() moeten gebruiken. Maakt voor de officiële testdata gelukkig niet uit.
:
spoiler:Voor nu runt dat al in een acceptabele tijd, en ik vraag me af of een binary search het echt substantieel zal versnellen met deze kleine search space, de meeste tijd wordt toch gespendeerd aan de file I/O bij mij. Maar het is zeker een goede oefening om weer eens een binary search te implementeren
spoiler:
I/O valt bij dit probleem toch wel mee?
En als je de limieten van je huidige aanpak wil ervaren kun je de grotere test inputs hier proberen.
En als je de limieten van je huidige aanpak wil ervaren kun je de grotere test inputs hier proberen.
spoiler:
door de verschillende mogelijkheden in te vullen 
. Volgens mij zou het gewoon goed moeten gaan met:
[code]
int(math.floor(bovengrens)) - int(math.ceil(ondergrens)) +1[/code]
(De laatste +1 omdat je een een beide zijde inclusieve range bekijkt), maar op 1 of andere manier werden mijn beide grenzen negatief, waardoor je dus moet omdraaien, en ik had er om kwart over 6 even geen zin meer in om dat te debuggen, ontbijt moest nog worden klaargezet.
. Volgens mij zou het gewoon goed moeten gaan met:[code]
int(math.floor(bovengrens)) - int(math.ceil(ondergrens)) +1[/code]
(De laatste +1 omdat je een een beide zijde inclusieve range bekijkt), maar op 1 of andere manier werden mijn beide grenzen negatief, waardoor je dus moet omdraaien, en ik had er om kwart over 6 even geen zin meer in om dat te debuggen, ontbijt moest nog worden klaargezet.
Verandert z'n sig te weinig.
/u/49730/babby%2520tux.png?f=community)
Makkelijk voor mij als Engineer vandaag.
spoiler:
Je hoeft slechts 1 punt te bepalen, het andere kun je dan makkelijk berekenen. :fill(white):strip_exif()/f/image/WvKsTBsfhDY3fA0nSBNIbTbf.png?f=user_large)
/u/102105/crop56f481fe1f74f.png?f=community)
:strip_icc():strip_exif()/u/39359/OCR2.jpg?f=community)
spoiler:
Zelfs "brute force" kan nog veel sneller.
(0..race.first).map { race.first * it - (it * it) }.count { it > race.second }
vervangen door iets als:
(1..time).firstOrNull { it * (time - it) > distance }?.let { (time - it * 2) + 1 } ?: 0
(0..race.first).map { race.first * it - (it * it) }.count { it > race.second }
vervangen door iets als:
(1..time).firstOrNull { it * (time - it) > distance }?.let { (time - it * 2) + 1 } ?: 0
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:
[...]
spoiler:Zelfs "brute force" kan nog veel sneller.
(0..race.first).map { race.first * it - (it * it) }.count { it > race.second }
vervangen door iets als:
(1..time).firstOrNull { it * (time - it) > distance }?.let { (time - it * 2) + 1 } ?: 0
spoiler:
Dat is toch geen brute force meer? Hierbij zoek je de eerste die matched in de wetenschap dat het symmetrisch is en alles tussen die offset en die offset van het einde dus een oplossing is. Hangt een beetje van je definitie van brute force af, maar goed. Wat mij betreft is brute force domweg elke mogelijkheid proberen, dat is wat mijn stukje code doet
Tja
:
[...]
spoiler:Dat is toch geen brute force meer? Hierbij zoek je de eerste die matched in de wetenschap dat het symmetrisch is en alles tussen die offset en die offset van het einde dus een oplossing is. Hangt een beetje van je definitie van brute force af, maar goed. Wat mij betreft is brute force domweg elke mogelijkheid proberen, dat is wat mijn stukje code doet
spoiler:
Nou ja, er zit inderdaad het handigheidje van de symmetrie in, maar het schaalt natuurlijk nog steeds mee met de grootte van time en distance.
Feitelijk zoek je de minimale waarde voor x * (time -x ) > distance en dat kun je oplossen met de kwadratische formule zoals anderen al aangeven. Dan hoef je slechts een berekening te doen waar je beide waarden ingooit. Met mijn oplossing moet je nog steeds vanaf 1 door het lijstje heen lopen totdat je de eerste a tegenkomt waarvoor a * (time - a) > distance geldt.
Feitelijk zoek je de minimale waarde voor x * (time -x ) > distance en dat kun je oplossen met de kwadratische formule zoals anderen al aangeven. Dan hoef je slechts een berekening te doen waar je beide waarden ingooit. Met mijn oplossing moet je nog steeds vanaf 1 door het lijstje heen lopen totdat je de eerste a tegenkomt waarvoor a * (time - a) > distance geldt.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Oh cool.
De grap is dat ik meer variantie heb tussen verschillende runs dan dat je wint met die optimalisatie
Vorig jaar gebruikte ik een AVX string to int parser die met een paar instructies een int kon parsen. Ben wel benieuwd hoeveel dat zou schelen.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Hij staat al sinds de post te stampen met BigIntegers en heeft nog geen resultaat, ik vermoed dat het niet helemaal lekker schaalt.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:
Hilarisch dit! In een half uurtje met pen en papier aan de ontbijttafel opgelost.
spoiler:Algemene vergelijking opgesteld voor de distance als functie van t en tmax. Die met de abc-formule omgeschreven naar de 2 vergelijkingen voor t. Laagste t naar boven afronden, hoogste naar beneden, verschil plus 1 geeft het aantal opties.
Met de Android calculator (die gelukkig ook voldoende precisie had voor deel 2) op het handje uitgerekend.
:
[...]
spoiler:door de verschillende mogelijkheden in te vullen
[code]
int(math.floor(bovengrens)) - int(math.ceil(ondergrens)) +1[/code]
(De laatste +1 omdat je een een beide zijde inclusieve range bekijkt), maar op 1 of andere manier werden mijn beide grenzen negatief, waardoor je dus moet omdraaien, en ik had er om kwart over 6 even geen zin meer in om dat te debuggen, ontbijt moest nog worden klaargezet.
spoiler:
Die van jullie gaan beide fout wanneer de vergelijking een integer oplevert. Dan zit je precies op het record en die voldoet dus niet.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/117379/KazuAva.gif?f=community)
spoiler:
Erg makkelijk vandaag, inderdaad. Gewoon brute force gedaan, al was het opstellen van een vergelijking een stuk logischer 
https://github.com/Unreal...n/day6-second/src/main.rs
https://github.com/Unreal...n/day6-second/src/main.rs
Ik merk sinds gisteren dat ik eindelijk wat in Rust begin te raken. Minder gestoei, dus dat is fijn
Nu nog even de tijd vinden om naar deel 2 van gisteren kijken. Ik had alleen tijd voor deel 1, en in de wandeling van het station naar huis deel 2 in m'n hoofd opgelost. Nu nog daadwerkelijk implementeren.
PS5 PSN: UnrealKazu
Klopt. Maar die zat bij mij alleen in het voorbeeld, niet in de echte opgave. En met de hand corrigeer je dat makkelijk
. Is wel een leuke edge-case idd.
Zo scherp als een voetbal!
:
[...]
Klopt. Maar die zat bij mij alleen in het voorbeeld, niet in de echte opgave. En met de hand corrigeer je dat makkelijk
spoiler:
Maar dus makkelijk op te lossen door ipv omhoog af te ronden, naar beneden af te ronden en dan +1, en vice versa
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
spoiler:
Ik had het over deel twee. Daar gaat het om "iets" meer mogelijkheden, waarvan je alleen de kleinste en de grootste nodig hebt. Die zijn prima te vinden door vanaf 0 (of vanaf 1, kniesoor die daar op let) te zoeken, resp vanaf de bovenkant naar beneden te gaan. Daarmee skip je tientallen miljoenen berekeningen die nergens voor nodig zijn.
Edit: en nog makkelijker is inzien dat eea symmetrisch is, natuurlijk
Edit: en nog makkelijker is inzien dat eea symmetrisch is, natuurlijk
Maar goed, uiteindelijk loopt ook deel twee in minder dan 1 ms
spoiler:
de minimum en maximumtijd zijn gewoon de oplossingen van een simpele kwadratisch vergelijking, dus kun je in 1 keer berekenen zonder ook maar een enkele loop voor deel twee, en voor deel1, 1 heel klein loopje.
[ Voor 5% gewijzigd door Dido op 06-12-2023 16:24 ]
:strip_exif()/u/26373/anim4.gif?f=community)
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
En dag 5 deel 2 ook af. Ik was gisteren echt te gaar om die off by one error te spotten
spoiler:
for mapI := len(maps) - 1; mapI > 0; mapI-- {
vs
for mapI := len(maps) - 1; mapI >= 0; mapI-- {
vs
for mapI := len(maps) - 1; mapI >= 0; mapI-- {
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
/u/36698/avatar.png?f=community){kind=avatar}
/u/13471/karnemelk.png?f=community)
:strip_icc():strip_exif()/u/633426/crop658152b10d6b4_cropped.jpg?f=community)
Dag 7:
spoiler:
Pff... moest even opzoeken hoe je ook alweer een custom comparator schreef in Python .
Maar goed, met onderbreking door ontbijt voor de kantoorganger toch redelijk snel opgelost
en deel 2 was bijna automatisch, moest alleen mijn Counter vervangen door even snel een dict opbouwen, en dan het aantal jokers optellen bij de meest-voorkomende.
Wel grappige edge case, blijkbaar kan 5 jokers ook. Stelletje jokers die elfjes
.Maar goed, met onderbreking door ontbijt voor de kantoorganger toch redelijk snel opgelost
en deel 2 was bijna automatisch, moest alleen mijn Counter vervangen door even snel een dict opbouwen, en dan het aantal jokers optellen bij de meest-voorkomende.
Wel grappige edge case, blijkbaar kan 5 jokers ook. Stelletje jokers die elfjes
Verandert z'n sig te weinig.
/u/22283/crop5e2c64c410533.png?f=community)
Oh, damn! Ik heb het echt vééééél te ingewikkeld gemaakt vandaag
(Maar toch was ik de eerste op het Tweakers leaderboard, dus misschien is snel maar dom soms toch beter dan slim.)
:strip_icc():strip_exif()/u/87006/crop6391f4393be60_cropped.jpg?f=community)
Veels te lang op deel 2 vast gezeten, totdat ..
De set van @Soultaker doet er bij mij ook circa 5 seconden over in python.
De set van @Soultaker doet er bij mij ook circa 5 seconden over in python.
spoiler:
ik de opdracht nog eens goed las en merkte dat ik 'To balance this, J cards are now the weakest individual cards, weaker even than 2. The other cards stay in the same order: A, K, Q, T, 9, 8, 7, 6, 5, 4, 3, 2, J.' helemaal niet had gezien 
. Daarna in 1x het goede antwoord.
. Daarna in 1x het goede antwoord.[ Voor 19% gewijzigd door bakkerjangert op 07-12-2023 09:22 ]
:strip_icc():strip_exif()/u/266124/crop63d63fdf5b8e2_cropped.jpg?f=community)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Day7: Time spent: 280.6µs
En ook geleerd dat als ik het in de VS Code embedded terminal run, dat er dan ongeveer 70µs bij de tijd bij komt. Dus ik kan dat aftrekken van de tijden die ik tot nu toe gepost heb 
En ook geleerd dat als ik het in de VS Code embedded terminal run, dat er dan ongeveer 70µs bij de tijd bij komt
. Dus ik kan dat aftrekken van de tijden die ik tot nu toe gepost heb
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Day 6 in Python
Even inhalen want was gisteren te druk.
Day 7 in Python
Even inhalen want was gisteren te druk.
spoiler:
Lekker brute force gehouden. Had wel door dat ik alleen maar het punt hoef op te zoeken waarop het boven de goal komt. 650ms voor deel 2 kan ik prima mee leven
Day 7 in Python
spoiler:
Voor dag 7 heb ik de kaarten eerst omgezet naar een 13-based systeem, daarna geteld hoevaak welke letter voorkomt. Gekeken welk profiel daar bij hoort, 3x letter, 1x letter, 1x letter is bijvoorbeeld een three of a kind. Daar een ranking aan gekoppeld zodat de beste hand de hoogste rang krijgt. Deze rang heb ik daarna aan de voorkant van de 13-based vertaling geplakt.
Door dit te doen kan ik nu de resulterende 13-base vertaling converteren naar een 10-based int en hoef ik enkel te sorteren op dat nummer en te vermenigvuldigen met de rang
Door dit te doen kan ik nu de resulterende 13-base vertaling converteren naar een 10-based int en hoef ik enkel te sorteren op dat nummer en te vermenigvuldigen met de rang
Beide delen draaien in ~1 seconde per stuk inc parsen
[ Voor 20% gewijzigd door FrankMennink op 07-12-2023 11:47 ]
Time spent: 63023.0µs
FYI: Die set voldoet niet aan het de facto format (hij eindigt op een newline)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ah ja, dat was nog een overblijfseltje van de opdracht verkeerd lezen. Ik dacht dat alle kaarten van de "joker-waarde" niets waard waren. Heeft me vanochtend wel een paar minuutjes gekost
Thanks, over het hoofd gezien!
Na nog wat refactoren kom ik uiteindelijk op deze code.
[ Voor 30% gewijzigd door Friits op 07-12-2023 12:24 ]
Enig idee hoe dat komt? Iets met output flushen naar de terminal, of wordt dat niet meegeteld in de timing?:
En ook geleerd dat als ik het in de VS Code embedded terminal run, dat er dan ongeveer 70µs bij de tijd bij komt
Volgens mij eindigen alle officiële invoerbestanden ook op een newline? (Zoals het overigens ook hoort!):
FYI: Die set voldoet niet aan het de facto format (hij eindigt op een newline)
Wow, die implementatie van type() is lekker obscuur
Eventueel kun je '23456789ABCDE' nog vervangen door hand.
Ik denk het ja.
Oh lol je hebt gelijk. Ik save die dingen nooit, want Chrome opent ze gewoon in een tab. En dan doe ik CTRL+A en copy/paste ik 'm naar een file. Maar dan neemt ie de laatste newline dus niet mee
.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nog obscuurder, maar ook heel elegant (al zeg ik het zelf)::
Wow, die implementatie van type() is lekker obscuur
spoiler:
def type(hand): return sum(map(hand.count, hand))
Good catch! En ik dacht nog wel dat ik "perfecte" code had geschreven!
[ Voor 4% gewijzigd door Friits op 07-12-2023 13:18 ]
spoiler:
Ik compare ze ook, maar gewoon op basis van (voor part 2) "J23456789TQKA".indexOf(char), scheelt de 23 ifjes in je compare method
En wat betreft het opnieuw loopen is mapIndexed in Kotlin echt een gigantische verbetering t.o.v. Java. Daarmee doe je gewoon de map methode van een java stream, maar ipv van dat je alleen de value tot je beschikking hebt, heb je dan (index, value) tot je beschikking in de map.
En wat betreft het opnieuw loopen is mapIndexed in Kotlin echt een gigantische verbetering t.o.v. Java. Daarmee doe je gewoon de map methode van een java stream, maar ipv van dat je alleen de value tot je beschikking hebt, heb je dan (index, value) tot je beschikking in de map.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
@Soultaker Interessant gegeven, ik heb (offline) een tabel gegenereerd met alle 135 handen en hun rank (×2, met en zonder jokers), zodat ik alleen maar een lookup hoef te doen naar de 'waarde' van een hand. Met jouw dataset is ie 2x zo snel (34ms), met de standaard input 2x zo langzaam
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/243953/crop56f55a7bcf291.png?f=community)
:strip_icc():strip_exif()/u/569624/crop57cdca5e3392e_cropped.jpeg?f=community)
Ik kom er niet uit, er zit ergens een edge case in die niet in de testdata zit waardoor de uitkomst van deel 2 niet klopt. Vanavond maar eens verder bestuderen
https://github.com/ysmild...ter/pkg/2023/day7/day7.go
https://github.com/ysmild...ter/pkg/2023/day7/day7.go
:
Ik kom er niet uit, er zit ergens een edge case in die niet in de testdata zit waardoor de uitkomst van deel 2 niet klopt. Vanavond maar eens verder bestuderen
https://github.com/ysmild...ter/pkg/2023/day7/day7.go
spoiler:
toevallig een kaart met 5 keer een joker?
:
Ik kom er niet uit, er zit ergens een edge case in die niet in de testdata zit waardoor de uitkomst van deel 2 niet klopt. Vanavond maar eens verder bestuderen
https://github.com/ysmild...ter/pkg/2023/day7/day7.go
spoiler:
Ik zat naar dit stukje te kijken:
for _, v := range cards {
if useJokers {
v += jokers
}
switch v {
case 5:
cardStrength = fiveOfAKind
break
case 4:
cardStrength = fourOfAKind
break
case 3:
threeOfAKindFound = true
case 2:
pairs++
}
}
Misschien interpreteer ik het verkeerd, maar gaat dit nu wel goed met pairs?
Als je b.v. J2345 hebt, dan krijg je hier toch 4 pairs in plaats van 1 als ik het goed zie?
for _, v := range cards {
if useJokers {
v += jokers
}
switch v {
case 5:
cardStrength = fiveOfAKind
break
case 4:
cardStrength = fourOfAKind
break
case 3:
threeOfAKindFound = true
case 2:
pairs++
}
}
Misschien interpreteer ik het verkeerd, maar gaat dit nu wel goed met pairs?
Als je b.v. J2345 hebt, dan krijg je hier toch 4 pairs in plaats van 1 als ik het goed zie?
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Hé leuk, nog iemand met Go!:
Ik kom er niet uit, er zit ergens een edge case in die niet in de testdata zit waardoor de uitkomst van deel 2 niet klopt. Vanavond maar eens verder bestuderen
https://github.com/ysmild...ter/pkg/2023/day7/day7.go
spoiler:
Geef jij je jokers niet dubbel uit? Je telt het aantal jokers op bij het aantal kaarten op de score te bepalen. Als ik snel naar je loop kijk (regel 95) denk ik dat bijvoorbeeld bij een hand als "8822J" twee keer de waarde threeOfAKindFound op true zet maar zie ik niet hoe je het pair telt. (v is in beide gevallen 3 geworden)
:strip_icc():strip_exif()/u/5080/veldsla.jpg?f=community)
spoiler:
Hoe maak jij het onderscheid tussen 12233 en 12323?
.edit: oh wacht, ik dacht even dat je een totale waarde voor elke hand gaf, maar dat getal wat je berekent maakt alleen onderscheid van het soort hand
.edit: oh wacht, ik dacht even dat je een totale waarde voor elke hand gaf, maar dat getal wat je berekent maakt alleen onderscheid van het soort hand
[ Voor 13% gewijzigd door .oisyn op 07-12-2023 15:59 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Was wel weer even iets pittiger.
Kan duidelijk nog wel wat korter maar heeft wel weer lang genoeg geduurd
Dag 7 - Kotlin
spoiler:
Ik had eerst even over het hoofd gezien dat de joker niet een extra kaart was maar in plaats van de Jack kwam, dat gaf wat onverwachte resultaten
Kan duidelijk nog wel wat korter maar heeft wel weer lang genoeg geduurd
Dag 7 - Kotlin
Tja