That’s very odd
Can you post the code somewhere?
You have: (check-equal? (solve-2) 939490236001473) but the solution to part 2 is 640856202464541
Thanks for the explanation. I was so close! Looking at some notes I scribbled - I solved for bus ids 7 & 13 w/ 77 and 78 timestamps, and I see a 91 I circled (7 * 13). I was trying to see the relation between 91 and the timestamps, but didn’t think to just add 91 :)
lol - that’s funny - I had no idea about that!
This has to be a ton of work for the organizer.
Hard enough to come up with good puzzles and ensure they’re bug-free, but to have individualized inputs also seems to add a lot of work depending on the puzzle.
IIRC there are some parsing techniques that can generate generators as well, so Eric may be able to leverage something like that.
Thanks for the nudge! I’ve been really enjoying my first time with AoC, so I badged up despite having “C++” in the name ;)
@me1890 how did you come to know about Van Eck’s sequence?
It was covered in a numberphile video in June 2019. https://youtu.be/etMJxB-igrc
I just so happend to still have the code i wrote while watching that video
@samth…for whatever reason, this showed up while I was testing but not when I tried to replicate this behavior explicitly
regardless, my friend and I engineered similar solutions, and they also noted a significant improvement with begin0 — I can ask them, I guess?
was it perhaps when debugging was on in DrRacket?
I am not using DrRacket
redid Day 15 using a vector in Typed Racket, solves Part 2 in around 1.1 seconds on my machine: https://git.knightsofthelambdacalcul.us/hazel/advent-of-code-2020/src/branch/canon/day15.rkt anyone have any faster solutions without using racket/unsafe/ops?
also the hash table solution is much slower here, for some reason.
For comparison, my naive, brute force, <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15-mutable-hash.rkt|mutable hash table solution> takes 6.2 seconds on a 16" macbook pro.
Using a <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15-vector.rkt|mutable vector> instead of the mutable hash table brings it down to 0.82 seconds using #lang racket on Racket v7.9 [cs]
There’s also tricks he has to consider, like making sure to generate inputs that satisfy some invariants that aren’t actually stated in the rules but which are necessary to avoid pathological behavior
Like the buses being prime in day 13 or there being no gaps of two in day 10
I’m guessing he just has a program that generates random values inside suitable distributions then replaces them in the input
Right, reminds me a bit of Haskell’s quickcheck framework
I’ve heard of that, but only used something similar in rust.
Lastly, a <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15.jl|newbie Julia version> takes about 0.43 seconds. That makes me pretty pleased with the 0.82 second Racket version.
By the way, are you using Racket’s time to time your code, or are you timing it from the shell i.e. including load time?
time. I am using Racket BC and thus the VM startup time kinda sucketh
chez would probably help. only using BC because I’m too lazy to change the NixOS derivation.
i implemented a solution with fxvector and unsafe fx ops which brings like 10–20% improvement over plain vectors
This is interesting, I did <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15.c|a C version> based on the <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15.jl|Julia version> and it came in at 0.64 seconds - in between Julia and Racket ! It’s been decades since I coded C seriously, so I may have done something stupid.
Try a Chez Scheme version next!
I don’t even have Chez installed at the moment, and I’m pretty tapped out on this by now :) Bottom line - I’m pleased with Racket’s speed, and if I need more, I’ll use Julia :)
Although, now I am curious about fxvector given @haskal’s comments above!
Ok, last one :) <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15-unsafe-vector.rkt|Unsafe vector/arithmetic version> comes in at 0.75 seconds. @soegaard2 I would think Chez would be similar, but I’m not really sure.
So, the immutable hash table version is about 24x slower than the unsafe vector version.
Sorry for the noise, but to have all the results in one table: <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15.rkt|Racket w/ immutable hash table> => ~ 18 seconds <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15-mutable-hash.rkt|Racket w/ mutable hash table> => ~ 6 seconds <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15-vector.rkt|Racket w/ mutable vector> => 0.82 seconds <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15-unsafe-vector.rkt|Racket w/ unsafe vector/arithmetic> => 0.68 seconds <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15.c|C version> => 0.47 seconds <https://github.com/lojic/LearningRacket/blob/master/advent-of-code–2020/day15.jl|Julia w/ mutable vector> => 0.41 seconds
Racket/ unsafe vector/arithmetic => 0.75 seconds
C version => 0.64 seconds That’s pretty close!
Yes, and I’d be fine with the 0.82 seconds with regular vectors to avoid the clutter of fx...
@badkins racket/fixnum doesn’t provide unsafe operations. They check that their inputs are fixnums.
Ah!
I don’t think your vector ops are unsafe either.
You’ll need racket/unsafe/ops variants
on it …
0.68 seconds - I’ll update the table ^
Changing the vector initialization of the C version dropped it from 0.64 to 0.59s
while playing with racket/unsafe/ops to make my solution fast(tm) I have successfully caused DrRacket to segfault for the first time
please clap
more unsafe -> program go fast -> win
what’s notable (and odd) is that my Typed Racket solution, my unsafe solution, and @badkins’s unsafe solution all run in around the same time on my machine (around 1200 ms)
Typed Racket ought to be producing similar code to your use of unsafe
this confirms my theory that Typed Racket good
this happens with PLT_TR_NO_OPTIMIZE though (albeit I’m not familiar with Typed Racket enough to know if this makes a difference here)
day 16 spoilers
in the interest of minimizing amount of code i used maximum-bipartite-matching from graph for part 2 i think this is a pretty neat solution https://git.lain.faith/haskal/aoc2020/src/commit/dc4fb90f0808bc08a0048d59f8dd800cfdac44ea/16.rkt#L17
wow, that is so much nicer than what i made
I made some very ugly code for today
note i usually make revisions. if you wanna see the first version see the history. it’s pretty bad (aoc is a tradeoff between code quality and your submission time and i’m optimizing for both because reasons)
I honestly don’t know how to write this nicely in racket. Could you tell me how to write these loops better? https://gitlab.com/-/snippets/2050872
I can explain parts if it doesn’t make sense
my first recommendation would be to dump the let* and use internal defines
and define helper functions. a lot of them
i am going to see if i can solve this problem in rosette later
but for now i sleep
I will try to make some helper functions. Thanks for the tips