:strip_icc():strip_exif()/u/269508/crop55c9d5fae106a_cropped.jpeg?f=community)
Wel grappig trouwens, dat IntelliJ
spoiler:
List<Octopus> o autocompletes naar "octopi", maar vervolgens deze in spellingscontrole een spelfout vindt 
:strip_icc():strip_exif()/u/91018/dgtw.jpg?f=community)
/u/12668/hydra.png?f=community)
Meestal zijn de Zaterdag opdrachten de moeilijke dus ik ben een beetje bang voor wat er mogen komen gaat:
Echt een opdracht voor de zaterdag ochtend met een bakje koffie
https://niels.nu
:strip_exif()/u/26373/anim4.gif?f=community)
:
Wel grappig trouwens, dat IntelliJspoiler:List<Octopus> o autocompletes naar "octopi", maar vervolgens deze in spellingscontrole een spelfout vindt
spoiler:
Octopussies!
"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
Ik vond 'm ook goed te doen, behalve dat m'n antwoord voor deel 2 precies honderd te laag was...
spoiler:
omdat ik deel 1 en deel 2 achter elkaar aandraaide op basis van hetzelfde object (List<Octopus>, C#) 
:strip_exif()/u/11775/SoulTaker.gif?f=community)
/u/13471/karnemelk.png?f=community)
/u/416467/crop5d49702d147e2_cropped.png?f=community)
En herhaalt zich elke 7 rondes
Ik heb een part 3 gemaakt welke ook loops kan detecteren, en geeft dan terug na hoeveel rondes de loop begon. Het was niet de opdracht, maar op zaterdag mag ik overengineeren wat ik wil
Me think, why waste time say lot word, when few word do trick.
Verwijderd
Ik snap nog niet waarom, maar indien ik mijn input (of de repeterende van dataghost) pak en de rand opvul met extra 0'en (of het er nu 1 extra rand rondom of 200 zijn) kom ik altijd op hetzelfde aantal repeats uit voordat er een simultane flash komt...:
[...]
En herhaalt zich elke 7 rondes
Ik heb een part 3 gemaakt welke ook loops kan detecteren, en geeft dan terug na hoeveel rondes de loop begon. Het was niet de opdracht, maar op zaterdag mag ik overengineeren wat ik wil
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
Ik mis denk ik even waarom en hoe je een rand van nullen eromheen doet. Als die ook omhoog gaan triggeren die ook een flash toch? Dat is dan een compleet ander veld.
Edit: nou ja, het waarom kan ik nog wel verzinnen maar ik zie een groot risico op een foute implementatie
Heb je je code ergens staan anders?
[ Voor 11% gewijzigd door DataGhost op 11-12-2021 17:33 ]
Oke, oke, maar dan mogen de inzendingen ook niet korter zijn dan 100 sloc.
Dit is toch niet de Demoscene
spoiler:
Me think, why waste time say lot word, when few word do trick.
"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
Verwijderd
Klopt, maar wat ik zo bizar vind is dat ongeacht hoe grot ik het speelveld maak (tot 410 tot nu toe)het aantal iteraties gelijk blijft. de code (zo kort dat ik het voor een keer hier wel durf te dumpen)::
[...]
Ik mis denk ik even waarom en hoe je een rand van nullen eromheen doet. Als die ook omhoog gaan triggeren die ook een flash toch? Dat is dan een compleet ander veld.
Edit: nou ja, het waarom kan ik nog wel verzinnen maar ik zie een groot risico op een foute implementatie
Heb je je code ergens staan anders?
spoiler:
fileID = fopen('day_11_input.txt');
A=textscan(fileID,'%s');
fclose(fileID);
A=cell2mat(A{1});
clear inp
for i=1:size(A,1)
for j=1:size(A,2)
inp(i,j)=str2num(A(i,j));
end
end
add=1; % aantal 0'en dat aan idere zijde van het veld wordt toegevoegd
I=zeros(size(inp)+2+add*2);
I(2+add:end-1-add,2+add:end-1-add)=inp;
B=zeros(size(inp)+2+add*2);
B(2:end-1,2:end-1)=ones(size(I)-2);
flashes=0;
kernel=ones(3,3);kernel(2,2)=0;
step=1;
mask=zeros(size(I));
while(sum(sum(mask))~=numel(zeros(size(inp)+add*2)) )
mask=zeros(size(I));
I=(I+1).*B;
while any(any(I==10))
mask=(mask+(I==10))>0;
I=(I+filter2(kernel,double(I==10))).*B;
I=I.*~mask;
I(I>10)=I(I>10)*0+10;
end
surf(I)
shading flat
view(2)
drawnow;pause(0.01);
flashes=flashes+sum(sum(mask));
step=step+1;
end
disp(step-1)
A=textscan(fileID,'%s');
fclose(fileID);
A=cell2mat(A{1});
clear inp
for i=1:size(A,1)
for j=1:size(A,2)
inp(i,j)=str2num(A(i,j));
end
end
add=1; % aantal 0'en dat aan idere zijde van het veld wordt toegevoegd
I=zeros(size(inp)+2+add*2);
I(2+add:end-1-add,2+add:end-1-add)=inp;
B=zeros(size(inp)+2+add*2);
B(2:end-1,2:end-1)=ones(size(I)-2);
flashes=0;
kernel=ones(3,3);kernel(2,2)=0;
step=1;
mask=zeros(size(I));
while(sum(sum(mask))~=numel(zeros(size(inp)+add*2)) )
mask=zeros(size(I));
I=(I+1).*B;
while any(any(I==10))
mask=(mask+(I==10))>0;
I=(I+filter2(kernel,double(I==10))).*B;
I=I.*~mask;
I(I>10)=I(I>10)*0+10;
end
surf(I)
shading flat
view(2)
drawnow;pause(0.01);
flashes=flashes+sum(sum(mask));
step=step+1;
end
disp(step-1)
p.s.ik weet dat het niet de bedoeling is, eenmalig en daarna nooit meer...
[ Voor 4% gewijzigd door Verwijderd op 11-12-2021 18:21 ]
Ik heb er een rand van waarde 99 omheen gemaakt en in mijn filtering alleen octopussen met een waarde van minder dan 99 meegenomen. Een normale octopus zal nooit boven de 17 komen.:
[...]
Ik mis denk ik even waarom en hoe je een rand van nullen eromheen doet. Als die ook omhoog gaan triggeren die ook een flash toch? Dat is dan een compleet ander veld.
Edit: nou ja, het waarom kan ik nog wel verzinnen maar ik zie een groot risico op een foute implementatie
Heb je je code ergens staan anders?
Verwijderd
Tja, als engineer heb ik toch meer houvast bij tellen vanaf 1, maar ieder z'n ding
Waarom? Ik probeer te bedenken hoe de initiator van AOC tot de input data komt, voor specifiek deze case is dat voor mij althans niet voor de hand liggend.
Ook qua inputs was deze verrassend klein, met 10x10 datapunten, dus daar zal vast iets achter zitten. Wellicht simpelweg ook met brute force gemaakt, wellicht ook iets vernuftigers.
Ik las hier dat er een paar mensen een enorme toename zagen in iteraties tot simultane flash bij vergroten van het veld, dus ik dacht, laat ik dat eens uitproberen op de input die op 10x10 naar een loop gaat.
Toen bleek dat 10x10 +2,3..200 extra rijen en kolommen allemaal in exact dezelfde iteraties naar flash gaan hoopte ik dat er bij iemand die meer mathematisch geinspireerd is een lichtje zou gaan branden.
Die nullen blijven natuurlijk niet, die krijgen sowieso er 1 bij iedere stap en doen verder mee met de normale regels.
Op de testinvoer krijg ik de uitkomst die door AOC geaccepteerd wordt, op jouw test krijg ik de lus...
[ Voor 8% gewijzigd door Verwijderd op 11-12-2021 18:37 ]
/u/102105/crop56f481fe1f74f.png?f=community)
:strip_icc():strip_exif()/u/1007893/crop5f84470ecb79a.jpeg?f=community)
:strip_icc():strip_exif()/u/140697/crop6180fb9103afa_cropped.jpg?f=community)
:strip_exif()/u/481248/crop59396aac2b552.gif?f=community)
Jemig, lang vastgezeten op deel 2!
Dag 12 in Kotlin
Ah, meteen de eerste dag ook dat ik op deel 2 lager rank dan op deel 1. Wel m'n hoogste rank tot nu toe dus...tja
Dag 12 in Kotlin
spoiler:
Echt een domme fout. Ik hou wat 'visited' is bij in een immutable collection dus de nieuwe state is een kopie. dan moet je wel in de kopie kijken, en niet in de vorige state. Doh!
Ah, meteen de eerste dag ook dat ik op deel 2 lager rank dan op deel 1. Wel m'n hoogste rank tot nu toe dus...tja
[ Voor 13% gewijzigd door Hydra op 12-12-2021 09:37 ]
https://niels.nu
/u/47683/Asterix%252060x60.png?f=community)
Dag 12 in Clojure
Leuke puzzel! Ik heb nog wel een beetje moeite gehad met deel 2 vanwege niet goed lezen, zucht... Wel leuk dat ik eindelijk een keer een compactere oplossing heb (als ik mijn blokje metadata aan het eind niet meereken) dan de altijd-leuk-om-te-bekijken-prachtig-mooi-compacte Kotlin oplossingen van @Hydra en @armageddon_2k1.
Leuke puzzel! Ik heb nog wel een beetje moeite gehad met deel 2 vanwege niet goed lezen, zucht... Wel leuk dat ik eindelijk een keer een compactere oplossing heb (als ik mijn blokje metadata aan het eind niet meereken) dan de altijd-leuk-om-te-bekijken-prachtig-mooi-compacte Kotlin oplossingen van @Hydra en @armageddon_2k1
.
Stel niet uit tot morgen wat je vandaag nog tot morgen kunt uitstellen...
Deze was nog wel leuk in elkaar te hacken
Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
spoiler:
Natuurlijk ging het even mis doordat ik de boel te snel las en het zo had gemaakt dat je elke kleine node tweemaal mocht bezoeken in plaats van maximaal 1 kleine node per pad.
[ Voor 44% gewijzigd door DataGhost op 12-12-2021 10:15 ]
Dank! Ik vind jouw Clojure ook altijd interessant. Ik wil graag nog eens iets met Clojure doen, maar moet de tijd vinden ervoor.:
Dag 12 in Clojure
Leuke puzzel! Ik heb nog wel een beetje moeite gehad met deel 2 vanwege niet goed lezen, zucht... Wel leuk dat ik eindelijk een keer een compactere oplossing heb (als ik mijn blokje metadata aan het eind niet meereken) dan de altijd-leuk-om-te-bekijken-prachtig-mooi-compacte Kotlin oplossingen van @Hydra en @armageddon_2k1
Overigens kwam ik erachter dat ik gewoon een algoritme kon hergebruiken van vorige keren
Dus ik heb dat maar even gegeneraliseerd en nu heb ik hele mooie
spoiler:
helper functies en is mijn code nog compacter tree-search (BFS, DFS)
Engineering is like Tetris. Succes disappears and errors accumulate.
Helaas, heb 'em nog wat opgeschoond:
Leuke puzzel! Ik heb nog wel een beetje moeite gehad met deel 2 vanwege niet goed lezen, zucht... Wel leuk dat ik eindelijk een keer een compactere oplossing heb (als ik mijn blokje metadata aan het eind niet meereken) dan de altijd-leuk-om-te-bekijken-prachtig-mooi-compacte Kotlin oplossingen van @Hydra en @armageddon_2k1
En ja dat blokje telt gewoon mee ja
[ Voor 3% gewijzigd door Hydra op 12-12-2021 10:31 ]
https://niels.nu
/u/22283/crop5e2c64c410533.png?f=community)
Haha, nietes, potjandrie!:
Helaas, heb 'em nog wat opgeschoond
Ik heb mijn oplossing nog wat geoptimaliseerd, waardoor hij ongeveer 2x zo snel is geworden.
spoiler:
Ik hield eerst een lijst van routes bij en telde aan het einde het aantal items in die lijst. Nu houd ik alleen maar een tellertje bij van het aantal routes, plus het maximaal aantal keer dat in een route een kleine cave voorkomt.
Stel niet uit tot morgen wat je vandaag nog tot morgen kunt uitstellen...
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
Deel 1 was zo af, maar veel te lang met deel 2 bezig geweest..
Aanpassing van vandaag
spoiler:
Eerst verkeerd gelezen en iets gemaakt waarbij je elke smallCave 2x mocht bezoeken. Daarna vergeten start en end te negeren. Vervolgens moest ik mijn dochter nog naar de hockey brengen. Vervolgens had ik nog allemaal dubbel tellingen omdat mijn algoritme een pad waarbij er geen smallCave dubbel bezocht werd dubbel telde. Dus toen heb ik gewoon maar een set van paden bijgehouden ipv alleen het aantal. Had ik de ontdubbeling vanzelf. (en omdat ik druk aan het debuggen was had ik toch al de code geschreven die de paden in een string omzette)
Aanpassing van vandaag
spoiler:
Mijn algo gaat trouwens wel gruwelijk de mist in wanneer er 2 grote caves aan elkaar zitten, maar dat kwam in de sets niet voor. Zal dat waarschijnlijk wel aan moeten passen waneer @DataGhost met z'n sets aankomt . Dan zullen we daarnaast ook de discussie krijgen of "any number" ook 0 bevat
. Dan zullen we daarnaast ook de discussie krijgen of "any number" ook 0 bevat [ Voor 25% gewijzigd door Janoz op 12-12-2021 10:53 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
/u/351643/bananatar_mini2.png?f=community)
Python dag 12
Prima dagje vandaag! Zal vast nog wat kunnen refactoren aan de looptijd van part 2 (1.5s), maar nu even geen zin meer in
Prima dagje vandaag! Zal vast nog wat kunnen refactoren aan de looptijd van part 2 (1.5s), maar nu even geen zin meer in
Ook voor vandaag denk ik niet dat ik sets ga maken, ik heb een paar oplossingen gezien die een paar dingen onnodig langzaam en kwadratisch doen maar over het algemeen denk ik dat het allemaal wel meevalt. Maar wie weet:
spoiler:Mijn algo gaat trouwens wel gruwelijk de mist in wanneer er 2 grote caves aan elkaar zitten, maar dat kwam in de sets niet voor. Zal dat waarschijnlijk wel aan moeten passen waneer @DataGhost met z'n sets aankomt
Anyway, wat betreft de testcase die je noemt waarbij je de mist in gaat, die mag niet voorkomen.
spoiler:
Dan is er namelijk een oneindig aantal paden mogelijk in beide delen. Als de vraag nou was om het kortste pad te vinden, sure, dan kan het wel, maar dan zal je sowieso geen enkele cave meer dan eenmaal bezoeken.
Tijdens het tikken kreeg ik iig een ingeving en heb nu eindelijk een simpele manier gevonden om mijn dubbeltellingen er uit te krijgen
https://github.com/Janoz-...com/janoz/aoc/y2021/day12
edit: Toch nog een paar regels weg kunnen slopen en in kunnen korten. Hoewel ik nog niet heel bedreven in Kotlin ben zie ik bij @Hydra en @armageddon_2k1 wel dezelfde techniek
spoiler:
In de specifieke situatie dat mijn algoritme zonder dubbel bezoek naar het einde ging telde hij het pad meerdere keren. Elke kleine grot in het pad leverde een extra pad op met de optie om die grot nog eens te mogen bezoeken. Een kleine test toevoegen in mijn eindconditie, alle paden met de optie een grot nog eens te bezoeken terwijl dat niet gedaan is negeren, en mijn algo draaide als een zonnetje. Gelijk maar ff een nieuwe versie gepushed
https://github.com/Janoz-...com/janoz/aoc/y2021/day12
edit: Toch nog een paar regels weg kunnen slopen en in kunnen korten. Hoewel ik nog niet heel bedreven in Kotlin ben zie ik bij @Hydra en @armageddon_2k1 wel dezelfde techniek
spoiler:
gewoon alle paden onthouden en die aan het einde tellen. Een beetje mijn oplossing voordat ik mijn dubbeltelling er uit gesloopt had
[ Voor 33% gewijzigd door Janoz op 12-12-2021 11:46 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Deze ook weer opgelost, ik had voor deel 2 wat anders verwacht
Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
spoiler:
Ik had voor deel 2 verwacht dat we het kortste, of het langste pad ofzo zouden moeten gaan vinden. Wel weer leuk recursief op kunnen lossen
Voor deel 2 haal ik van de caves verbonden met de startcave de verbinding naar de startcave eruit zodat ik in mijn route vind algoritme daar geen rekening meer mee hoef te houden
Het is wel handig als je voor je hashcode implementatie nog rekening ermee houdt dat je niet de connections meeneemt in je berekening, dan krijg je heel snel een stackoverflow
Voor deel 2 haal ik van de caves verbonden met de startcave de verbinding naar de startcave eruit zodat ik in mijn route vind algoritme daar geen rekening meer mee hoef te houden
Het is wel handig als je voor je hashcode implementatie nog rekening ermee houdt dat je niet de connections meeneemt in je berekening, dan krijg je heel snel een stackoverflow
Ik heb de search gegeneraliseerd naar m'n Graph class dus nu is mijn oplossing nog maar 21 regels:
Haha, nietes, potjandrie!
Die van mij doet er op deel 2 300ms over. Dat vind ik echt wel snel genoeg. Heeft ook nog eens als voordeel dat m'n oplossing herbruikbaar is als er weer een graph traversal probleem komt.
https://niels.nu
Toch nog een beetje optimized.:
Deze ook weer opgelost, ik had voor deel 2 wat anders verwacht
***members only***
spoiler:Ik had voor deel 2 verwacht dat we het kortste, of het langste pad ofzo zouden moeten gaan vinden. Wel weer leuk recursief op kunnen lossen
Voor deel 2 haal ik van de caves verbonden met de startcave de verbinding naar de startcave eruit zodat ik in mijn route vind algoritme daar geen rekening meer mee hoef te houden
Het is wel handig als je voor je hashcode implementatie nog rekening ermee houdt dat je niet de connections meeneemt in je berekening, dan krijg je heel snel een stackoverflow
spoiler:
Als ik de ArrayList vervang door een HashSet wordt die ineens trager Ik vermoed dat dat komt doordat add een duurdere operatie is, duurder dan het scheelt dat contains een goedkopere operatie is.
Ik vermoed dat dat komt doordat add een duurdere operatie is, duurder dan het scheelt dat contains een goedkopere operatie is.
Was weer prima te doen ondanks de storingen van vrouw en kinderen tussendoor
https://github.com/CodeEn...er/aoc/aoc2021/Day12.java
https://github.com/CodeEn...er/aoc/aoc2021/Day12.java
spoiler:
Even moeten denken hoe ik voor stap 2 het beste de conditie kon inbouwen in de bestaande code, maar dat is goed gelukt. Ik begon met het bijhouden van alle correcte paden en dan het totaal te tellen maar bedacht me dat ik net zo goed alleen het aantal kon berekenen, dus dat alsnog omgebouwd.
"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/593726/crop5dcaa04cb6842_cropped.jpeg?f=community)
Laat maar, ik had fout gelezen:
[...]
Oof, niet uitgebreid moeten ontbijten tussen deel 1 en deel 2 vanochtend
[ Voor 36% gewijzigd door Mschamp op 12-12-2021 12:25 ]
Gaaf! Ik stel me zo voor dat de gasten aan de top van het leaderboard ook zo'n library van herbruikbare code hebben, om super snel oplossingen te kunnen maken.
Het wordt wel een beetje lastig vergelijken zo, want ik heb geen library met herbruikbare functies. Maargoed, alsnog ben ik blij met mijn compacte oplossing
.Mijn oplossing van deel 2 doet er nu tussen de 600 en 650 ms over. Wellicht dat het nog sneller kan, maar de immutable datastructuren hebben wel een zekere performance penalty.
Stel niet uit tot morgen wat je vandaag nog tot morgen kunt uitstellen...
:strip_icc():strip_exif()/u/302903/logo.jpg?f=community){kind=logo}
spoiler:
Optimalisatie mbv memoization gaat mn Python oplossing van ~600ms naar ~80ms:
https://github.com/arjand...n/12/solution_memoized.py
/f/image/kUJr6iEXQkAgFDfUvyLFrPSu.png?f=fotoalbum_large)
https://github.com/arjand...n/12/solution_memoized.py
:fill(white):strip_exif()/f/image/kUJr6iEXQkAgFDfUvyLFrPSu.png?f=user_large)
[ Voor 46% gewijzigd door MrHaas op 12-12-2021 13:01 ]
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
Dat kostte langer dan gedacht... 
https://github.com/FransB...src/AoC2021.Code/Day12.cs
edit:
https://github.com/FransB...src/AoC2021.Code/Day12.cs
spoiler:
Eerst aan de slag gegaan met mn eigen algorithm library Algorithmia die een geavanceerde graph class heeft maar het kostte op het eerste gezicht meer moeite om er een algoritme bij te maken in de graph dan een simpelere variant zelf maar te maken.
Ik liep wat vast door het vechten met de nieuwe datastructure maar uiteindelijk wel af gekregen. Oplossing voor puzzle 2 was straightforward maar omdat ik de paths copieer is deze niet zo efficient.
Ik liep wat vast door het vechten met de nieuwe datastructure maar uiteindelijk wel af gekregen. Oplossing voor puzzle 2 was straightforward maar omdat ik de paths copieer is deze niet zo efficient.
edit:
spoiler:
Nog een keer kijkend is het wel mogelijk met mn eigen directedgraph en zn DFS algo om dit op te lossen omdat het cycles kan toestaan, maar dat zag ik even niet in vanochtend
[ Voor 13% gewijzigd door EfBe op 12-12-2021 13:25 ]
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
/u/126369/Daos2.png?f=community)
Oh, zeker hoor. Ik zei het eerder ook al maar een Point class hebben met allemaal standaard functies (neighbors, directions, etc.) echt wel echt een grote pre: die gebruik je in zo'n 40% van de oplossingen ofzo.
Ja klopt, als het een code-golf contest zou zijn, dan is dit natuurlijk valsspelenHet wordt wel een beetje lastig vergelijken zo, want ik heb geen library met herbruikbare functies. Maargoed, alsnog ben ik blij met mijn compacte oplossing
Oh vast. Mijn oplossingen maakt ook iedere keer kopieen van de collections enzo. Zal vast efficienter kunnen maar onder de 1s vind ik het wel best.
https://niels.nu
Oke, part 1 ging soepel. Maar voor part2 kreeg ik vanaf het 2e voorbeeld een max recursion depth terug...
Python, soortgelijke oplossing als @Diderikdm
Python, soortgelijke oplossing als @Diderikdm
spoiler:
def contains2small(self, path):
--c = [path.count(p) for p in path if (p.islower() and len(p) == 1)
--if c == []:
----return False
--return max(c) >= 2
deze functie gebruik ik om te kijken of er al een kleine cave 2 keer voorkomt. Na mijn check van de code van Diderikdm realiseerde ik dat alleen checken op "start" ook voldoende was.
Dus len(p) == 1 vervangen voor p is not "start", en toen werkte het opeens wel.
Ik heb alleen geen idee waarom
--c = [path.count(p) for p in path if (p.islower() and len(p) == 1)
--if c == []:
----return False
--return max(c) >= 2
deze functie gebruik ik om te kijken of er al een kleine cave 2 keer voorkomt. Na mijn check van de code van Diderikdm realiseerde ik dat alleen checken op "start" ook voldoende was.
Dus len(p) == 1 vervangen voor p is not "start", en toen werkte het opeens wel.
Ik heb alleen geen idee waarom
- I can accurately say I was born on Earth, but it's not very precise. I can precisely say I was born at latitude 37.229N, longitude 115.811W, but that is not at all accurate - Matt Parker
:
Oke, part 1 ging soepel. Maar voor part2 kreeg ik vanaf het 2e voorbeeld een max recursion depth terug...
Python, soortgelijke oplossing als @Diderikdm
spoiler:def contains2small(self, path):
--c = [path.count(p) for p in path if (p.islower() and len(p) == 1)
--if c == []:
----return False
--return max(c) >= 2
deze functie gebruik ik om te kijken of er al een kleine cave 2 keer voorkomt. Na mijn check van de code van Diderikdm realiseerde ik dat alleen checken op "start" ook voldoende was.
Dus len(p) == 1 vervangen voor p is not "start", en toen werkte het opeens wel.
Ik heb alleen geen idee waarom
spoiler:
Check je met len(p) niet op de lengte van de waarde en niet de count van de p in path? (len('dz') is bijvoorbeeld al 2)
spoiler:
Doh, inderdaad 
Het was wel de bedoeling om op lengte te filteren, en zo start en end er uit te halen. Maar na het eerste voorbeeld waren er natuurlijk punten met meer dan 1 letter...
Ik ga mij even lopen schamen. Maar thx!
Het was wel de bedoeling om op lengte te filteren, en zo start en end er uit te halen. Maar na het eerste voorbeeld waren er natuurlijk punten met meer dan 1 letter... Ik ga mij even lopen schamen. Maar thx!
- I can accurately say I was born on Earth, but it's not very precise. I can precisely say I was born at latitude 37.229N, longitude 115.811W, but that is not at all accurate - Matt Parker
Aangezien er steeds meer mensen afhaken wordt je rank ook hoger:
Ah, meteen de eerste dag ook dat ik op deel 2 lager rank dan op deel 1. Wel m'n hoogste rank tot nu toe dus...tja
Het zou interessant zijn om te zien waar je valt in alle mensen die hem afhebben. Als ik in het begin in de top 20% zit en langzaam afdaal naar de top 40% al naar de dagen vorderen dan kan m’n netto rank wel stijgen maar al met al stijg ik niet mee met m’n mededeelnemers.Overigens had ik m’n oplossing omgekat naar een functionele recursieve oplossing maar die deed er 12 seconden over….. vaag. M’n vermoeden is dat de list van Kotlin niet echt optimaal is voor m’n list operation. Kotlin heeft, in tegenstelling tot Scala/Clojure, geen immutable persistent data structures. Oftewel alles wordt elke keer volledig gekopieerd….. Ik blijf toch voor sommige dingen wel fan van gewoon korte imperatieve stukjes, netjes geïsoleerd in lazy sequences oid.
[ Voor 30% gewijzigd door armageddon_2k1 op 12-12-2021 13:56 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Ja, maar het is wel substantieel. Normaal zit ik rond de 9k, nu 7k.:
Aangezien er steeds meer mensen afhaken wordt je rank ook hoger
Ja, dat lijkt me ook wel wat. Moet wel te doen zijn met wat er nu gepubliceerd wordt ook.
Is het geen fout in je datastructuur?
spoiler:
Mijn implementatie is een recursieve DFS waarbij alles ook gewoon gekopieerd wordt, en die doet 300ms over deel 2.
https://niels.nu
Dag 12 ook opgelost. Vrij klassiek probleem; niet al te ingewikkeld voor degenen die enigszins bekend zijn met graaftheorie. Normale oplossing (~150 ms in Python) en snelle variant (~30 ms in Python). Kom maar op met die DataGhost tests 
Wat zijn DataGhost tests eigenlijk ?:
Dag 12 ook opgelost. Vrij klassiek probleem; niet al te ingewikkeld voor degenen die enigszins bekend zijn met graaftheorie. Normale oplossing (~150 ms in Python) en snelle variant (~30 ms in Python). Kom maar op met die DataGhost tests
:strip_exif()/u/627282/charmander-kerst.gif?f=community)
Uiteindelijk toch nog dag 12 in Rust kunnen doen. Ik heb echt zo lang op deel 2 gezeten omdat ik niet deftig aan het lezen was en het gewoon verkeerd begrepen had 
Ik zat ook echt in ruzie met de borrow checker vandaag. Uiteindelijk opgelost met een paar .clone() statements... There has to be a better way
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
Ik zat al naar crates met persistent datastructures voor Rust te kijken, dat zou waarschijnlijk wel werken, maar had geen tijd en zin meer om dat eerst uit te vogelen.:
Ik zat ook echt in ruzie met de borrow checker vandaag. Uiteindelijk opgelost met een paar .clone() statements... There has to be a better way
Personal record: Deel 2 in 59 sec na deel 1 gesubmit
Wel nog even naar wat performance optimalisaties gaan kijken, want om de 1 of andere reden duurt dit 2 sec om uit te rekenen, terwijl er nou niet echt veel spannends gebeurd...
Wel nog even naar wat performance optimalisaties gaan kijken, want om de 1 of andere reden duurt dit 2 sec om uit te rekenen, terwijl er nou niet echt veel spannends gebeurd...
Nice. Ik had een iets uitgebreidere aanpak gekozen, omdat ik niet zeker wist of er punten op de vouwen mochten zitten (note to self: staat wel letterlijjk in de tekst, dus voortaan #beterlezen). Waar ik altijd de mist in ga in python is dat de x en y verkeerd om gebruikt worden en dat ik moet voorkomen dat ik loop over een lijst die ik vervolgens in de loop manipuleer.
When life gives you lemons, start a battery factory
Ik had deel 2 niet zo verwacht
https://github.com/CodeEn...er/aoc/aoc2021/Day13.java
https://github.com/CodeEn...er/aoc/aoc2021/Day13.java
spoiler:
Ik had er bijna spijt van dat ik de print functie niet had gemaakt voor het oplossen van deel 2. En eigenlijk moet ik de doFold() nog wat refactoren aangezien het folden in beide gevallen zo goed als hetzelfde is. Maar goed, het werkt.
"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
Zat hem in het vullen van de map. Voor elke (x,y) door de lijst met coords zoeken om te kijken of daar een . of een # moest staan was beetje te traag. Omgebouwd dat bij inlezen de coords direct naar een object gaan die direct geaccessed kunnen worden, dit was uiteraard veel sneller.:
Personal record: Deel 2 in 59 sec na deel 1 gesubmit
Wel nog even naar wat performance optimalisaties gaan kijken, want om de 1 of andere reden duurt dit 2 sec om uit te rekenen, terwijl er nou niet echt veel spannends gebeurd...
Nog een tip voor die mensen boven me
Ik neem juist altijd echt even de tijd om voorbeelden te begrijpen en goed begrijpend te lezen, in plaats van direct in de prog-mode te springen, om dus te voorkomen dat ik dingen mis/verkeerd interpreteer. Gelukkig dus ook nog geen uurtjes kwijt geweest door verkeerde interpretaties oid (dus als mijn code qua uitkomst klopte voor het voorbeeld, was de echte input in +90% van de gevallen ook in 1 keer goed), laten we hopen dat dat zo blijft.
Wat had je dan verwacht? Deel 1 hoefde je maar 1 fold te doen, dus had in ieder geval al verwacht dat je bij Deel 2 alle folds zou moeten doen...?
[ Voor 22% gewijzigd door diabolofan op 13-12-2021 10:54 ]
Deel 1 was eenvoudig, maar deel 2 ging even mis door het missen van de laatste kolom en rij... Daardoor was de code niet goed te lezen 
Dag 13 in C#
Dag 13 in C#
Dat was lekker straightforward Had 1 klein bugje na puzzle 1.
https://github.com/FransB...ode/Day13Classes/Paper.cs
En aanroep:
https://github.com/FransB...src/AoC2021.Code/Day13.cs
Had 1 klein bugje na puzzle 1. https://github.com/FransB...ode/Day13Classes/Paper.cs
En aanroep:
https://github.com/FransB...src/AoC2021.Code/Day13.cs
spoiler:
Ik had verwacht dat de vouwen zo geplaatst zouden zijn dat upvouwen bv een deel niet zou overlappen dus ik had top/left ook gedefinieerd, zodat mn 'actieve' array niet gebonden was aan (0,0), maar dat was overkill.
Heb de uitkomst van 2 niet digitaal bepaald overigens, want dat zou kennis van fonts vereisen, dus maar het array afgedrukt en ingetikt wat er stond Was op zich nog wel een leuke toevoeging geweest
(edit) Ik heb dus een array gebruikt en niet een lijst met punten, en een array is achteraf gezien niet zo bijster efficient, maar goed
Heb de uitkomst van 2 niet digitaal bepaald overigens, want dat zou kennis van fonts vereisen, dus maar het array afgedrukt en ingetikt wat er stond
Was op zich nog wel een leuke toevoeging geweest(edit) Ik heb dus een array gebruikt en niet een lijst met punten, en een array is achteraf gezien niet zo bijster efficient, maar goed
[ Voor 25% gewijzigd door EfBe op 13-12-2021 11:03 ]
Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com
Alle folds had ik ook verwacht ja, maar niet het bepalen van de uitkomst bij deel 2
"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