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.
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.
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 '!!
@@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 CZcams comments sounding cringe anyway. _Well this one was just stupid,_ and I'll have to make sure I make less of these. CZcams 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.
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!
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!
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.
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😂❤️
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
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.
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
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.
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 Π fun. I'd like ou to show basic workings for how physics formulas are derived. it's not that hard to run through conservation of momentum and energy quickly. years since I did it but we only had calculators and spreadsheets to do such models in those days!
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
: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
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 :\
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.
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
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
the video length is 31:41 this is just excessive
And also: Unexpected and a Coincidence (maybe)
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.
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?
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.
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 CZcams comments sounding cringe anyway. _Well this one was just stupid,_ and I'll have to make sure I make less of these.
CZcams 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
You could also use this way:
console. log(Math.PI);
Mahdi Nicoo that wouldnt be fun
@@andrewzhang8512 r/wozzles
@@andrewzhang8512 r/woooosh
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.
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!
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!!!
I loved that getting pi , and pi song and eating pi , thank you so much ❤❤❤
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
This is one of the best channel on CZcams!
+3Blue1Brown needs to see this. Extremely laggy and inefficient, but extremely elegant.
A podcast with Grant and Dan in it has the potential to break the Internet.
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.
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😂❤️
Best PI day ever. Thank you so much dan!!!
It would be cool to see if you graph velocities like in the 3b1b video
I am liking the new editing style
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
Props to the editor on this one. This is my favorite episode!
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!
Thanks for blowing my mind with this fact all over again. :)
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!
One of the most respected youtube channels.
You are amazing.
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
This is my favorite video you've done!
That rendition of Hallelujah was beautiful.
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.
Your computer must be insane to be able to handle that whole thing in any reasonable amount of time.
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 ;)
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
You make me feel happy. Thanks
This is your best video. I love it.
AMAZING DEMONSTRATION!
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!
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
The most effective way to calculate Pi by far.
Ok, so you were singing with the amazing grace melody. gotcha , divine number.
The man can code and serenade!
This guy is more of a comedian than a programmer
Awesome name "collision clacking magic wonderfull thing!" , That's the coolest name ever!
I was just about to do the same thing! Good work! Happy PI day!
The song is definitely hallelujah
This may be my favorite Pi video ever!
The best crossover, EVER!
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.
Dan be like:
* clack *
*NOICE*
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.
I loved that video, glad you could remake it!
The song was the best thing ever, you should make an album!
You could make the number of time steps dependent on the distance to the wall. That would speed up the longer calculations significantly.
I love how I understand all the coding stuff he is doing but I suck at coding myself
This guy belongs at NASA.
easter egg found:
the lenght of the video is 31:14, which is pi!
Thank you for the serenade in pi, much appreciated.
I love the clacking too !
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
so glad I am alive to see this
Very cool Daniel. Interesting the creativity that you have.
Really interesting video :D
the video was fab and the song was terrifying 🤣😂
amazing Π fun. I'd like ou to show basic workings for how physics formulas are derived. it's not that hard to run through conservation of momentum and energy quickly. years since I did it but we only had calculators and spreadsheets to do such models in those days!
cursed uppercase pi
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
Your videos time also represent first 4 digit of pi😁😁😁.. love your video 🙌🙌🙌
I programmed this algo right away after watching 3b1b video about it.
The editing on this video is amazing !
Awesome Video man !
Can we get a code based Ukulele album? I'll happily master it for you.
I love it when you normalize the speed of the video just to make us listen your pi song hahdhahshhsjjsdjjdjd so nice
I really like 3blue1brown’s Collision Clacking Magic Wonderful Thing.
Click click bzzz weeeeuuuuuuueeeewwww bzz click click
you must have a common ancestor with the nutty professor 😂
“Its 3, like PI!”
I am Gonna pretend I didn’t hear that......
: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
awsome as allways :) only thing missing is having the block scale based on their mass
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 :\
This is awesome!
Just started with programming and so, and I have one doubt. What is the purpose of writting "return newV" in the bounce function?
Good stuff Mr Shiffman!
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.
phantastic how this works. would be interesting how this correlates to a circle
Watch 3blue1brown’s video
Happy Pi day!!!
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
Amazing video as Usual!!! Always learn a lot from your Channel !!
Very nicely edited video
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!
I would like it to write the pi and compare it with the hits. Also, I would like different color when hitting the wall.
This was the first thing I ever programmed in Processing!
The "Never forget the this dot" sticker on your laptop, LOL