# Difference between revisions of "Talk:1292: Pi vs. Tau"

(sudden flash of realization) |
|||

Line 56: | Line 56: | ||

: A sudden flash of realization: are we getting nerd-sniped here?--[[Special:Contributions/108.162.254.168|108.162.254.168]] 11:55, 18 November 2013 (UTC) | : A sudden flash of realization: are we getting nerd-sniped here?--[[Special:Contributions/108.162.254.168|108.162.254.168]] 11:55, 18 November 2013 (UTC) | ||

+ | |||

+ | : The claim is clearly about e+2, making Dgbrt's comment closest to the right direction. [[Special:Contributions/173.245.54.40|173.245.54.40]] 12:03, 18 November 2013 (UTC) |

## Revision as of 12:03, 18 November 2013

I started an explanation. Hopefully others will help improve it, as I don't think it's quite adequate. 199.27.130.174 05:32, 18 November 2013 (UTC)

The comic currently shows the symbol π (pi) in all three cases, but it should have the symbol τ (tau) in the rightmost case. I'm sure there is a compromise symbol "pau" too. Maybe with a deformed left leg? 141.101.97.4 07:07, 18 November 2013 (UTC)

WolframAlpha gives

4.5545743763144164456766617143366171162404440766665105335330776311513504520604364524762740226212061363100001776216741750712622557020442741544760057441760026766230424023460366047331305225241275347777145543054127636365666430221066167347236617261603127725745513663702031155234027041040155322217227723576660045156156303357534162372112340027743775672417274565277274565735325624457113522164166560115654407251403563246444122664066521461311773474046032763760765740133706761276420415672577471077133607673035331070364705651055376634161405567176532346433567731715723623721267302576735154761375545411215522177775706407470673020025353246535120744232706060324711633457720155013202527060250466252665661576165164140301645132275526153126363575631176312270212441433434206352313125326760006365710744276056412434626534152021052065172556442150110056601034116570607064550553636566432544260105637423220411372664024454234201642615033200331506013362432026775605543212342336511350621361642654426372425415023071413764173735461042064323757413414533013..._8which does indeed have four 666 sequences. 141.101.99.254 08:06, 18 November 2013 (UTC)

This number contains 7777, 000 and 444 twice, though. 141.101.93.11 09:08, 18 November 2013 (UTC)

Wrote the transcript, not sure if I explained the visual well enough, so I left the incomplete tag if someone else has a better idea. Should suffice for understanding however, considering the content 108.162.248.18 08:55, 18 November 2013 (UTC)

(The discussion about different results was trimmed)

Wolfram gives the result with 666

http://www.wolframalpha.com/input/?i=1.5+pi+octal

4.554574376314416445676661714336617116240444076666510533533077631151350452060436452476274022621206136310000177621674175071262255702044274154476005744176002676623042402346036604733130522524127534777714554305412763636566643022

The Unix arbitrary precision calculator gives the result without

$ echo "scale=200; obase=8; 6*a(1)" | bc -l

4.554574376314416443236234514475050122425471573015650314763354527003043167712611655054674757031331252340351471657646433317273112431020107644727072362457372164022043765215506554422014311615574251563446213636251744101107770257

Any suggestions how we can check them?

"Randall says so" is probably correct, but insufficient :-) -- Mike (talk) *(please sign your comments with ~~~~)*

4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8 in decimaland

4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000_8 in decimalboth indicate the approximation is only accurate to a limited degree.

http://www.wolframalpha.com/input/?i=4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8+in+decimal http://www.wolframalpha.com/input/?i=4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8+in+decimal

The method I used to get the value I put in the text was; I used the following command to generate my approximation:

echo 'scale=200; obase=8; a(1) * 6' | bc -l | tr -d ' \\\n' ; echowhich outputs

4.554574376314416443236234514475050122425471573015650314763354527003043167712611655054674757031331252340351471657646433317273112431020107644727072362457372164022043765215506554422014311615574251563446213636251744101107770257

In 'bc*, a(1) is arctangent of 1 (i.e. 45 degrees, or pi/4); (pi/4 * 6) should be equal to 'pau'. I additionally checked the result using base 2 encoding, and converted each three bit binary value into an octal value. The decimal value of pi (using a(1) * 4) matches with the value of pi to at lease 1000 digits. *
173.245.54.86 09:21, 18 November 2013 (UTC)

Both Maxima and the GNU Emacs calculator output as the first 1000 octal digits:

4.5545743763144164432362345144750501224254715730156503147633545270030431677126116550546747570313312523403514716576464333172731124310201076447270723624573721640220437652155065544220143116155742515634462136362517441011077702611156024117447125224176203716336742057353303216470257662666744627534325504334506002730517102547504145216661211250027531716641276765735563341721214013553453654106045245066401141437740626707757305450703606440651111775270032710035521352101513622062164457304326450524432531652666626042202562202550566425643040556365710250031642467447605663240661743600041052212627767073277600402572027316222345356036301002572541750000114422036312122341474267232761775450071652613627306745074150251171507720277250030270442257106542456441722455345340370205646442156334125564557520336340223313312556634450170626417234376702443117031135045420165467426237454754566012204316130023063506430063362203021262434464410604275224606523356702572610031171344411766505734615256121034660773306140032365326415773227551

This also agrees with the first 220 digits of the previous result (last two digits above are 57 vs 61 here, maybe due to rounding when converting to octal). Again, no 666 within the first 200 digits. The Wolfram result deviates from this at the 18th digit already. --ulm (talk) 10:21, 18 November 2013 (UTC)

Also e+2 does not contain the substring '666':

echo "scale=200; obase=8; e(1) + 2" | bc -l

4.55760521305053551246527734254200471723636166134705407470551551265170233101050620637674622347347044466373713722774330661414353543664033100253542141365517370755272577262541110317650765740633550205306625--Dgbrt (talk) 10:43, 18 November 2013 (UTC)

- A sudden flash of realization: are we getting nerd-sniped here?--108.162.254.168 11:55, 18 November 2013 (UTC)

- The claim is clearly about e+2, making Dgbrt's comment closest to the right direction. 173.245.54.40 12:03, 18 November 2013 (UTC)