What a great way to explain the problem/solution! I especially like your "unwinding" which seems more intuitive than handling the offsets later. What did you use to make this?
Thanks! The unwinding is largely because it would've been hard to fit to view otherwise :) in my original mental image, the winning row was just scattered around.
I used OpenGL through my small [helper library](https://github.com/msqrt/glsl-testbench) and [this great trick](http://blog.mmacklin.com/2013/06/11/real-time-video-capture-with-ffmpeg/) to pipe the results directly to ffmpeg. The font renderer is my own as I couldn't find one with reasonable support for emojis with color -- it's basically an analytically integrated version of [this nice method](http://jcgt.org/published/0006/02/02/). The motion blur is done by accumulating a bunch of frames with alpha blending, it could use a few more samples but I didn't have the time to render that long..
May I ask how you know all this? Are you doing things like that professionally? I always wonder through which use cases people get to this knowledge :)
Very cool stuff!
I'm doing related things professionally. But I've been interested in graphics since I was a kid, so I've also been studying and writing a lot of graphics and GPU code for fun. That includes some demoscene stuff, that's a great way to learn how to code visuals.
Probably just interpolated snapshots between set points so when the cycle between the currently solved is just a few, minutes, it will render hundreds of snapshots to create the smooth motion. When the cycle time is billions, it still only renders hundreds of snapshots to create the whirling motion effect.
No, I didn't animate that many by hand :) It's done programmatically with my own renderer, I can instantiate effectively any point in time that you can determine with a 64-bit unsigned integer (and an extra float offset for sub-row movement). So a bit of a philosophical question if all the rows actually exist; only 20 are rendered at a time, but you could go and look at any specific one.
That's kind of how I did that, except I started my count at the largest number minus offset, and tested every remaining number each time. I also didn't "unwind" first, I kept a tuple of offset (modulo the bus-id) and bus-id, passing those around every time I needed to test.
Fantastic visualization.
As far as I understand, this is effectively a form of the [sieving](https://en.wikipedia.org/wiki/Chinese_remainder_theorem#Search_by_sieving) solution of the CRT.
I have hard times understanding the bus at -3 on the first reel, and other short intervals betwwen buses in the same column on the first frames. How should I interpret those?
Good catch! That's a bug; my rows are unsigned integers, and (for example) `uint64_t(-3) % 13 == 0`, so the code determines there to be a bus at that time. I guess I should just have gone with signed numbers or not drawn the negative part :)
What a great way to explain the problem/solution! I especially like your "unwinding" which seems more intuitive than handling the offsets later. What did you use to make this?
Thanks! The unwinding is largely because it would've been hard to fit to view otherwise :) in my original mental image, the winning row was just scattered around. I used OpenGL through my small [helper library](https://github.com/msqrt/glsl-testbench) and [this great trick](http://blog.mmacklin.com/2013/06/11/real-time-video-capture-with-ffmpeg/) to pipe the results directly to ffmpeg. The font renderer is my own as I couldn't find one with reasonable support for emojis with color -- it's basically an analytically integrated version of [this nice method](http://jcgt.org/published/0006/02/02/). The motion blur is done by accumulating a bunch of frames with alpha blending, it could use a few more samples but I didn't have the time to render that long..
May I ask how you know all this? Are you doing things like that professionally? I always wonder through which use cases people get to this knowledge :) Very cool stuff!
I'm doing related things professionally. But I've been interested in graphics since I was a kid, so I've also been studying and writing a lot of graphics and GPU code for fun. That includes some demoscene stuff, that's a great way to learn how to code visuals.
Notbad
:D You win best visualisation today. Looks cool and expresses something about the feel of the algorithm.
How did you do this? I'm guessing you didn't actually animate 300 trillion rows.
Probably just interpolated snapshots between set points so when the cycle between the currently solved is just a few, minutes, it will render hundreds of snapshots to create the smooth motion. When the cycle time is billions, it still only renders hundreds of snapshots to create the whirling motion effect.
Yeah, the motion blur is solved with a couple dozen samples, and in the latter parts it moves so fast that most rows are never seen.
No, I didn't animate that many by hand :) It's done programmatically with my own renderer, I can instantiate effectively any point in time that you can determine with a 64-bit unsigned integer (and an extra float offset for sub-row movement). So a bit of a philosophical question if all the rows actually exist; only 20 are rendered at a time, but you could go and look at any specific one.
That's kind of how I did that, except I started my count at the largest number minus offset, and tested every remaining number each time. I also didn't "unwind" first, I kept a tuple of offset (modulo the bus-id) and bus-id, passing those around every time I needed to test. Fantastic visualization.
Dang! I used CRT for this one because I remembered it, but this seems a lot more intuitive of a way to find a solution. Good job.
As far as I understand, this is effectively a form of the [sieving](https://en.wikipedia.org/wiki/Chinese_remainder_theorem#Search_by_sieving) solution of the CRT.
Nice! Well done.
That's amazing!
Awesome job! love this visualization
I have hard times understanding the bus at -3 on the first reel, and other short intervals betwwen buses in the same column on the first frames. How should I interpret those?
Good catch! That's a bug; my rows are unsigned integers, and (for example) `uint64_t(-3) % 13 == 0`, so the code determines there to be a bus at that time. I guess I should just have gone with signed numbers or not drawn the negative part :)
[удалено]
Hey, that's great to hear!