Your structure looks a lot like mine, only I don’t copy in the heat loss from the overall grid - I use it as the “distance” value in Dijkstra. I.e. the length of edge A→B is the heat loss value of B.
As far as I can tell, how I should implement dijkstra is though to track the accumulated length of all edges. So I summarize for total heatloss so far. And the path looks almost right. I tried using only the edges for prioritzing the queue… and the path was wayyy different.
I think I am making some kind of logical mistake with my Dijkstra implementation. I find myself unable to completely use the code I am finding on various websites. I have studied solutions of other people now because I was hoping to find some clue. But since nobody seems to be using java it is a bit difficult.
I am out of time for this right now and disappointed, implementing path finding isn’t that hard.
I’m really enjoying the existence of Rust algorithm libraries like pathfinding
. I mean, I’ve written Dijkstra before (even in PostScript!) so I don’t feel I have anything to prove there.
I got a good clue on Mastodon from someone who either made the same mistake or studied my code.
I will extract an abstract Dijkstra implementation for future reference.
Day 18
Well done Eric, you fooled me.
My thought process:
- this is obviously shoelace formula
- hang on, what about the colours? I’m going to have to rewrite it from scratch for part 2.
- [writes a long and complicated grid-based system with borders and flood fill]
- part 2 doesn’t care about the colours, it’s just Bigger Numbers.
- [writes shoelace formula after all]
- [fixes it for non-zero border width]
- [ports it back to part 1]
Could have done that a whole lot faster if I hadn’t tried to anticipate part 2…
Bah. Day17.2 did me another few … but those were all my very own classic stupid faults. Part 1 I was just in a mental dead-end (“Ein Brett vor dem Kopf”) and mixing up A-star and Dijkstra on top of it.
But Part2 was just one stupidity after another. Getting my if conditions straight for one thing… the second testcase was very helpful though.
Now on to Part 18 which I begun work on this morning and which looks far easier, though I am not looking forward to failing an actual flood fill implemntation (with the pipes I cheated)
edit: end I am in trouble with day 18 already. I manage to reproduce the test loop the digger creates but my production input after visualizing… somehow is not a closed loop… the end dangles somewhere
I did poorly in a coding interview years ago over something like this. they had me writing a binary search tree, I did something wrong with how it rebalanced them (because I couldn’t remember details of how to do it, because that’s why there are books). I pointed out were I to write this for real, I’d be using a library for that, because there was an excellent one available that had lots and lots of testing, was faster, etc. that was greeted about as well as a bull in a candy shop would be.
“Which of these letters isn’t a valid option for gnu ls?”
“If I have to work without man pages this isn’t a job for me.”
Getting asked stuff I have to look up every day… that’s what we have chatGPT and search engines for and manpages and documentation and wikipedia, so we don’t have to have everything in our heads. My cousin is a math and history teach and he allows students to look up everything on the internet in his tests, because it’s the reality. There are ways to check if people have knowledge and epxerience that are not memory tests.
Java Switchstatements are goldfish code: I look up the syntax, write one and 10 seconds later I have forgotten the syntax… again. So what? Ok not true for the cool new one with lambdas, I know that now because it’s cool. but the original sucks, I don’t even know how to trigger IntelliJ to create a barebones one for me–instead I now forget that lambdas are called lambdas… it’s not important what they are called I am really good at using them.
Fell behind on AoC a bit over the weekend. In part because of parenting duties. But mostly because I’ve been working on a note taking application for playing 1862: Railway Mania in the Eastern Counties to help A) keep myself from cheating (or, in general, making mistakes) and B) create better AARs for posterity’s sake as well as being able to look back, analyze previous games, and try to learn how I could have played better.
So far, so great. The merger mechanism, in particular, has caused me quite a bit of grief. I originally envisioned the program using (user-driven) Actions that trigger a number of Events, where the events would do all of the work as well as form the basis for generating the journal/AAR report.
Well, that was a lot of “foundation” code to write to get started, and I was in the middle of a game (to generate sample data) and I needed to validate my available cash… soo… I just hacked together a bunch of code to get the job done. Which works (except for the aforementioned merger logic, and some other less common things that are not currently implemented)
But, anyway, I did Day 16 today.
Day 16
Part 1
Cool enough. Some nice classes and some good OO made this pretty straight-forward
Part 2
I considered doing an analysis of each position on the grid and determining which “starting locations” could activate that spot… but… perimeters are smaller than areas… so… straightforward brute force it is! It worked okay. Runs in about 13 seconds or less.
I just ran along the edges for part 2 for 16. Solved it in very little time.
My biggest issue was mixing up directions on 16 … one of my more common mistakes. So… well…
After finding my mistake for 18.1 I closed the loop of the trench and then I did a very simple outside flooding and that was that. Now I think that is not going to cut it for part 2. And I already saw a spoiler keyword on Mastodon–but that is fine by me. I am going to learn something new.
I’m writing tests for the stuff I have been working on. I invoked the test tool on some of it. It told me it found 204 tests, 255 of them passed, and 5 failed. Um. Okay.
Who wrote the test tool?
Ah no I misunderstood… we have those. We have input generators for tests that run distinct iterations on a single test. Those are very cool. I just forget what they are called. I always have to go copy one I wrote previously. But they allow me to have distinct test cases that fail separately but are a single method in the code.
Those will cause intellij to dynamically adjust its test counting. it’s very weird.
A 2.5% failure rate is not reason to ignore a 125% success rate.
Day 19 part 2 looks like another hard one. I have Ideas.
It’s an internal tool. The extra tests are ones that are defined implicitly, like coverage tests (a single line in a build file can create a coverage test for every source file consumed). There are some other implicit tests that are magiced into existence by running tests, too.
I just find it amusing that it’s not reporting them as tests it’s going to run.
In our tests some of these generators pick test cases from the database at random amounts. IntelliJ can‘t know about these ahead of time. I really like the whole technique though and I can live with IntelliJ scrambling to catch up the counting
Day 18 now solved both parts. I was quite proud of my initial implementation of part 1. I learned something last year and got the actual algorithm right on first try. However part 2…. the internet gave me a clue and I decided to not ignore it and follow up on the math. I now know more math and did not get quite as frustrated as I might have (12.2 is still awaiting a solution).
I will now go take a longer look at 19.
Today was my last day of work but I‘ll have a very busy rest of the week…. I should have started my winter break earlier. Meh. I hope I will still find the time for the puzzles.
Day 19
This was very like day 5, both in the feeling of “quite enjoyable part 1, tedious part 2” and in that I lost enthusiasm for bashing at it and finished the next day. Actually easier part 2 than day 5; yeah, tree walk, but given the basic idea of “store variables as ranges, partition ranges on condition” the rest was basically plumbing.
Yay winnow
which made the parsing a breeze.
parsing 19 was almost as bad as xmas groceries shopping. slept over part 2 and woke Knowing how it worked