Nu nog een keer op de niet-naïeve manier (dank Cor
):day-14: parsing: 109.937µs
day-14: part1: 17.847µs
day-14: part2: 467.34µs
day-14: finishing: 6.6µs
day-14: total: 602.41µs
):day-14: parsing: 109.937µs
day-14: part1: 17.847µs
day-14: part2: 467.34µs
day-14: finishing: 6.6µs
day-14: total: 602.41µs
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
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/11775/SoulTaker.gif?f=community)
Ah doh, je hebt gelijk, ik had de verkeerde file naar die validators gestuurd. Per regel lijkt ie valid maar de php json decoder vindt em niet valid. Naja, blijft toch php
PHP ondersteunt niet zo'n diepte nesting:
Ah doh, je hebt gelijk, ik had de verkeerde file naar die validators gestuurd. Per regel lijkt ie valid maar de php json decoder vindt em niet valid. Naja, blijft toch php
Python:
1
2
3
4
5
| # gen-json.py import sys n = int(sys.argv[1]) print('['*n + '1' + ']'*n) |
PHP:
1
2
3
4
5
| <?php $stdin = fopen('php://stdin', 'r'); $line = fgets(STDIN); echo count(json_decode($line, false, 999999999, JSON_THROW_ON_ERROR)), PHP_EOL; ?> |
$ python3 gen-json.py 4998 | php parse-json.php 1 $ python3 gen-json.py 4999 | php parse-json.php PHP Fatal error: Uncaught JsonException: Syntax error in parse-json.php:4
Het lijkt er dus op dat de maximale nesting depth 4998 is (of 4999 afhankelijk van hoe je het bekijkt). Interessant genoeg krijg je een ándere error als je zelf een maximum-diepte opgeeft van minder dan 4999 ("Maximum stack depth exceeded").
Wel weer typisch PHP hoor: de documentatie zegt één ding, de implementatie doet compleet wat anders.
edit:
Het is trouwens niet puur de nesting depth. Als ik een string van de vorm [1,[1,[1,....1]]] genereer dan crasht 'ie eerder: exact wanneer de invoer 10,000 bytes groot is. Maar het is ook niet alleen de invoerlengte die het probleem is, want als ik een platte string als [1,1,1,1,...] van meer dan 10,000 bytes genereer dan werkt het wel.
Kortom, het lijkt een combinatie van te diepe nesting en te lange input (en ja, ik heb geverifieerd dat fgets() daadwerkelijk de hele regel inleest en niet b.v. na 10,000 bytes trunceert).
edit:
Gelijk maar ff een bug geraporteerd: https://github.com/php/php-src/issues/10104
[ Voor 21% gewijzigd door Soultaker op 14-12-2022 18:12 ]
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
:strip_exif()/u/481248/crop59396aac2b552.gif?f=community)
: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
:strip_icc():strip_exif()/u/197441/vDorst-icon-60x.jpg?f=community){kind=icon}
Nu niet meer
. Code even wat simpeler opgeschreven en nog wat meer directer op de string werken (ipv een losse functie aanroepen die een struct teruggeeft met de huidige token)===[ input.txt ]========== Time: 46us (load:31us, algo:14us) Part 1: 5760 Part 2: 26670 ===[ aoc_2022_day13_large-1.txt ]========== Time: 21,645us (load:49us, algo:21,594us) Part 1: 22673 Part 2: 80802 ===[ aoc_2022_day13_large-2.txt ]========== Time: 13,188us (load:41us, algo:13,146us) Part 1: 226645370 Part 2: 801677840 ===[ aoc_2022_day13_large-3.txt ]========== Time: 18,043us (load:37us, algo:18,005us) Part 1: 197239 Part 2: 722402
Ben af en toe wel wat teleurgesteld in de code die de compiler genereert.
[ Voor 6% gewijzigd door .oisyn op 15-12-2022 03: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.
/u/22283/crop5e2c64c410533.png?f=community)
Ik had de minnetjes bij de invoer wel gezien maar geen goeie regex geschreven. Het duurde bij deel 2 vrij lang voordat ik daar weer aan dacht. 
Siditamentis astuentis pactum.
/u/36698/avatar.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/237526/crop5e05c1d265781_cropped.jpeg?f=community)
Al was het een bruteforce in 1m19s voor deel 2, wel blij met 9 min tussen part 1 en 2 completion time
Nu tijd om (in ieder geval part 2) te refactoren.
Dag 15 - Python
Nu tijd om (in ieder geval part 2) te refactoren.
Dag 15 - Python
:strip_exif()/u/627282/charmander-kerst.gif?f=community)
Same. Ik heb gewoon de tijd niet om in te halen voor het weekend. Maar vind ik niet erg, liever dat ik op mijn gemak de AoC kan afwerken
Without nipples, boobs are pointless - 365 project - In mijn hoofd is het alle dagen Kerstmis - What type of bees make milk? Boobies! - What type of bees are scary? BoooOOOOOooobeees! - Cactusliefhebster
Nog even inhalen: Dag 14 in Python
Viel redelijk mee, kon de oplossingen vinden voor mn thee begon te werken
Dag 15 in Python
Deel 1 een tijdje op lopen staren waarom het niet werkte, nog even goed naar mn "slimme" parser gekeken, die nam alleen de positieve getallen mee. Deel 2 kwam ik op ongeveer dezelfde oplossing uit als @MrHaas, redelijk brute force. Deel 2 runt in 28s, eigenlijk te lang voor de AoC 15s barrier, maar (nog) geen idee hoe het slimmer kan.
Viel redelijk mee, kon de oplossingen vinden voor mn thee begon te werken
Dag 15 in Python
Deel 1 een tijdje op lopen staren waarom het niet werkte, nog even goed naar mn "slimme" parser gekeken, die nam alleen de positieve getallen mee. Deel 2 kwam ik op ongeveer dezelfde oplossing uit als @MrHaas, redelijk brute force. Deel 2 runt in 28s, eigenlijk te lang voor de AoC 15s barrier, maar (nog) geen idee hoe het slimmer kan.
spoiler:
Bij mij staat de beacon op rij 3.1 miljoen nogwat, als ik de range reverse is ie wel snel genoeg om binnen de 15 seconden te vallen 
[ Voor 11% gewijzigd door FrankMennink op 15-12-2022 12:42 ]
Lijkt er op dat je "geluk" hebt gehad met je input: op mijn laptop doet jouw oplossing er op jouw input 8ms over en op mijn input 200ms
.
Wow inderdaad, groot verschil in input files.:
[...]
Lijkt er op dat je "geluk" hebt gehad met je input: op mijn laptop doet jouw oplossing er op jouw input 8ms over en op mijn input 200ms
Jouw input doet er bij mij 115ms over.
Vreemd dat er zo veel variantie zit op de inputs.
[ Voor 6% gewijzigd door Jern_97 op 15-12-2022 13:00 ]
Gelukt!:
Al was het een bruteforce in 1m19s voor deel 2, wel blij met 9 min tussen part 1 en 2 completion time
Nu tijd om (in ieder geval part 2) te refactoren.
Dag 15 - Python
deel 1 & 2 runnen nu samen in 16 ms:
spoiler:
Voor deel 1 de x ranges op y=2000000 laten overlappen en max x - min x gedaan
Voor deel twee 4 lijnen getekend per scanner (manhattan + 1) en de lijnen naar rechtsonder laten intersecten met de lijnen naar rechtsboven. Voor elk van deze punten gekeken of de manhattan distance tussen dit punt en alle scanner groter is dan de manhattan distance van de scanner naar hun beacon, hier komt 1 punt uit
Voor deel twee 4 lijnen getekend per scanner (manhattan + 1) en de lijnen naar rechtsonder laten intersecten met de lijnen naar rechtsboven. Voor elk van deze punten gekeken of de manhattan distance tussen dit punt en alle scanner groter is dan de manhattan distance van de scanner naar hun beacon, hier komt 1 punt uit
Als je een algoritme maakt dat stopt zodra er een goed antwoord gevonden is, dan kun je natuurlijk gewoon mazzel hebben dat dat antwoord redelijk snel gevonden wordt. Ik gok dat als jij de regels uit jouw input in omgekeerde volgorde zet, je ook een hele andere running time gaat zien, terwijl er hetzeflde antwoord uit komt
Ik zie veel aanmames hier. Maar volgens mij zijn ze allemaal niet 100% waterdicht. Het is wachten op de eerste custom input waarbij de boel de mist in gaat
[ Voor 19% gewijzigd door .oisyn op 15-12-2022 14:20 ]
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.
Met dank aan @Diderikdm (:
Nog even inhalen: Dag 14 in Python
Viel redelijk mee, kon de oplossingen vinden voor mn thee begon te werken
Dag 15 in Python
Deel 1 een tijdje op lopen staren waarom het niet werkte, nog even goed naar mn "slimme" parser gekeken, die nam alleen de positieve getallen mee. Deel 2 kwam ik op ongeveer dezelfde oplossing uit als @MrHaas, redelijk brute force. Deel 2 runt in 28s, eigenlijk te lang voor de AoC 15s barrier, maar (nog) geen idee hoe het slimmer kan.
spoiler:Bij mij staat de beacon op rij 3.1 miljoen nogwat, als ik de range reverse is ie wel snel genoeg om binnen de 15 seconden te vallen
) voor het idee hoe het sneller kan, deel 1 gaat nu in 0.06ms en deel 2 in 1.6ms
Day 14 in Kotlin
Ik liep ook een dag achter, maar het maken van die animatie heeft me voor wat afleiding gezorgd
:fill(white):gifsicle():strip_exif()/f/image/YXJS3Zk643iWisFR0RGIHRvO.gif?f=user_large)
Ik liep ook een dag achter, maar het maken van die animatie heeft me voor wat afleiding gezorgd
:strip_icc():strip_exif()/u/48567/viribox_60x60.jpg?f=community)
/u/409503/Paint%2520skillz.png?f=community)
Na lang prutsen eindelijk (!?) dag 7 opgelost (F#)
spoiler:
Kreeg steeds overflow error van iteraties.
Bleek dat de map namen meerdere keren voorkwamen.
Absolute paden bleken de uitkomst.
Daarna part 2 snel opgelost
Bleek dat de map namen meerdere keren voorkwamen.
Absolute paden bleken de uitkomst.
Daarna part 2 snel opgelost
Ondertussen doe ik lekker mee met de aannames:
Ik zie veel aanmames hier. Maar volgens mij zijn ze allemaal niet 100% waterdicht. Het is wachten op de eerste custom input waarbij de boel de mist in gaat
===[ input.txt ]========== Time: 46us (load:45us, algo1:0us, algo2:1us) Part 1: 4861076 Part 2: 10649103160102
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.
Ondertussen ook wat geoptimaliseerd en kom nu aan 55us met mijn originele input en 150us als ik de lijnen omdraai. MrHaas's input doet er nu 250us over. Nog steeds een groot verschil precies.:
[...]
Als je een algoritme maakt dat stopt zodra er een goed antwoord gevonden is, dan kun je natuurlijk gewoon mazzel hebben dat dat antwoord redelijk snel gevonden wordt. Ik gok dat als jij de regels uit jouw input in omgekeerde volgorde zet, je ook een hele andere running time gaat zien, terwijl er hetzeflde antwoord uit komt
Ik zie veel aanmames hier. Maar volgens mij zijn ze allemaal niet 100% waterdicht. Het is wachten op de eerste custom input waarbij de boel de mist in gaat
Welk van mijn aannames zijn niet waterdicht volgens jou? Ik tracht altijd mijn oplossing zo generiek mogelijk te maken.
@Jern_97 Soultaker noemde er al een: waarbij de plek aan de rand van de bounding box ligt, waardoor hij dus niet aan alle kanten hoeft te worden afgesloten door sensoren. De andere is volgens mij dat je geheel bent omsingeld door hoekpunten van de ruiten. Hangt een beetje van je implementatie af of je deze meepakt of niet.
.edit: zeg maar deze case:
Het gaat hier om punt X. Dat is de enige lege plek waar geen sensor komt, maar hij wordt niet afgesloten door de diagonalen van sensoren, maar door de hoekpunten.
Deze mag dan niet helemaal omdat sommige sensoren precies even ver van meerdere beacons zitten (die op de hoeken), maar daar is wel iets op te verzinnen.
Volgens mij heb ik dat probleem op deze manier al verholpen
.edit: zeg maar deze case:
.S..BBB..S. S.........S ....SSS.... ........... B.S.....S.B B.S..X..S.B B.S.....S.B ........... ....SSS.... S.........S .S..BBB..S.
Het gaat hier om punt X. Dat is de enige lege plek waar geen sensor komt, maar hij wordt niet afgesloten door de diagonalen van sensoren, maar door de hoekpunten.
Deze mag dan niet helemaal omdat sommige sensoren precies even ver van meerdere beacons zitten (die op de hoeken), maar daar is wel iets op te verzinnen.
Volgens mij heb ik dat probleem op deze manier al verholpen
[ Voor 47% gewijzigd door .oisyn op 15-12-2022 18:52 ]
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.
Volgens mij houdt mn oplossing al rekening met deze case::
@Jern_97 Soultaker noemde er al een: waarbij de plek aan de rand van de bounding box ligt, waardoor hij dus niet aan alle kanten hoeft te worden afgesloten door sensoren. De andere is volgens mij dat je geheel bent omsingeld door hoekpunten van de ruiten. Hangt een beetje van je implementatie af of je deze meepakt of niet.
.edit: zeg maar deze case:
.S..BBB..S. S.........S ....SSS.... ........... B.S.....S.B B.S..X..S.B B.S.....S.B ........... ....SSS.... S.........S .S..BBB..S.
Het gaat hier om punt X. Dat is de enige lege plek waar geen sensor komt, maar hij wordt niet afgesloten door de diagonalen van sensoren, maar door de hoekpunten.
Deze mag dan niet helemaal omdat sommige sensoren precies even ver van meerdere beacons zitten (die op de hoeken), maar daar is wel iets op te verzinnen.
Volgens mij heb ik dat probleem op deze manier al verholpen
spoiler::no_upscale():strip_icc():fill(white):strip_exif()/f/image/Dl0lwiNklyf2uYflAld0oJxx.jpg?f=user_large)
^ hij checkt alle kruispunten (inclusief hoeken, zijn ook kruispunten)
^ hij checkt alle kruispunten (inclusief hoeken, zijn ook kruispunten)
Soultaker's opmerking is inderdaad atm niet gecovered. Maar door de 4 lijnen van de boundingbox toe te voegen aan de intersectietests zou dit in principe ook gecovered moeten zijn.:
@Jern_97 Soultaker noemde er al een: waarbij de plek aan de rand van de bounding box ligt, waardoor hij dus niet aan alle kanten hoeft te worden afgesloten door sensoren. De andere is volgens mij dat je geheel bent omsingeld door hoekpunten van de ruiten. Hangt een beetje van je implementatie af of je deze meepakt of niet.
.edit: zeg maar deze case:
.S..BBB..S. S.........S ....SSS.... ........... B.S.....S.B B.S..X..S.B B.S.....S.B ........... ....SSS.... S.........S .S..BBB..S.
Het gaat hier om punt X. Dat is de enige lege plek waar geen sensor komt, maar hij wordt niet afgesloten door de diagonalen van sensoren, maar door de hoekpunten.
Deze mag dan niet helemaal omdat sommige sensoren precies even ver van meerdere beacons zitten (die op de hoeken), maar daar is wel iets op te verzinnen.
Volgens mij heb ik dat probleem op deze manier al verholpen
De 2de case werkt volgens mij wel zonder problemen. Ik zoek namelijk gewoon elk punt dat ten minste 1 keer voorkomt in een intersectie. In het bovenstaand geval zal dit punt volgens mij gewoon meerdere keren terug komen uit de intersectie tests.
EDIT: waarschijnlijk volstaat zelfs om enkel de 4 hoekpunten van de bbox toe te voegen. Aangezien elk ander punt op de rand van de bbox ten minste door 2 sensors moet worden begrensd.
[ Voor 6% gewijzigd door Jern_97 op 15-12-2022 19:30 ]
spoiler:
2881 2549
0:00:00.001004 0:00:00.028992
16210 26113
0:00:00.002999 0:00:00.192484
31306 25875
0:00:00.049029 0:00:38.392391
Edit: deed module 31377
0:00:00.001004 0:00:00.028992
16210 26113
0:00:00.002999 0:00:00.192484
31306 25875
0:00:00.049029 0:00:38.392391
Edit: deed module 31377
spoiler:
Volgens mij kan het nog sneller als je eerst een sortering maakt van parallelle lijnen met 1 ruimte en deze eerst doet
===[ aoc_2022_day15_large-1.txt ]========== Time: 156us (load:49us, algo1:1us, algo2:105us) ===[ aoc_2022_day15_large-2.txt ]========== Time: 583us (load:100us, algo1:4us, algo2:478us) ===[ aoc_2022_day15_large-3.txt ]========== Time: 191,043us (load:1,083us, algo1:49us, algo2:189,911us)
Antwoorden voor large1 kloppen trouwens niet. Moet ik even nakijken.
.edit: ah de inputs eindigen met een newline. Daardoor las ik 1 extra regel aan garbage, wat ook impact had op de performance
===[ aoc_2022_day15_large-1.txt ]========== Time: 64us (load:43us, algo1:1us, algo2:19us) Part 1: ***977 Part 2: ***629 ===[ aoc_2022_day15_large-2.txt ]========== Time: 522us (load:78us, algo1:3us, algo2:440us) Part 1: ***079 Part 2: ***553 ===[ aoc_2022_day15_large-3.txt ]========== Time: 177,697us (load:952us, algo1:44us, algo2:176,700us) Part 1: ***109 Part 2: ***116
Ik denk dat er voor large3 nog wel behoorlijk wat te halen valt. Het schaalt momenteel kwadratisch met het aantal sensoren.
.edit: hmm jammer, ik probeer een BVH te bouwen maar er is zoveel overlap tussen de sensoren dat er nauwelijks iets mee te winnen valt kwa vergelijkingen, en dan voegt het vooral heel veel overhead toe.
.edit2: pff soms doe je gewoon veel te moeilijk.
===[ aoc_2022_day15_large-1.txt ]========== Time: 80us (load:55us, algo1:2us, algo2:22us) Part 1: ***977 Part 2: ***629 ===[ aoc_2022_day15_large-2.txt ]========== Time: 371us (load:99us, algo1:4us, algo2:268us) Part 1: ***079 Part 2: ***553 ===[ aoc_2022_day15_large-3.txt ]========== Time: 53,506us (load:1,009us, algo1:48us, algo2:52,448us) Part 1: ***109 Part 2: ***116
[ Voor 71% gewijzigd door .oisyn op 15-12-2022 22:17 ]
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.
Lastig vandaag. :-D Ik zit in dubio. Zal ik gaan werken.. of zal ik doorpuzzelen.. Of allebei 
Siditamentis astuentis pactum.
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
:strip_icc():strip_exif()/u/140697/crop6180fb9103afa_cropped.jpg?f=community)
spoiler:
Dit lijkt me meer een soort TSP dan een shortest-path probleem. Die laatste kun je wel gebruiken om de kosten in kaart te brengen om te reizen tussen de "interessante" valves.
valves.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.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Poeh pittig dagje vandaag! Zat te huiveren voor deel 2 gezien de tijden maar had gelukkig niet zo heel veel aanpassingen nodig (24 min)
runt in ~1s, kan vast sneller maar niet voor nu
Dag 16 - Python
runt in ~1s, kan vast sneller maar niet voor nu
spoiler:
Dubbele variant van BFS + priority queue gekozen -> Eerst om de onderlinge afstanden van alle valves met een waarde van >0 te vinden en in een dict te stoppen, vervolgens vanaf begin alle combinaties van valves door te lopen (waarvan dubbele combinaties alleen met hogere release worden geëvalueerd). Voor deel twee exact hetzelfde, alleen hou je nu jezelf + olifant bij en per ronde pak je de minimale time van de twee.
Dag 16 - Python
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
14ms voor part1. Ik snap jullie tijden 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.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Zit op 157ms voor part1 en 796ms voor part2:
14ms voor part1. Ik snap jullie tijden niet
Is wel Python he
/u/351643/bananatar_mini2.png?f=community)
Helaas klopt je algoritme niet
Code? Ben benieuwd of je eenzelfde fout hebt gemaakt of dat je het correcte algoritme gewoon weer debiel snel hebt weten te krijgen. (14 ms voor deel 1 klinkt voor jou wel realistisch, dat is “maar” 250 keer sneller dan m'n Python oplossing wat wel realistisch is gezien de resultaten uit het verleden.):
14ms voor part1. Ik snap jullie tijden niet
[ Voor 44% gewijzigd door Soultaker op 16-12-2022 16:10 ]
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.
Hmm.. je hebt gelijk, heb een off by 2 op deel twee op de testinput..:
[...]
Helaas klopt je algoritme niet
[...]
Code? Ben benieuwd of je eenzelfde fout hebt gemaakt of dat je het correcte algoritme gewoon weer debiel snel hebt weten te krijgen. (14 ms voor deel 1 klinkt voor jou wel realistisch, dat is “maar” 250 keer sneller dan m'n Python oplossing wat wel realistisch is gezien de resultaten uit het verleden.)
Even kijken wat dat is
Ook voor deel 1 klopt 'ie niet helemaal. Test maar eens met::
Hmm.. je hebt gelijk, heb een off by 2 op deel twee op de testinput..
Valve AA has flow rate=0; tunnels lead to valves BB, CC Valve BB has flow rate=10; tunnels lead to valves CC, DD Valve CC has flow rate=10; tunnel leads to valve BB Valve DD has flow rate=10; tunnel leads to valve AA
Correcte antwoord (vrij eenvoudig met de hand te verifiëren):
spoiler:
780
Ik zou dus met deel 1 beginnen met debuggen.
/u/243953/crop56f55a7bcf291.png?f=community)
Ik moet zeggen dat ik dezelfde aanname gedaan heb en dat werkt gewoon, maar ja, misschien heeft @Soultaker straks wat input waar toevallig wel een wat verticalere tunnel tussen zit, en ze hebben geen klim gear meegenomen
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ik doe hetzelfde, maar dan in 500ms
spoiler:
de 15x15 matrix (of eigenlijk 16x15) bereken ik met 16x dijkstra in 25ms dus vond het de moeite nog niet om daarvoor Floyd–Warshall te gaan lopen uitpluizen. Maar hij staat nu zeker op mijn todo lijst.
Voor deel 2 ben ik (denk ik) slim aan het permuteren. Voor alles heb ik iets van 16k mogelijkheden maar ik durfde het ook wel aan om daarvan maar 6K te testen
Voor deel 2 ben ik (denk ik) slim aan het permuteren. Voor alles heb ik iets van 16k mogelijkheden maar ik durfde het ook wel aan om daarvan maar 6K te testen
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Alright is aangepast, zou nu wel moeten werken:
Poeh pittig dagje vandaag! Zat te huiveren voor deel 2 gezien de tijden maar had gelukkig niet zo heel veel aanpassingen nodig (24 min)
runt in ~1s, kan vast sneller maar niet voor nu
spoiler:Dubbele variant van BFS + priority queue gekozen -> Eerst om de onderlinge afstanden van alle valves met een waarde van >0 te vinden en in een dict te stoppen, vervolgens vanaf begin alle combinaties van valves door te lopen (waarvan dubbele combinaties alleen met hogere release worden geëvalueerd). Voor deel twee exact hetzelfde, alleen hou je nu jezelf + olifant bij en per ronde pak je de minimale time van de twee.
Dag 16 - Python
draait nu wel een stukje trager in 239ms en 5.24sspoiler:
Uiteindelijke wijziging was ipv op sorted(seen) op sorted(seen) + [current_valve]
[ Voor 6% gewijzigd door Diderikdm op 16-12-2022 17:44 ]
Ook maar even alles gepushed voor vandaag. Weer een uitbreiding op mijn toolset kunnen doen . Nu maar eens even kijken of @.oisyn weer spelfouten gaat vinden
. Nu maar eens even kijken of @.oisyn weer spelfouten gaat vinden
[ Voor 14% gewijzigd door Janoz op 16-12-2022 17:46 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
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_icc():strip_exif()/u/341556/crop5dce11181361b.jpeg?f=community)
Je lijkt te beginnen bij valve XB omdat het de eerste regel in je invoer is, maar je moet beginnen bij valve AA. Vandaar dat je eerste actie (“move to YV”) al niet klopt: er is geen pad van AA naar YV (wel van XB naar YV).
(Btw, kudos voor het printen van behulpzame debug-informatie
)
[ Voor 9% gewijzigd door Soultaker op 16-12-2022 23:09 ]
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.
Nasty, maar eindelijk weer tijden waar ik mee kan doen. Part 1 en 2 voor dag 17 in 143ms
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
je reactie inspireerd me
spoiler:
ipv het hele patroon zoeken vanaf een arbitrair punt, gewoon beginnen met een regel die toch niet meer veranderd, maar waarvan je aan kunt nemen dat het patroon al begonnen is, en dan elke keer als je bij dezelfde move en dezelfde rock bent kijken of de regel met dezelfde offset gelijk is aan degene waarmee je begonnen bent. Dat is een stuk snellere methode om het patroon te vinden dan dat ik nu doe.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Bedankt! Dat werkt een stuk beter
Ik zie nu ook wat de bug is. Hij zit in dit stukje. Wil je:1. Een minimale invoer die demonstreert wat er mis gaat, of
2. Een uitleg van wat er mis gaat, of
3. Een pull request die het probleem fixt?
(Btw ongerelateerde tip: maak de fields in class State final dan is het duidelijker dat het een immutable object is.)