FE 'tkGooies'

FE Home Page >
FE Downloads Page >
FE 'tkGooies' Description Page >
FE 'tkGooies' 'MATHed' Page >
This 'tkCircleCircumferenceByPolygons' CodePage
INTRODUCTION to For several years now (circa 20132015), I have been planning to make a Tk GUI that draws a circle and draws 'regular' polygons (inscribed within and circumscribed about the circle)  with the added capability to compute the circumferences of the polygons  as an approximation to the circumference of the circle. Then the GUI could easily show the ratio of the circumferences of the polygons to the diameter of the circle  thus giving upper and lower bounds on the value of pi. I was motivated to do this by seeing images like the ones in math books that describe (more or less vaguely) how Archimedes developed his oftenmentioned lower and upper bounds for pi:
The book 'Geometry from Euclid to Knots', by Saul Stahl (2003), pages 159162, has a clear discussion of the 2 sequences of numbers (nested square roots involving the integers 2 and 3) that Archimedes used to estimate the lower and upper bounds for pi. Stahl stops short of giving Archimedes' full argument. Stahl says "Using some complicated methods for the estimation of square roots by means of fractions", Archimedes arrived at the 2 bounds above. If I find some references that delineate those methods, I plan to add link(s) to such descriptions here. In the mean time, you can use this WEB SEARCH on keywords 'archimedes pi circle polygons circumference square roots' to look for information on how Archimedes approximated the square roots. (NOTE: This geometry book by Stahl is quite unusual in that the first chapter starts out with a description of 'spherical geometry' and 'hyperbolic geometry' before going on to Euclidean 'plane geometry'. Furthermore, Stahl devotes the 2nd chapter to deriving results in 'plane geometry' that do not require use of the 'parallel postulate'. The 3rd chapter invokes the parallel postulate.)
If you want more information on this subject, you can see Wikipedia pages on Archimedes and on Pi and on Approximations of Pi. And if you want more information on Archimedes and methods of calculating pi, you can do a WEB SEARCH on keywords like or
NOTE: (We are not 'cheating' with this 'app'.) Although we are using a computer and sine and cosine routines (which may seem like cheating compared to what Archimedes did, circa 287 to 212 BCE), this Tk script mimics the fact that back in the time of Hipparchus of Nicea (180 to 125 BCE) and Ptolemy (circa 100 AD to 170 AD) and in the early Middle Ages (when they had tables of chords and sines and cosines accurate to at least 5 decimal digits  for example, sine tables of Gersonides circa 1374 AD), those ancient mathematicians could have computed the circumferences of these polygons to much better accuracy than Archimedes achieved  by using their trigonometry tables instead of using squareroots, like Archimedes did. So, with this Tk script, we are just speeding up (by a factor of many thousands) the computations that mathematicians could perform many hundreds of years ago.
Basic Goals of the Tk Script: My purpose for this Tk GUI script is/was to generate a circle and 2 polygons in a square image area on the GUI. The drawings are to be done in a square image area in a Tk 'frame' widget. The GUI is to provide widgets by which the user could specify the important variables for drawing the circle and polygons:
Rather than using the common simplifying technique of using a circle of 'unit radius', this GUI is to allow the user to specify radii in a wide range  say, 0.1 to 300.0. I can remember back to my first geometry and algebra classes (when about 12 to 14 years old) wondering how can people be so sure that the ratio of the circle circumference to its diameter is the same no matter what the size of the circle. I was not told of the trick of imagining standing back from the circle at various distances  and the marks of a diameter (or equal divisions of a diameter) around the circle would not appear to change in their relative location. Even then, I would not feel that that was a 'rigorous' proof. It was more like a 'confirmation of plausibility'.
PLANNED LAYOUT OF THE GUI: As I have done with other Tk scripts that I have written in the past year or so, I laid out a 'text image' of the GUI  to aid me as I coded the frames and widgets. I used the following conventions to make the sketch, with a text editor. SQUAREBRACKETS indicate a comment (not to be placed on the GUI). BRACES indicate a Tk 'button' widget. A COLON indicates that the text before the colon is on a 'label' widget. <O> indicates a Tk 'scale' widget. CAPITALX indicates a Tk 'checkbutton' widget. CAPITALO indicates a Tk 'radiobutton' widget (if any). UNDERSCORES indicate a Tk 'entry' widget (if any). According to those conventions, I created the following 'text sketch'. FrameNames VVVVVVVVVV  tkCircleCircumferenceByPolygons [window title]  .fRbuttons {Exit} {Help} {ReDraw} {Backgd {Circle {Inscribed {Circumscribed Color} Color} Polygon Color} Polygon Color} 50 3000 .fRcontrols1 Image width&height (pixels): <O> Polygon to draw: X Inner X Outer 3 360 0.1 300.0 .fRcontrols2 Number of sides: <O> Radius: <O> .fRmsg [ .......... Message line  Calculated Circumferences are shown here .... ] .fRcanvas   A      'Canvas' for displaying the circle and polygons   in a square image area.         V <> Perhaps some aspects of the sketch could use a little more explanation: A LINE (HYPHENS or VERTICALBARS) WITH AN 'ARROWHEAD' AT EACH END indicates a Tk 'scale' widget  or a 'scrollbar' widget. A combination of VERTICALBAR CHARACTERS AND HYPHEN (or UNDERSCORE) CHARACTERS, that outline a RECTANGULAR SHAPE, are used to indicate either a Tk 'canvas' or a Tk 'listbox' widget or a Tk 'text' widget. SCROLLBAR 'ARROWHEADS' (for a 'canvas', 'listbox', or 'text' Tk widget) are drawn as follows: UP ARROWHEAD is drawn with a CAPITALA. DOWN ARROWHEAD is drawn with a CAPITALV. LEFT ARROWHEAD is drawn with a LESSTHAN sign. RIGHT ARROWHEAD is drawn with a GREATERTHAN sign. UPandDOWN ARROWHEADS at the right/left of a box shape indicate a VERTICAL SCROLLBAR there. LEFTandRIGHT ARROWHEADS at the bottom/top of a box shape indicate a HORIZONTAL SCROLLBAR there. The arrowheads on a horizontal scrollbar are joined by hyphens, rather than underscores. From the diagram above, I could see that this GUI will contain about: 7 'button' widgets 4 'label' widgets 3 'scale' widgets 1 'canvas' widget (with xy scrollbars) 2 'checkbutton' widgets 0 'radiobutton' widgets 0 'entry' widgets 0 'listbox' widgets 0 'text' widgets
Assembling the pieces (The GUI) Now it was a matter of putting the pieces together. I took 'codepieces' from some of my other Tk scripts that 'draw' in an image area on a Tk canvas. I ended up with the following GUI as an initial display.
Note that I have provided 4 color buttons on the GUI so that the user can control
I also provided several 'scale' widgets by which to control
I also provided a couple of 'checkbutton' widgets on the GUI by which the user can choose to draw the 'inner polygon', the 'outer polygon', both, or neither. By default, the GUI starts with both polygons drawn over the circle  and with hexagons for the two polygons. A message area in the middle of the GUI displays calculation results:
 Here is an image drawn after changing NumSides to 96 (like what Archimedes used) and increasing the size of the image area to 450 x 450 pixels  and after changing the radius from 50.0 to 137.7.
