Boy was I confused, using both incorrect area and maximization formulæ! Taking a bunch of shortcuts, the only area polynomial consistent with Weisstein's published value(s) a ~ .726868±.000001 was this teensy little -478425365462547737405343343 - 3773041038347596515021000956 a + 5833707081723328603647313856 a^2 + 76143004877906320975709476552 a^3 - 23523528029439955698746202488 a^4 - 647330513128418259524157203072 a^5 + 10555168880874361068013425792 a^6 + 3078428637636379850280988117504 a^7 + 367361764236902187872898865664 a^8 - 9147034213711759916391887323136 a^9 - 2370238736752843325635609948160 a^10 + 17935820857956814364517526943744 a^11 + 8009206689639186621822611818496 a^12 - 23588130061203336356460301369344 a^13 - 16192270866005062836001824866304 a^14 + 20027080947914571766986403610624 a^15 + 20104198057699941048810876698624 a^16 - 9574865040443004381891485761536 a^17 - 15455347946546823025854527832064 a^18 + 1491865144134539091913264332800 a^19 + 7452392569346922858753860567040 a^20 + 680235061366055307103034146816 a^21 - 2358897389358876839124819509248 a^22 - 332708870397989105275274002432 a^23 + 601318123428810231261639475200 a^24 + 42551878829792132053254275072 a^25 - 148064818635686576530703515648 a^26 + 7175008161182179668028030976 a^27 + 30114159874526648530622218240 a^28 - 4631615507099121446555746304 a^29 - 5240302758882335722850746368 a^30 + 1917928307706587784371240960 a^31 + 335103297887714904283021312 a^32 - 282207246119748476170403840 a^33 + 29758395462703081578299392 a^34 + 17594041430635084655886336 a^35 - 5317091837915248694657024 a^36 + 90234644551552032833536 a^37 - 19803120195082488119296 a^38 - 7670386770149352931328 a^39 + 2605602600411474165760 a^40 + 442721857769029238784 a^41 + 147573952589676412928 a^42 (Maybe *this* was the Hitchhiker's question.) If x[0]=y[0]=0 is at 12 o'clock, {x[1] -> 0.4090922742540297144137223530196025702309789207193622270057`\ 28.701970206043647, x[3] -> 0.2621417199570122516947515442431989707074610037358454609006`\ 31.657645148109477, y[1] -> -0.\ 2237838646956895981631358594540368453100997531513295193292`28.\ 402113583161636, y[3] -> -0.\ 9650293874582158881693828064552254538651756132469738396802`33.\ 09068393231289, y[2] -> -0.\ 6403786761031722315576549599983641660781397743846746632412080350248417\ 6836919`55.57006165606416, a -> -0.7268684827516267668381865381035592037517221216088385406499389\ 05647615006833786233340127192157068`69.} The area is negative because I went around clockwise (duh!). On Tue, Jan 3, 2012 at 4:59 PM, Bill Gosper <billgosper@gmail.com> wrote:
On Tue, Jan 3, 2012 at 4:43 PM, Bill Gosper <billgosper@gmail.com> wrote:
I couldn't express in radicals the (decic) Hexagon coordinates (http://mathworld.wolfram.com/GrahamsBiggestLittleHexagon.html) so I N A I V E L Y sought the Octagon. As far as I can Google, the univariate polynomials have never been written. A few hours with Resultant and 8G suggests why. If the bottommost vertex lies at (0,-1), the equation for the next-bottommost is 0= an (apparently irreducible) polynomial of degree 1872 with leading coefficient ~
<braindamage censored in accordance with Byelorussian law>
Whoa, wrong root! There are thousands to choose from...
This polynomial is so huge that it's not even possible to guess it by PSLQing the numerical solution to a multivariate partial solution. Apparently, it was not even clear until last year which equations to solve, i.e. which chords are unit length. --rwg
42nd degree isn't huge, but this approach is still exceedingly difficult. I've had FindIntegerNullValue poop out on vectors this short. But the real problem is coming up with many digits of a in the first place. Multivariate FindRoot consistently finds close but bogus roots, of which there are an enormity. So I used Resultant to make huge but factorable univariate polynomials (having had bad times with Eliminate), and then called univariate NSolve. It only occurred to me just now to try multivariate NSolve, which actually seems to work. I suspect I'd've drowned in Cartesian products of bogus solution vectors. There were many solutions to the area polynomial with larger |a|. I suspect these, on back substitution, would produce illegal values for the other unknowns. Contemplating the thousands of possibilities, I ran out of endurance. All I did was eliminate coordinates until down to a single equation in a, y[2], and y[3], and then solve it along with D[a,y[2]]=D[a,y[3])=0. Resultant helpfully introduced spurious factors of degree 800, all brimming with solutions matching the true(?) one to three or more places. --rwg In case you want to join the chase, the initial system, after imposing the obvious symmetries, is merely {a + (1/2)*(2*x[3] + y[1] - 2*x[1]*y[2] + 2*x[3]*y[2] - y[3]), 1 - x[3]^2 - y[3]^2, 1 - (x[1] + x[3])^2 - (y[1] - y[3])^2, 1 - (1/2 + x[1])^2 - (y[1] - y[2])^2, 1 - (1/2 + x[1])^2 - (-y[1] + y[2])^2, 1 - (x[1] + x[3])^2 - (-y[1] + y[3])^2} Diagram: GraphData[{"BiggestLittlePolygon", 8}] Coordinates: FullForm[%] (three digits!)