This method is not time sensitive. Because of conservation of momentum and energy, Euler integration is not an issue. The problem is that when a collision happens, you let the 2 objects intersect with themselves and the wall. This leads to the small cube slowly drifting through the wall. If you just snap back the cubes positions after a collision, you should be fine. Technically the pieces don't even need to move, you just have to count the collisions respecting the alternating order of wall and cube collisions.
The problem here is that we don't know if the blocks collided until it's too late and they're already overlapping. So we must reduce the time step to be notified earlier of a collision occurring. You're suggestion of overwriting the position of the blocks breaks a few laws of physics and will introduce an additional source of error without actually fixing the original issue. There are two solutions: 1. Upon detecting overlap, compute how far back to reverse the simulation until the blocks are just touching. Do so, and then compute the collision and continue. 2. Before moving the blocks, measure the distance to the next collision. If this is less than the sum of the velocities then advance the simulation by a fractional time step such that they just meet. Then compute the collision and continue. In physics engines, method 1 is called a discrete simulation, advancing by a fixed time step and solving intersections retro-actively, very common in video games as it's relatively cheap to compute. Method 2 is called continuous collision resolution and is more computationally expensive and so sees less use in video games (Fun fact: this method was used in Diablo 3's bespoke physics engine to give us that sweet ragdoll physics)
@@thetastefultoastie6077 The only thing that matters to get an accurate result is the order of wall and cube collision. And it's only decided by the sign of the relative speed of the small cube. As long as you maintain that order, anything goes. Position doesn't matter much as long as you ensure the correct order.
Ah, thank you for this discussion. Indeed I did not explain this properly, oy! @Tasteful, if you would like to write a new comment (essentially what you wrote above) that is stand-alone I can pin it. I will address this during my live stream and maybe try to make a new version?
@@thetastefultoastie6077 I understand what you're saying, but this isn't a time dependant problem, and can be solved analytically. Therefore the only reason for the time stepping should be visualisation, not too get the answer. The visualisation could be solved simply with the fix above but it means it'd run faster without grinding to a halt.
Man For this you deserve 3,141,592,653,589,793,238,462,643,383,279,502,884,197,169,399,375,105,820,974,944,592,307,816,406,286,208,998,628,034,825,342,117,067 subscribers. And No I didn't copy-paste or see and type it. I remember 100 digits of PI using ASAP Science's song '100 digits of PI '!!
It's amazing how accurate you got it! Even having seen the 3blue1brown video, I was blown away by how the digits of Pi appeared, and the correct ones to boot! And all with so little code.
@@Brahvim I’ve never looked at a comment and wanted to make a comment about how awful it was until now. I don’t care that it was over a year ago, that was one of the worst things that I have read in my entire life. Please, never let any words escape from your head again, whether verbal, digital, or pen and paper. Your thoughts do not deserve to be heard.
@@brando3465 _Thanks._ I've always talked to people about my TH-cam comments sounding cringe anyway. _Well this one was just stupid,_ and I'll have to make sure I make less of these. TH-cam is _just not_ the place for me to do these things, maybe. ...Thanks.
Agree !!! Pi is such a magical number , so mind bending where and how people come up with different ways to find it ! It's everywhere too !! Happy Pi day ! :D
Knowing the velocity of both blocks, you could calculate the point in space and time where they collide. So you don't need time steps at all! (Except for animation purposes). If the time until collision is above say 1/60th of a second you could use a time step for animating. In fact that would give you a nice iterative formula for pi. (That would converge quite slowly!)
Yeah I didn't use time or distance at all in my program to count collisions. It might seem like the small block could get crushed between the wall and big block if the big block is really big but I think what happens is there is trillions of small collisions that occur slowing the big block down enough so the crushing can't happen. At least in a mathematical model.
29:47 The difference between float/double and BigDecimal, as well as the difference between int/long and BigInteger, is that using primitive types, the JVM is allocating a chunk of memory just for that primitive type's previously-set boundary, while as a for BigInteger/BigDecimal, the JVM is directly using the memory to store the bytes, which naturally results in a bigger usage of memory for the application. If you have a lot of RAM and you need high-precision for numbers, you can safely use BigInteger/BigDecimal. Just be careful not running into Infinite loops!
I did this in processing myself and after 7 digits it was just too slow.. I can't believe it went till 9 digits at such a good speed. But it's super impressive. I love how we all enjoy coding mathematical ideas that just make programming fun😂❤️
That clack sound is the same as the clack that Clackers made, a toy from the late 60's that used to break kids wrists :) Good article on Wikipedia about them. Super video!
A Good way would be to calculate the "exact" collision point. Then you could calculate the amount of time that the small block needs to hit the wall, add v*time to both, calc exact collision point, repeat.
30:10 For the optics method, the trick is to use complex numbers to represent the angles, rather than explicitly dealing with angles or relying on any kind of trig function. Using the small angle approximation you can construct a complex number for a particular angle 𝜃 as just 1+𝜃i, and then n*𝜃 is (1+𝜃i)^n. Here's a quick python implementation: ideone.com/T4UCnV For the kinematics method, instead of a fixed timestep you can directly compute the time until the next collision as dt = (x1+w1-x2)/(v2-v1) and make that as one single step; then to animate it you can either interpolate between timesteps or you can have a separate fixed-timestep integration that you re-seed from the main integration at each collision. This also lets you play the clack sounds at a more granular time resolution rather than forcing it to be quantized to the animation framerate. If you're interested I have a python implementation of this that works for an arbitrary number of blocks in an arbitrary number of dimensions, including an interpolation mechanism. At this point I don't have anything for generating the actual animation, but I can at least plot graphs: gist.github.com/AJMansfield/00d69e1488c2b1eb56b8c4da2ca739dc Alternately, you can even forego tracking the block positions altogether, since we already know what order the collisions happen in and the position doesn't figure into the momentum transfer equation. If you take this route you can also simplify things even further and perform the momentum transfer as a single matrix multiply rather than as a number of separate steps. Here's another quick python implementation of this method: ideone.com/jPBh8C
You can also simulate/calculate pi in different bases by adjusting the mass ratio between the blocks! You get pi in base ten if the ratio is 10^2^n, you can do binary with 2^2^n, hex with 16^2^n, etc. You have to convert from base 10 to the target base, of course.
@@philippg6023 Yes, he does prerender everything. It's a python library he wrote himself. I mean, why should he play it live? It's a video, after all, playing it live and recording it would be a waste of precision and smoothness.
I watched the videos from 3blue1brown when they were released and I also absolutely fell in love with the clacking, hahaha! I like seeing I'm not the only weirdo in this world :3
Nice hint with the video length (31:41) And offcours awesome video as always I find it cool how you are so motivated and you actually made me want to learn a few digits of PI myself so I made an app that lets you train PI like a vocabulary trainer. I think you would like it
The reason why Euler integration is normally approximate is because it assumes v to be constant throughout a time step, resulting in setting x += v, where in theory it should be x+= integral of v dt. In this case the objects are moving conserving momentum, so v is a piecewise constant function and, as long as the time step is smaller than the smallest distance between two consecutive collisions, the algorithm will give exact results.
I think that using the speed of both blocks after the last collision can bring more digits to pi ; possibly up to 8 digits for 64 bit double floating point. The slope of that line represent the best rational approximation to get a few more digits of pi. The current code compute 10 digits of pi and double are 18 digits total. One extra twist of optimization could be to avoid redrawing the cubes if they didn't move by a whole integer, which is one pixel. We expect no more than 1 order of magnitude improvement here. This code reminds me the bresingham algorithm to draw circles using integers only.
Dan, just precalculate the collision without simulating velocity in steps. All you really need to do is calculate the moment of the collisions, not what's in between
What I thought about doing is: instead of doing a simulation that checks collision through coordinates, you could just evaluate whether the blocks will collide or not or if the smaller block will hit the wall, like so (block 1 is the smaller one, with speed v1 and block 2 is the bigger one, with speed v2): if v1 > 0 and v1 < v2, the blocks will never collide again; if v1 < v2, block 1 will hit the wall; if neither is true, blocks 1 and 2 will collide with each other and change speeds based on the formula. Based on this idea, I created a program in C++ that does exactly that, but by 11 digits the imprecision got too big and the results stopped matching :\
I just programmed it on my phone up to d=9, was a bit tricky to get right but not that bad... Essentially the main part of code is: public boolean iterate() { if(v1>0) { cols+=2; double tempV1 = getNewV1(); double tempV2 = getNewV2(); v1 = tempV1; v2 = -tempV2; return true; } if(Math.abs(v2)>Math.abs(v1)) { cols++; double tempV1 = getNewV1(); double tempV2 = getNewV2(); v1 = tempV1; v2 = -tempV2; if(v2
You can speed up the calculations by a lot if you just set timeSteps to 6 ** (digits - 1), instead of 10 ** (digits - 1). You won't miss any counts, I've tested it with 11, and it didn't miss a single number.
you could make the time steps increase proportionally to velocity and inversely to distance close distance + high velocity = lots of tiny steps large distance + low velocity = few large steps
I wonder what would happen if you changed the base in m2 formula to be equal to 4 (which is 2^2) and changed the number format to binary. Would it calculate Pi digits in binary? EDIT: I have checked my idea and it seems to be working properly in other bases. You can introduce another const called base and use it to display pi in different bases: //before setup const base = 2; //adding new constant const timeSteps = base ** (digits - 1); //modifying timeSteps ... //in setup const m2 = power(base ** 2, digits - 1); //modifying m2 ... //in draw countDiv.html(count.toString(base)); //modifying div's inner HTML The only problem is that the number of digits is not equal to the value of the digits variable in all bases. (if digits == 6 it displays 7 bits in binary) Any ideas how to fix it? EDIT2: the value of pi in binary is equal to: 11.001001... and 10.01021... in ternary Note that there are 2 digits instead of one before the floting point, so I suspect that's why it displays one additional digit in binary and ternary
:D I tried to make this simulation when it came out and it it worked but was rly buggy because there box went on the the other side of the "wall" thing Thank you so much :D
I think a better way to fix the precision issues would be to use a variable timestep. You can predict exactly when the next collision will be so you can be sure you get it right.
This idea have been discussed in more detail in another comment trail. The two choices are skipping until close to collision then allow the current code to resume looping from 0 to 9 times to detect the collision and find the pi digit or go past collision and back track with a loop similar to the present code.
I recreated this in Python using Pygame and it starts to lag at even 5 digit and 1000 time steps! Frame rate drops really badly. Any suggestions on how to speed it up?
This method is not time sensitive. Because of conservation of momentum and energy, Euler integration is not an issue.
The problem is that when a collision happens, you let the 2 objects intersect with themselves and the wall. This leads to the small cube slowly drifting through the wall.
If you just snap back the cubes positions after a collision, you should be fine.
Technically the pieces don't even need to move, you just have to count the collisions respecting the alternating order of wall and cube collisions.
I came to see if this comment was here, not too write it myself, but because I didn't think it was a problem but wanted to get confirmation :-)
The problem here is that we don't know if the blocks collided until it's too late and they're already overlapping.
So we must reduce the time step to be notified earlier of a collision occurring.
You're suggestion of overwriting the position of the blocks breaks a few laws of physics and will introduce an additional source of error without actually fixing the original issue.
There are two solutions:
1. Upon detecting overlap, compute how far back to reverse the simulation until the blocks are just touching. Do so, and then compute the collision and continue.
2. Before moving the blocks, measure the distance to the next collision. If this is less than the sum of the velocities then advance the simulation by a fractional time step such that they just meet. Then compute the collision and continue.
In physics engines, method 1 is called a discrete simulation, advancing by a fixed time step and solving intersections retro-actively, very common in video games as it's relatively cheap to compute. Method 2 is called continuous collision resolution and is more computationally expensive and so sees less use in video games (Fun fact: this method was used in Diablo 3's bespoke physics engine to give us that sweet ragdoll physics)
@@thetastefultoastie6077 The only thing that matters to get an accurate result is the order of wall and cube collision. And it's only decided by the sign of the relative speed of the small cube. As long as you maintain that order, anything goes. Position doesn't matter much as long as you ensure the correct order.
Ah, thank you for this discussion. Indeed I did not explain this properly, oy! @Tasteful, if you would like to write a new comment (essentially what you wrote above) that is stand-alone I can pin it. I will address this during my live stream and maybe try to make a new version?
@@thetastefultoastie6077 I understand what you're saying, but this isn't a time dependant problem, and can be solved analytically. Therefore the only reason for the time stepping should be visualisation, not too get the answer.
The visualisation could be solved simply with the fix above but it means it'd run faster without grinding to a halt.
I love that the video length is Pi (31:41)! Happy #PiDay!
Was this intended?
@@MaxPicAxe yes
Holy crap I didn't notice this, I love when youtubers take the time to add little easter eggs xD
We have a mission - lets make the likes 3 141
@Shreerang Vaidya let the sharing begin #Piday #Collisions #JavaScriptbenchmark
15:30 FUNDAMENTAL THEOREM OF ENGINEERING
Gordon Chan You had 3.14 likes but now you have 3.15
e=pi=3
and sin x = x ofc
g/3 = pi = e = 3
Jose Gonzalez ah yes, g/3
Calculates Pi On Pi day ... with a Pi long video ...
how committed someone can be?
dont forget eating pie and singing the pi song
Lol
@@tregi yup
Pi commited
approximately pi long
27:14
It goes like this, the wall, the block,
the drawing loop, the ticking clock,
the baffled Dan programming Pi collisions 🎶
You should be proud of yourself
That's amazing
p5 js
p5 js
The baffled Dan composing Pillelujah!
Pillelujah, Pillelujah, Pillelujah, Pillelujah.
What is that to the tune of?
the video length is 31:41 this is just excessive
And also: Unexpected and a Coincidence (maybe)
Man For this you deserve 3,141,592,653,589,793,238,462,643,383,279,502,884,197,169,399,375,105,820,974,944,592,307,816,406,286,208,998,628,034,825,342,117,067 subscribers.
And No I didn't copy-paste or see and type it. I remember 100 digits of PI using ASAP Science's song '100 digits of PI '!!
Oh god.
It's amazing how accurate you got it!
Even having seen the 3blue1brown video, I was blown away by how the digits of Pi appeared, and the correct ones to boot! And all with so little code.
You could also use this way:
console. log(Math.PI);
Mahdi Nicoo that wouldnt be fun
@@andrewzhang8512 r/wozzles
@@andrewzhang8512 r/woooosh
engineers: "that's kinda like pi, 3!"
A few feet is no issue!
`3!`
Hmm, "Three factorial"?
(That's `27`!)
r/unexpectedfactorial? :wheeze:
timestamp: 15:30
@@Brahvim I’ve never looked at a comment and wanted to make a comment about how awful it was until now. I don’t care that it was over a year ago, that was one of the worst things that I have read in my entire life. Please, never let any words escape from your head again, whether verbal, digital, or pen and paper. Your thoughts do not deserve to be heard.
@@brando3465 _Thanks._ I've always talked to people about my TH-cam comments sounding cringe anyway. _Well this one was just stupid,_ and I'll have to make sure I make less of these.
TH-cam is _just not_ the place for me to do these things, maybe.
...Thanks.
This is frickin amazing :D Math and Computer Science are just so amazing! Happy Pi Day everyone
Agree !!! Pi is such a magical number , so mind bending where and how people come up with different ways to find it ! It's everywhere too !!
Happy Pi day ! :D
Knowing the velocity of both blocks, you could calculate the point in space and time where they collide. So you don't need time steps at all! (Except for animation purposes). If the time until collision is above say 1/60th of a second you could use a time step for animating. In fact that would give you a nice iterative formula for pi. (That would converge quite slowly!)
Yeah I didn't use time or distance at all in my program to count collisions.
It might seem like the small block could get crushed between the wall and big block if the big block is really big but I think what happens is there is trillions of small collisions that occur slowing the big block down enough so the crushing can't happen. At least in a mathematical model.
26:52 I love the song, you should upload a video just with the song
29:47 The difference between float/double and BigDecimal, as well as the difference between int/long and BigInteger, is that using primitive types, the JVM is allocating a chunk of memory just for that primitive type's previously-set boundary, while as a for BigInteger/BigDecimal, the JVM is directly using the memory to store the bytes, which naturally results in a bigger usage of memory for the application.
If you have a lot of RAM and you need high-precision for numbers, you can safely use BigInteger/BigDecimal. Just be careful not running into Infinite loops!
man i was feeling depression because i field to learn advanced javascript and u made me more interested in it u made me change my mind
Man, it's really cool you just see the physics through the math, like with hypothesising what the m=1 scenerio is. You're quite the polymath!
I did this in processing myself and after 7 digits it was just too slow.. I can't believe it went till 9 digits at such a good speed. But it's super impressive. I love how we all enjoy coding mathematical ideas that just make programming fun😂❤️
That clack sound is the same as the clack that Clackers made, a toy from the late 60's that used to break kids wrists :) Good article on Wikipedia about them.
Super video!
Oh the concept is from 60s, I used to have one of those like almost 10 years ago
That want dark, very quickly.
One of the most respected youtube channels.
You are amazing.
This is one of the best channel on TH-cam!
A Good way would be to calculate the "exact" collision point. Then you could calculate the amount of time that the small block needs to hit the wall, add v*time to both, calc exact collision point, repeat.
12:27
We can think of the wall as 256 high bedrock
What an amazing video as always! The video edition is every time getting better too. Great work!!! Thanks!!!
+3Blue1Brown needs to see this. Extremely laggy and inefficient, but extremely elegant.
I am liking the new editing style
30:10 For the optics method, the trick is to use complex numbers to represent the angles, rather than explicitly dealing with angles or relying on any kind of trig function.
Using the small angle approximation you can construct a complex number for a particular angle 𝜃 as just 1+𝜃i, and then n*𝜃 is (1+𝜃i)^n.
Here's a quick python implementation: ideone.com/T4UCnV
For the kinematics method, instead of a fixed timestep you can directly compute the time until the next collision as dt = (x1+w1-x2)/(v2-v1) and make that as one single step; then to animate it you can either interpolate between timesteps or you can have a separate fixed-timestep integration that you re-seed from the main integration at each collision. This also lets you play the clack sounds at a more granular time resolution rather than forcing it to be quantized to the animation framerate.
If you're interested I have a python implementation of this that works for an arbitrary number of blocks in an arbitrary number of dimensions, including an interpolation mechanism.
At this point I don't have anything for generating the actual animation, but I can at least plot graphs: gist.github.com/AJMansfield/00d69e1488c2b1eb56b8c4da2ca739dc
Alternately, you can even forego tracking the block positions altogether, since we already know what order the collisions happen in and the position doesn't figure into the momentum transfer equation.
If you take this route you can also simplify things even further and perform the momentum transfer as a single matrix multiply rather than as a number of separate steps.
Here's another quick python implementation of this method: ideone.com/jPBh8C
Wow, thanks for this thorough explanation and code samples! Much appreciated!
A podcast with Grant and Dan in it has the potential to break the Internet.
The most effective way to calculate Pi by far.
I loved that getting pi , and pi song and eating pi , thank you so much ❤❤❤
Best PI day ever. Thank you so much dan!!!
It would be cool to see if you graph velocities like in the 3b1b video
Props to the editor on this one. This is my favorite episode!
You can also simulate/calculate pi in different bases by adjusting the mass ratio between the blocks! You get pi in base ten if the ratio is 10^2^n, you can do binary with 2^2^n, hex with 16^2^n, etc. You have to convert from base 10 to the target base, of course.
why does the visualization video of 3blue1brown is so smooth?
Well because its a visualisation Video ; ) maybe he pre calculated it so basically he rendered the video
@@philippg6023 Yes, he does prerender everything. It's a python library he wrote himself. I mean, why should he play it live? It's a video, after all, playing it live and recording it would be a waste of precision and smoothness.
Yup
It's MANIM. 😁
Mathematical Animation Engine written by Grant Sanderson.
That rendition of Hallelujah was beautiful.
Oddly enough, I actually did this a couple months ago! I coded the collision thingy! Neat
All your videos are awesome! But this one must be one of the coolest and funniest I've ever seen!
I watched the videos from 3blue1brown when they were released and I also absolutely fell in love with the clacking, hahaha! I like seeing I'm not the only weirdo in this world :3
This is my favorite video you've done!
Thanks for blowing my mind with this fact all over again. :)
Nice hint with the video length (31:41)
And offcours awesome video as always I find it cool how you are so motivated and you actually made me want to learn a few digits of PI myself so I made an app that lets you train PI like a vocabulary trainer. I think you would like it
The reason why Euler integration is normally approximate is because it assumes v to be constant throughout a time step, resulting in setting x += v, where in theory it should be x+= integral of v dt.
In this case the objects are moving conserving momentum, so v is a piecewise constant function and, as long as the time step is smaller than the smallest distance between two consecutive collisions, the algorithm will give exact results.
this is the coolest thing ive ever seen in my life
In the last few videos, your editing was so nice. If possible, please keep it up like this!
when I study too much , I just take a break and watch your videos . Great work , you are making this world a better place by making silly mistakes ;)
This is your best video. I love it.
This may be my favorite Pi video ever!
I think that using the speed of both blocks after the last collision can bring more digits to pi ; possibly up to 8 digits for 64 bit double floating point. The slope of that line represent the best rational approximation to get a few more digits of pi.
The current code compute 10 digits of pi and double are 18 digits total.
One extra twist of optimization could be to avoid redrawing the cubes if they didn't move by a whole integer, which is one pixel. We expect no more than 1 order of magnitude improvement here.
This code reminds me the bresingham algorithm to draw circles using integers only.
You make me feel happy. Thanks
AMAZING DEMONSTRATION!
Dan, just precalculate the collision without simulating velocity in steps. All you really need to do is calculate the moment of the collisions, not what's in between
Very cool Daniel. Interesting the creativity that you have.
You could make the number of time steps dependent on the distance to the wall. That would speed up the longer calculations significantly.
The editing on this video is amazing !
Awesome name "collision clacking magic wonderfull thing!" , That's the coolest name ever!
is it coincidence that the length of the video is equal to the value of pi*10?
No
But pi*10 = 31.415926...? Length of video is 31:41.
pi*10^1 lol
Can we get a code based Ukulele album? I'll happily master it for you.
Thank you for the serenade in pi, much appreciated.
I love the clacking too !
What I thought about doing is: instead of doing a simulation that checks collision through coordinates, you could just evaluate whether the blocks will collide or not or if the smaller block will hit the wall, like so (block 1 is the smaller one, with speed v1 and block 2 is the bigger one, with speed v2):
if v1 > 0 and v1 < v2, the blocks will never collide again;
if v1 < v2, block 1 will hit the wall;
if neither is true, blocks 1 and 2 will collide with each other and change speeds based on the formula.
Based on this idea, I created a program in C++ that does exactly that, but by 11 digits the imprecision got too big and the results stopped matching :\
The best crossover, EVER!
I loved that video, glad you could remake it!
This guy belongs at NASA.
Good stuff Mr Shiffman!
I really like 3blue1brown’s Collision Clacking Magic Wonderful Thing.
Click click bzzz weeeeuuuuuuueeeewwww bzz click click
The man can code and serenade!
The song was the best thing ever, you should make an album!
Ok, so you were singing with the amazing grace melody. gotcha , divine number.
easter egg found:
the lenght of the video is 31:14, which is pi!
I just programmed it on my phone up to d=9, was a bit tricky to get right but not that bad...
Essentially the main part of code is:
public boolean iterate()
{
if(v1>0)
{
cols+=2;
double tempV1 = getNewV1();
double tempV2 = getNewV2();
v1 = tempV1;
v2 = -tempV2;
return true;
}
if(Math.abs(v2)>Math.abs(v1))
{
cols++;
double tempV1 = getNewV1();
double tempV2 = getNewV2();
v1 = tempV1;
v2 = -tempV2;
if(v2
Your videos time also represent first 4 digit of pi😁😁😁.. love your video 🙌🙌🙌
You can speed up the calculations by a lot if you just set timeSteps to 6 ** (digits - 1), instead of 10 ** (digits - 1).
You won't miss any counts, I've tested it with 11, and it didn't miss a single number.
so glad I am alive to see this
We have an anual competition at our college, where people recite the numbers of pie, last year a 12 year old girl recited over 900 decimal numbers
Just started with programming and so, and I have one doubt. What is the purpose of writting "return newV" in the bounce function?
Very nicely edited video
Hi Daniel, great video as always, lovely stuff :) Did you consider using BigInt in JS for this challange? Maybe you can go for 20 digits :D
I did consider it! I have some videos coming out soon where I experiment with this idea! (using BigDecimal in Java)
@@TheCodingTrain great, can't wait, I love your videos :)
Please tell me what is the best coding to learn for 8-16-32-64-128-256-512-1024bit games? Even 64-128 would work.
you could make the time steps increase proportionally to velocity and inversely to distance
close distance + high velocity = lots of tiny steps
large distance + low velocity = few large steps
Amazing video as Usual!!! Always learn a lot from your Channel !!
I wonder what would happen if you changed the base in m2 formula to be equal to 4 (which is 2^2) and changed the number format to binary. Would it calculate Pi digits in binary?
EDIT: I have checked my idea and it seems to be working properly in other bases. You can introduce another const called base and use it to display pi in different bases:
//before setup
const base = 2; //adding new constant
const timeSteps = base ** (digits - 1); //modifying timeSteps
...
//in setup
const m2 = power(base ** 2, digits - 1); //modifying m2
...
//in draw
countDiv.html(count.toString(base)); //modifying div's inner HTML
The only problem is that the number of digits is not equal to the value of the digits variable in all bases. (if digits == 6 it displays 7 bits in binary) Any ideas how to fix it?
EDIT2: the value of pi in binary is equal to:
11.001001...
and 10.01021... in ternary
Note that there are 2 digits instead of one before the floting point, so I suspect that's why it displays one additional digit in binary and ternary
This is awesome!
23:50 The face of pure surprise
Really interesting video :D
Should we start parallel threading and making use of GPU? ;)
awsome as allways :) only thing missing is having the block scale based on their mass
Belated pi day wishes dood,...I am new subscriber...thank u for made this video...I am gonna make this concept in unity(using c#)
Oh cool! please share when you do!
:D I tried to make this simulation when it came out and it it worked but was rly buggy because there box went on the the other side of the "wall" thing
Thank you so much :D
I programmed this algo right away after watching 3b1b video about it.
Awesome Video man !
phantastic how this works. would be interesting how this correlates to a circle
Watch 3blue1brown’s video
I was just about to do the same thing! Good work! Happy PI day!
This guy is more of a comedian than a programmer
the video was fab and the song was terrifying 🤣😂
Your computer must be insane to be able to handle that whole thing in any reasonable amount of time.
That was amazing
I think a better way to fix the precision issues would be to use a variable timestep. You can predict exactly when the next collision will be so you can be sure you get it right.
Yes, great suggestion!
This idea have been discussed in more detail in another comment trail. The two choices are skipping until close to collision then allow the current code to resume looping from 0 to 9 times to detect the collision and find the pi digit or go past collision and back track with a loop similar to the present code.
god i love this guy! awesome job!
For collision detection i think you should rely on = instead of allowing it to overlap by < checks? As you said its not elastic
wouldnt work unless unlimited framerate
There's a way to faster the counting?
I recreated this in Python using Pygame and it starts to lag at even 5 digit and 1000 time steps! Frame rate drops really badly. Any suggestions on how to speed it up?