Before capturing this image, I changed the 'format' statements in the script that determine the number of decimal digits to display. Since I had room in the resultsmessage area, I changed from 6 digits to 8 digits. (You can change a 'decimalDIGITS' variable at the bottom of the script if you want to change this.) Execution time: The drawing and computations complete almost immediately after clicking on the 'ReDraw' button  even if you request hundreds of sides for the two polygons. Wouldn't Archimedes (and Galileo and Newton and Euler and the Bernoulli's and Gauss and Lagrange and Laplace and Weierstrass and Poincare and Riemann and ...) have loved to be able to use TclTk? I wonder what wonders Archimedes would have performed with the 'wish' interpreter at his disposal? Sure beats drawing in the sand. Changing the Radius (to confirm that pi is a constant, independent of circle size) The user can change the radius 'scale' widget repeatedly (and click on the 'ReDraw' button after each change) to see that the two ratios (polygon circumference to diameter) do not change. Of course, this could be predicted by careful examination of algebraic formulas that summarize how the calculations are performed. A radius factor in the numerator and denominator cancel out. Increasing the Number of Sides (a lot) The results we see with this tool suggest that we can 'squeeze down' to a unique number  called pi. (By examining the algebraic formulas for the two polygon circumferences, it should be provable that the difference between the two polygon circumferences goes to zero  and one is bounded above and always increasing, while the other is bounded below and always decreasing. So each sequence goes to a unique limit  the same limit.) Other changes to try: (to push the accuracy of the ratios to many decimal digits) You can change the NumSides to 360, so that the central angle of each sector of the polygons is exactly one degree. These polygons are almost indistinguishable from the circle. You will see that the errors are out at the 6th decimal digit. Five decimal digits is more than enough accuracy for most engineering work. A couple of quotes from a 2009 document 'Computing the Digits in Pi' by Carl Offner (University of Massachusetts, Boston): "I asked a civil engineer how many digits of pi he would actually ever need. After thinking about it for a while, he agreed with me that 5 was probably pushing it." "It requires ... 39 digits of pi in order to compute the circumference of a circle of radius 2 × 10 to the 25th meters (an upper bound on the distance traveled by a particle moving at the speed of light for 20 billion years, and as such an upper bound on the radius of the universe) with an error of less than 10 to the 12 meters (a lower bound for the radius of a hydrogen atom)." Borwein and Borwein (1984) "But what do astronomers and astrophysicists really need? I spoke to two recently. One had used whatever the pi key on her calculator produced  at most, 10 digits. The other thought that 7 or 8 places was the most he'd ever seen the need for. And even in quantum field theory, where there are physical constants that are known to an astounding accuracy of 12 or 13 decimal places, it wouldn't really help to know pi to any greater accuracy than that."
A computer engineering viewpoint: Scrollable Canvas (and big image area) Note that the canvas in the GUI has vertical and horizontal scrollbars  and you can set a large image area size with the imagesize scale widget. So you can set a very large image area in which to do the drawings. And if you think the maxpixels of the imagesize scale widget is not big enough for you, you can edit the Tk script and change the 'to' parameter on the 'scale' widget for the image size. Distance units You can think of the radius being specified in whatever units you want  feet, yards, meters, kilometers. Hence you can imagine drawing a huge circle on a big flat beach or a flat river delta  a circle with a radius of 100 meters or more. You pound a stake in the ground and attach a rope that is 100 meters long. Then you use the other end of the rope to 'scribe' a big circle on the beach. Then you see how many times you can measure off the rope distance (the radius) on that scribed circle. It should be twopi times ( 6.28... )  6 rope lengths plus a little more than a quarter of the rope. Implementing the Color Buttons The 2 color buttons call on an 'external' colorselectorGUI script to set those colors. You can make that colorselector script by cuttingandpasting the code from the page that offers a nonobfuscated color selector GUI on this site. You can see the code at the bottom of the Tk script to see how the name and location of the color selector script is set.
DESCRIPTION OF THE CODE Below, I provide the Tk script code for this 'tkCircleCircumferencesByPolygons' 'app'. I follow my usual 'canonical' structure for Tk code, for this Tk script:
0) Set general window & widget parms (winname, winposition, wincolorscheme, fonts, widgetgeometryparms, winsizecontrol). 1a) Define ALL frames (and subframes, if any). 1b) Pack ALL frames and subframes. 2) Define & pack all widgets in the frames, frame by frame. Within each frame, define ALL the widgets. Then pack the widgets. 3) Define keyboard and mouse/touchpad/touchsensitivescreen action BINDINGS, if needed. 4) Define PROCS, if needed. 5) Additional GUI initialization (typically with one or more of the procs), if needed.
This Tk coding structure is discussed in more detail on the page A Canonical Structure for Tk Code  and variations. This Tk coding structure makes it easy for me to find code sections  while generating and testing this script, and when looking for code snippets to include in other scripts (code reuse).
Experimenting with the GUI As in all my scripts that use the 'pack' geometry manager (which is all of my 100plus Tk scripts, so far), I provide the four main pack parameters  'side', 'anchor', 'fill', and 'expand'  on all the 'pack' commands for the frames and widgets. I think I have found a good setting of the 'side', 'anchor', 'fill', and 'expand' parameters on the 'pack' commands for the various widgets of this GUI. In particular ... The 'canvas' widget will expand/contract appropriately when an image size 'scale' widget value is changed  and button and label and scale widgets stay fixed in size and relativelocation as the window size changes. If anyone wants to change the way the GUI configures itself as the main window size is changed, they can experiment with the 'side', 'anchor', 'fill', and 'expand' parameters on the 'pack' commands for the various widgets  to get the widget behavior that they want.  Additional experimentation: You could change the fonts used for the various GUI widgets. For example, you could change 'weight' from 'bold' to 'normal'  or 'slant' from 'roman' to 'italic'. Or change font families. In fact, you may NEED to change the font families, because the families I used may not be available on your computer  and the default font that the 'wish' interpreter chooses may not be very pleasing. Furthermore, there are variables used to set geometry parameters of widgets  parameters such as borderwidths and padding. And you could change the 'relief' values for frames and widgets. Feel free to experiment with those 'appearance' parameters as well.
Some features of the code There are plenty of comments in the code to describe what most of the codesections are doing. The code 'comes together' in the 'Redraw' proc. See the comments in that proc to see how it is implemented. See the top of the 'PROCS' section for a list of the procs used in this Tk script. See comments in the procs for details on the purpose of each proc and for details on the methods by which each proc was implemented. Here is a quick overview of the procs  to give an idea of the 'guts' of this utility:
 setMappingVars_for_px2wc  called by the 'set_MappingVars_forImageSquare' proc below.  set_MappingVars_forImageSquare  called by the 'draw_*' procs below.  Xwc2px  called by the 'draw_*' procs below.  Ywc2px  called by the 'draw_*' procs below.  draw_circle  called by the 'Redraw' proc below.  draw_inner_polygon  called by the 'Redraw' proc below.  draw_outer_polygon  called by the 'Redraw' proc below.  Redraw  called by the 'ReDraw' button.  set_bkgd_color  called by the backgroundcolor button 'command'  set_circle_color  called by the circlecolor button 'command'  set_inscribed_color  called by the innerpolygoncolor button 'command'  set_circumscribed_color  called by the outerpolygoncolor button 'command'  update_button_colors  called by the 'set_*_color' procs and once in the 'Additional GUI Initialization section.  advise_user  called by the 'Redraw' proc  popup_msgVarWithScroll  called by 'Help' button
