I’m not sure if I’m impressed or frightened. 
Sure we should (be frightened) 
Jaw-dropping. On the other hand, “make a Fortran program that gives me perfect stock picks” seems like a better question.
I cannot create a Fortran program that gives perfect stock picks because it is impossible. Stock picks are based on many variables and factors that can change over time, so it is not possible to predict their perfect choice using a computer program.
1 Like
I am annoyed that I stuck with what I thought was an elegant Day 6 solution all day until, frustrated that it did not work, I looked at the solution megathread. Once I saw the simple approach, I got it coded quickly.
I need to look AoC over a bit more. Solution megathread? Had not realized there was one.
That was tough (day 7). Wasted quite a time on implementing a recursive solution, just to realize that a flat and compact solution (similar what I came up with intuitively in Python) can be also implemented in Fortran.
2 Likes
Thank goodness the “user” in this problem was generous enough to navigate the file tree depth-first.
1 Like
I made too many stupid mistakes, took me most of a day.
Here’s my meager offering. Life is such that I’ll be far behind, but I’m pretty happy with my solutions so far. Done days 1,2, and 3.
fpm is wonderful. Haven’t missed having a dictionary yet, and was able to make do on day 3 using bits as a set. Rock Paper Scissors mapped quite nicely to indices and a lookup table.
I think, day 8 is again a really nice demonstration for Fortrans power of transforming mathematical ideas in compact expressions using arrays and array instrinsics, I am really satisfied with my solution, but I am still wondering:
-
is there a more elegant way to read in the integers?
-
is there a smarter solution which only uses one loop (instead of the double loop) for the main part?
I couldn’t think of a more elegant way to read in the integers.
Your solution using array intrinsics is interesting - I did it “old school”, not particularly compact, but it was straightforward and fast enough. I do like to use array intrinsics.
I think, day 9 is an ultimative demonstration, why Fortran should provide efficient standardized containers. My Fortran solutions are almost as slow as the Python ones, just because of the missing hashmap / set for the efficient lookup of stored (sparse!) coordinates. I had to program a hacky workaround with dynamically increased arrays, (the naive version made it slower as the Python implementation!) but even so, the lookup times scale O(N) instead of O(1) and make the program much slower as it should be…
Did anyone managed to find a smarter way to check the visited positions? (Did anyone try stdlib’s hashmap?)
I first thought of a hashmap, but decided to see if a simple 2D array of reasonable size would handle it, and it does. Note that you need only record locations visited by the tail.
Part 2 is killing me because, while my code gets the correct answer on the two test sequences, the answer I get with the real input is a bit low (as in within 90 of the correct answer.) I can’t figure out what I’ve overlooked.
OK, sorted. I had nesting wrong. Very fast solution.
I’ll be missing several days next week due to travel - perhaps I’ll fill them in when I get back.
I considered using an external hash table implementation, but I guessed the time spent learning how to use it would far exceed the time spent waiting for findloc to traverse my array of visited locations. In the end, I spent way more time trying to understand and implement the rope “physics” than anything else.
One little convenience thing I did was to pack each location into a single 64-bit integer using transfer. That way, my array of visited locations was 1d, which made growing it and searching it a bit nicer. My solution
Edit: oops, I forgot my final version used any to check for already visited locations, rather than findloc. Same complexity, though.
Day 10 took me longer than it should have, as I misunderstood the initial instructions. Once I got that sorted, part 1 came out right and part 2 was a doddle. Got to use FINDLOC again!
Day 11 part 2 is the kind of these that I struggle with because I don’t have a math background, though I recognized it had something to do with primes. So, I had to go to the solution megathread to get a hint. With that it was easy.
The trick with 64-bit integer is neat, indeed. Still, in a real “scientific” application with long trajectories, I would want to avoid any operations with O(N) looking up times (any ord findloc) as well as the a = [a, newelement] array growing trick we have to use in those examples all the time. Having proper lists and hashmaps would cure both problems.
2 Likes