sitemap
Supported browsers: Internet Explorer 6.0+, Firefox 3.0+, Safari 3.0+, Chrome 5.0+, iPhone4 (partial support and may have to reload the page). Some graphics may not work in Opera.
Imagine a cube with the length of each side being one unit (e.g., one centimeter). The volume of the cube is one unit cubed (e.g., one centimeter cubed, equals one milliliter). Define X, Y, and Z perpendicular axes centered at the center of the cube, perpendicular to the cube's faces, parallel to various edges. Use a drill of diameter one unit to drill out the cube along the X axis. The drill is centered in two parallel cube faces and tangent to four faces. After drilling, there would be four identical pieces, just barely split from one another (but imagine we keep the pieces from separating). How much of the original volume did the drill remove? How much volume remains? Well, this is equivalent to a circle inscribed in a square. The fraction removed is pi/4 (~0.7854); the fraction remaining is 1-(pi/4), or about 0.2146. Not difficult at all.
Now we drill out the four remaining pieces along the Y axis, centered in that face, tangent to four faces. How much volume remains now? Now it is not so easy to calculate. We could use integral calculus to determine the volume but we won't do that in this demo. Let's move ahead to the final step.
Now we drill out the eight remaining pieces along the Z axis, centered in that face, tangent to four faces. We end up with eight identical corner pieces: eight octants, eight corners. How much volume remains now? We could solve this with integral calculus (a triple integral), which does give a precise, analytical answer. If you like, go ahead and solve that. Later in this page I will give a link to a calculus solution. However, here I want to give a visual demo that doesn't use calculus.
Let's use a computer program to generate a lot of random points within the cube. It is easy to have the program test and record whether each point would be drilled out by one of the drills or would remain untouched. If we divide the number of points that remain untouched divided by the total number of random points, we get an approximation to the volume that remains after drilling. This numerical integration technique is called Monte Carlo integration or the Monte Carlo method (named after the famous Monte Carlo Casino in Monaco).
Let's watch as the program finds points that remain after drilling. We'll make it colorful!
(If the drawing canvas does not appear, is really short, or is blank, reload the page. The drawing canvas can be resized as you please (except on multitouch devices) by dragging and releasing the magenta drag-handle at the lower right of the canvas; the demo will restart.)
This demo does not perform well on Internet Explorer.
This demo runs best when a lot of memory is available. It may run relatively slowly on mobile devices and older, slower PCs: the demo still functions but try it on a newer laptop or desktop for best effect. You can increase the size of the drawing canvas - which is interesting - but the demo will slow down to a small or large extent, depending. You may be able to speed the demo by minimizing the browser for a few minutes.
Instructions:
If you were watching the beginning of the demo carefully, you might have noticed that all eight corners progress at the same rate... a little more exactly than randomly. Since the eight corners of the drilled cube will be identical/symmetrical, the volume remaining in the cube will be eight times the volume of any one corner. To speed the graphical demo, I generated random points within just one of the eight octants within the cube and mirrored those points to all eight octants. The count at the upper right is the total number of points (random plus mirrored); the number of generated random points is one eighth of this.
Notice that the volume fraction does not stabilize its fifth and sixth decimal places even after after hundreds of millions of random points generated. It takes more than a few billion (thousand million) random points to converge to that accuracy but we get third decimal place accuracy after a few million random points. There are other numerical integration techniques that may converge more quickly for a given problem. (Accuracy might also depend upon the specifics of the pseudorandom number generator and independence of the x, y, and z values. In JavaScript, we only get one random number generator, seeded automatically from clock time: we cannot start three random number generators with different seeds.)
Well, but what should the volume remaining after drilling be, exactly?
This is a problem that can be solved analytically using integral calculus.
Spoiler alert: if you want to try this yourself, stop reading here.
Go here for my integral calculus solution. The volume remaining after drilling out the unit cube in three directions is exactly 1+sqrt(2)-(3*pi/4). Evaluating this formula to nine decimal places we get 0.058019072. Rounding to six decimal places we get 0.058019. Our simulation did not lock onto this precision even after a billion random points generated.
We know that the volume remaining after the first drilling would be 1-(pi/4). If we take this value and subtract the final volume remaining, we get that the second and third drillings together removed a volume of (pi/2)-sqrt(2). It's interesting that the solution involves the square root of 2. Considering the problem geometrically, do you see why the square root of 2 is involved?
Switching gears, if we were highly skilled machinists, we might be able (with some difficulty) to drill the holes perfectly in a metal or plastic cube that we constrain not to fall apart into four, then eight, pieces during machining. If we were able to machine it, then we could weigh the pieces accurately. Or we could use Archimedes' technique of immersing the pieces in water to determine their volume... and eureka! Of course, we could never get the accuracy of the integral calculus analytical solution.
In this demo, you see the individual random points as display pixels. You might expect that the demo is using raster graphics (e.g., HTML5's canvas element) but actually it is using vector graphics (SVG). This is part of the reason why the demo gets slow if you resize the display canvas to be very large. But so far none of my browsers and systems have crashed or hung even resizing it to be huge. (However, this demo did not work with Internet Explorer so I disabled it for IE.)
Following are some related Wikipedia, and other, articles.
I hope you found this interesting, useful, and/or fun. Is there a demo you would like me to add? Would you like to be notified when a new demo is available? Links for sharing, reporting a problem, or emailing me are available in the pull-down menu at the top of the page. Feel free to link to my pages, screencast them to YouTube, or reuse my source code with attribution (MIT-style license).
Friend Links
Recommended Links