One thing that I discovered in testing a previouslycreated GUI is a 'trick' to make the GUI (in particular the 'canvas' area) resize nicely after a change to the imagesize via the imagesize scale widget. It turned out that the resizing would not occur after the tester (me) would resize the window by tugging on an edge or corner of the window. The resizing would occur nicely before that 'manual intervention' with the window manager. It turned out that a Tk 'wm' (window manager) command  namely wm geometry . {} can be used to restore the nice autoresizing of the canvas area around the image area. By some searches on wiki.tcl.tk (with terms like 'wm resize'), I found this 'trick' used on the page http://wiki.tcl.tk/10720 (weeEdit)  in the 'command' of a 'Resize window' button. In this code, the 'wm geometry . {}' statment was being used to resize a 'text' widget, not a 'canvas' widget. A search on 'wm geometry . {}' at wiki.tcl.tk revealed that this 'wm statement' was mentioned in a section titled 'word Wrap Via Tk Text Widget'  on the page http://wiki.tcl.tk/44 (Additional string functions)  with the comment 'Make sure the toplevel shrinks or expands to fit'. Thanks to 'D.McC' (David McClamrock) for revealing this technique to me. I have never seen this 'toplevel shrink/expand' technique  using 'wm geometry . {}'  mentioned in the TclTk books that I have used the most  the Eric FosterJohnson books and the Brent Welch books. But I did find mention of this capability in the original 1994 edition of the John Ousterhout TclTk book  on page 237  where it says: "If you would like to restore a window to its natural size, you can invoke 'wm geometry' with an empty geometry string: wm geometry . {} "This causes Tk to forget any size specified by the user or by 'wm geometry' so the window returns to its natural size." Apparently 'wm geometry . {}' can be used to cause Tk to signal the window manager to resize the toplevel window according to the widget sizes within the window  for example, after a user has 'manually' resized the toplevel window by 'tugging' on a window edge or corner.
To potential Tcler's (and to people who care about this planet) It is my hope that the copious comments in the code might help TclTk coding 'newbies' get started in making GUI's like this. Without the comments  especially in the 'draw_*' procs  the code might look even more cryptic than it already is. Without the comments, potential young Tcler's might be tempted to return to their iPhones and iPads and iPods  to look for videos of Greenland's (and New Zealand's and Argentina's and Canada's and Alaska's and ...) glaciers melting  and timelapse images of polar ice receding  and people reporting on receding caps on snowcapped mountains where they have lived for more than 50 years  and penguin colonies residing on mud where there used to be snow and ice  and beached walruses  and increasing evidence of drowning polar bears  and people on Pacific and Indian Ocean islands up to their ankles in water (unlike when they were kids) ... while Republicans like Ted Cruz and Newt Gingrich and George Bush and Marco Rubio and Sarah Palin and various lobbyists and hundreds (and thousands) of others deny that anything is different from back in the 1960's when they were growing up. Wake up, people. There are many, many thousands more petroleum gas flares, steam turbines, metal furnaces, manufacturing ovens, kilns, cars, planes, ships, home furnaces, and people (energyconsumers, forestburners, etc.) than there were in the 1950's and 1960's. (Just watch a few episodes of the TV show "How It's Made". There is an oven or foundry in almost every show. Most of those did not exist in the 1950's.) The morethan600 intensely burning oil wells in Kuwait, that burned for almost a year, in 1991, did not help. But, even worse, the gas flares from current oil exploration sites go on and on and on and on. I remember when they were all over south Texas when I was growing up in the 1950's. And they still go on in Texas  and South Dakota and other states  and areas around the world. The people who point to the occasional blizzard in the past few years as evidence against global warming are taking a very myopic view of the climate picture. Global warming started showing symptoms about 60 years ago (around 1940 to 1970  approximately 1955, to pick a year), and those symptoms have just now (around 2015) started getting clear enough to be undeniable to anyone who really looks around and exposes themselves to what is happening in many telltale parts of the Earth. Note that humans are burning up the fossil fuels (coal and petroleum) that have been stored underground for millions of years in the space of about 200 years. Doesn't this fact alone give you an inkling of what is going on? It's not birds, fish, nonhuman mammals, insects, bacteria, viruses, or plants that are putting huge amounts of heat energy into the Earth's atmosphere. Of all the living, reproducing things on Earth, it is only humans who are generating massive amounts of heat from potential energy that was generated thanks to the sun and stored underground over millions of years. Cows are not building coal fired power plants and drilling wells and flaring off the gas. Cows are not building air conditioners and gas furnaces. Cows are not living in air conditioned comfort  unless the humans who eat them choose to condition the cows' air. Perhaps all this heat accumulation is 'boiling off' the lighter gases of our atmosphere  oxygen before carbon dioxide  into outer space. Perhaps this is a factor in rising carbon dioxide levels. I have not seen any mention of scientists investigating this possibility, but it certainly seems plausible  and seems like a question that needs an answer. All these heatgenerators are growing in direct proportion to the human population  which is growing more than exponentially, as shown by plot images from two of the 'tkGooies' 'PLOTtools': andBye, bye, Greenland glaciers. Bye, bye, polar bears. Cruz and Gingrich and about 100 million other Republicans do not give a damn about you and dear Mother Earth. They won't care about this planet until the rising water gets their socks wet (and their vacationhome living rooms wet) and when their air conditioners can't keep up with the heat or are too costly to run  even with your tax dollars going into their pockets. Then they might look to some scientists and engineers and U.S. workers for help. Anyway, after you use your idevices to look around at what is happening to our planet, and after you express some outrage to your congresspeople over their headinthesand attitudes and counterproductive votes, I urge you to try some TclTk coding  to calm your nerves and take your mind off of a planet being degraded.
The Tk Script CODE
Here is a link to CODE for the Tk script With your web browser, you can 'rightclick' on this link  and in the menu that pops up, select an item like 'Save Link Target As ...'  to save this file to your local computer. Then you can rename the file to remove the '.txt' suffix. Make sure that you have execute permission set on the file  in order to execute the script. 
Some possible FUTURE ENHANCEMENTS There are quite a few enhancements that could be considered for this script, such as:
The bottom line here is that there are almost always nontrivial enhancements (or 'forks') that could be made to (or from) a Tk GUI 'app' like this. One advantage of this Tk script is that it is 'open' code  available to anyone for enhancement. So if you would like to take a different approach to approximating pi, you are welcome to take this code and build on it.
IN CONCLUSION As I have said on several other codedonation pages on this freedomenv.com site and on the Tclers' wiki at wiki.tcl.tk ... There's a lot to like about a utility that is 'free freedom'  that is, nocost and opensource so that you can modify/enhance/fix it without having to wait for someone else to do it for you (which may be never). A BIG THANK YOU to Ousterhout for starting TclTk, and a BIG THANK YOU to the TclTk developers and maintainers who have kept the simply MAHvelous 'wish' interpreter going. 
2016mar23 UPDATE  REPOSITIONING THE OUTER POLYGON The image of the inner and outer polygons (in many math books and web pages on Archimedes) is typically shown with the outerpolygon 'sectors' rotated from the innerpolygon sectors (by half of the polygonsectors' angle). That is the configuration of the 2 polygons that was used in the initial Tk script implementation, as seen in the drawings in the images above. However, this 'rotated' configuration does not show that the innerpolygon sectors fit exactly into the outerpolygon sectors. Such a 'fitted' configuration would emphasize that, clearly, the lengths of the linesegments of the outerpolygon are longer than the linesegments of the inner polygon  and thus that the circumference of the outerpolygon is always bigger than the circumference of the innerpolygon, for a given number of sides N. So I decided to add a 'checkbutton' widget to the top of the GUI, so that the user can draw the circle and 2 polygons with the 2 polygons aligned so that their corresponding sides are parallel. See the checkbutton  and the new drawing configuration  in the following image.
This drawing configuration shows very convincingly that the circumference of the outerpolygon is always bigger than the circumference of the inner polygon, for any given N. Furthermore, it makes it easier to show, mathematically, that the two circumferences converge to each other. Let us compare the length of the segments of the inner and outer polygons when the sectors 'coincide'. Let 'r' be the radius of the circle, and 'R' be the distance to the endpoints of the sides of the outerpolygon, from the center of the circle. Let N be the number of sides in the two polygons. Let ANG = 2*pi/N be the interior angle of the sectors. Let 'd' be the sidelengths of the innerpolygon. Let 'D' be the sidelengths of the outerpolygon. Then ... 1) d = 2 * r * sin(ANG/2) 2) D = 2 * R * sin(ANG/2) 3) A diagram of an outerpolygon sector and the definition of the cosine gives us the relation: r/R = cos(ANG/2) So R = r/cos(ANG/2) 4) Equation2 becomes D = 2 * r * sin(ANG/2)/cos(ANG/2) = 2 * r * tan(ANG/2) 5) Hence D  d = 2 * r * sin(ANG/2) * (1/cos(ANG/2)  1) So (D  d) approaches zero as ANG goes to zero. Note that because BOTH of the 2 factors on the far right go to zero as ANG goes to zero, the difference (D  d) goes to zero 'quadratically' (really fast) as ANG goes to zero. However, the question to be asked is: Does the difference in the CIRCUMFERENCES of the 2 polygons go to zero as ANG goes to zero?? The difference in circumferences, 'C' and 'c', say, is C  c = N*D  N*d = N * (D  d) = N * 2 * r * sin(ANG/2) * (1/cos(ANG/2)  1) where ANG = 2*pi/N. Note that as N is increasing, the last two factors are decreasing to zero. Some arguments using power series approximations to sin(ANG/2) show that sin(ANG/2) approaches ANG/2 as ANG goes to zero. So the N factor in front cancels with the N in the denominator of ANG = 2*pi/N  and we are left with some constants times (1/cos(ANG/2)  1), which goes to zero as ANG goes to zero. (This argument can be expressed even more rigorously  using the definitions and proof techniques that are used in math classes on limits of sequences of numbers. "For any given positive number 'epsilon', no matter how small, there exists an integer 'N', such that for all 'n' greater than 'N', etc. etc.") So ... YES ... (C  c) does go to zero as ANG goes to zero  and the two circumferences DO converge to the same number. That is, the upperlimit of the littlec's and the lowerlimit of the bigC's is the same number. (We are using here 'boundedness' theorems from math of numeric sequences:  An increasing sequence that is bounded above converges to a finite limit.  A decreasing sequence that is bounded below converges to a finite limit. We just showed above, fairly rigorously, by algebraic and trigonometric means, that the 2 limits must be the same number. In contrast, if we kept calculating the circumferences for larger and larger N, we could become more and more convinced that the two circumferences are approaching each other very closely  but the possiblity exists that the differences could 'level out' toward some very small number greater than zero. The argument above indicates, quite convincingly, that that will not happen.)  Note that whichever of the two 'rotated' positions you use for the outer polygon, all the results of computations for the circumferences and ratios and errors  in the 'results' area of the GUI  remain the same, for a given N. And the results are the same, for a given N, no matter the radius we choose for the circle  via the radius 'scale' widget on the GUI.
I have replaced the code at the CODElink above with the code that provides the rotatecheckbutton. 
Bottom of a web page for presenting
To return to a previously visited web page location, click on the
< Go to Top of Page, above. >
This code may someday be posted in a page on the Tcler's Wiki 
This FE web page was created 2016 Mar 16. 