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

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
Line 150: Line 150:
 
And out of curiosity, what happened with [[287]] and floating point numbers?
 
And out of curiosity, what happened with [[287]] and floating point numbers?
 
The explainxkcd for 287 says nothing about floating point.
 
The explainxkcd for 287 says nothing about floating point.
 +
 +
[[Special:Contributions/173.245.53.145|173.245.53.145]] 22:09, 19 November 2013 (UTC)

Revision as of 22:09, 19 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..._8
which 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 ~~~~)

Please use the <pre> tag for this long numbers.--Dgbrt (talk) 09:20, 18 November 2013 (UTC)


Testing Wolfram Alpha with
4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8 in decimal
and
4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000_8 in decimal
both 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' ; echo
which 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)

When I take Wolfram alpha's octal(pi*1.5) I get the first 303 (base 10) characters as this:

4.554574376314416445676661714336617116240444076666510533533077631151350452060436452476274022621206136310000177621674175071262255702044274154476005744176002676623042402346036604733130522524127534777714554305412763636566643022106616734723661726160312772574551366370203115523402704104015532221722772357666

200(base 10) is 310(base 8) so in the fist '200' characters, 666 shows up 4 times (5 if you count 6666 as twice?) Xami (talk) 14:01, 18 November 2013 (UTC)

The Wolfram result is what you get when you calculate pi*3/2 in decimal, round to 14 digits after the decimal point and then convert to octal. That is, 4.7123889803846910 converted to octal. Definitely, this won't give you 200 digits precision. --ulm (talk) 15:15, 18 November 2013 (UTC)
It lines up too perfectly to be a coincidence. It fits all the requirements: has 666 four times within 2008 digits, and although 0000, 222, 444, and 7777 appear, they only appear once as a run. You can't double count 7777 as two 777's because it is a single run. If WolframAlpha doesn't give the correct precision, it is likely that Randall made the same error. --RainbowDash (talk) 16:59, 18 November 2013 (UTC)

Being τ, tau, is already being expressed in terms of π, pi, it shows bias. (Though I think Pau would lead to some interesting spherical geometry equations. ~~Drifter 108.162.219.214 (talk) (please sign your comments with ~~~~)

The bias is worse than that: From the perspective of π, the discussion is about multiples of π, so (3/2)π (that is 3π/2 = 3τ/4) is indeed the compromise between π and 2π. But from the perspective of τ, the discussion is about fractions of τ, so the compromise between τ and τ/2 is τ/(3/2) (that is 2τ/3 = 4π/3). Maybe we can call this ‘ti’ (or ‘tie’, pace 173.245.53.184 below). —TobyBartels (talk) 20:47, 18 November 2013 (UTC)

Actually, both compromises are wrong. (3/2)π is the arithmetic mean of π and τ, while τ/(3/2) is their harmonic mean. But for geometric ratios (which these are), the appropriate mean is generally the geometric mean (hence the name). You can see how even-handed this is: it's (√2)π = τ/(√2). —TobyBartels (talk) 20:50, 18 November 2013 (UTC)

---

I am in favour of just calling it ti(e). --173.245.53.184 17:52, 18 November 2013 (UTC)

---

There are real world uses to both Tau and Pi: Pi is the number that relates to what you get when you measure a circle (the distanced around divided by the distance across); and Tau is get when you draw a circle (the distance around divided by the distance from the center). It is the difference between a mic (aka "micrometer" http://en.wikipedia.org/wiki/Micrometer ) and a protractor. Tau might have some mathematical advantages in both 2D and 3D in that it has no integer attached to it to find either circumference (2D) or surface area (3D) which makes radians and solid angles simpler. However, that advantage is lost in other dimensions and for the area of a circle.

Pau, of course, has a 61% chance of going to the dribbling spheroid hall of fame. (ref: http://www.basketball-reference.com/players/g/gasolpa01.html ), to which neither Tau nor Pi can hold a candle.~~Remo ( 199.27.128.183 19:19, 18 November 2013 (UTC) )

---

The differences between Wolfram and BC really bothered me since I have used both for precision calculation in the past. The long and short of the matter, having done most of the maths 'long hand', BC is correct, Wolfram is wrong, and sadly, Randall was also wrong. It seems as tho Wolfram is rounding pi*1.5 to around 15 decimals but leaving the 9 repeating before converting to Octal.

If you take the output of octal(pi * 1.5) and paste it back into the input like so:

4.554574376314416445676661714336617116240444076666510533533077631151350452060436452476274022621206136310000177621674175071262255702044274154476005744176002676623042402346036604733130522524127534777_8

Wolfram gives you back (converted to decimal):

4.71238898038468999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

If you give that same input to BC and ask it to convert to decimal you get:

4.712388980384689999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999992894219160392567888

If you do the math long hand out to 55 decimal places, pi * 1.5 equals:

4.712388980384689857693965074919254326295754099062658731462416...

Converting that by hand into octal is a bit of a pain, but if you do, at the 18th decimal place where BC and Wolfram differ you end up with the following:

0.000000000000000183697019872102976583909889841150158731462416... is your remainder to be converted so far
0.000000000000000055511151231257827021181583404541015625          = 8 ^ -18

Wolfram gives the 18th decimal as 5, BC as 3. I can't see 5 going into 18 5 times, but 3 times fits nicely. --DarkJMKnight (talk) 20:04, 18 November 2013 (UTC)

Looks like Wolfram is simply using floating-point mathematics, presumably the IEEE "double precision". Interestingly, this is not the first time floating-point maths has been a problem; in 287, a similar problem caused an unintended trivial solution. Sabik (talk) 04:41, 19 November 2013 (UTC)

  • On second thoughts, there's no indication that he used Wolfram Alpha; as with 287, it simply could have been a Perl script (or Python or pretty much any programming language). Sabik (talk) 05:25, 19 November 2013 (UTC)

---

How can 200 be octal and then mean 310 decimal??? If 200 were octal, that would be 128 decimal, so we would end up writing 128 decimals. Of course 310 octal is 200 decimal, but taking 2008 to mean 31010 is plain crazy, even if it's the only way to make it fit the "four times 666" constraint! What am I missing here? 173.245.53.149 21:27, 18 November 2013 (UTC)

This Mathematica code searches for the pattern 666 in the octal expansion of 1.5 pi:

digits = RealDigits[3*Pi/2, 8, 10000][[1]]; Select[Range[10000 - 2], Take[digits, {#, # + 2}] == {6, 6, 6} &]
{279, 326, 495, 496, 3430, 3728, 4153, 6040, 7031, 7195, 7647, 7732, 8353, 8435, 8436, 8575, 8768, 9008}

These positions start counting with the leading "4" as position 1. It does not occur in the first 200 digits, but occurs 18 times in the first 10,000 digits. Many other digit combinations occur more times in the first 10,000 digits, including "123" (23 times), "222" (21 times), and "555" (26 times). Note that "xkcd" converted to numbers (a=1, b=2, etc.) is 24, 11, 3, 4. The combination 241134 first occurs in 1.5 pi at digit number 250,745. Dcoetzee (talk) 06:44, 19 November 2013 (UTC)

Wow, this filled up fast. Is it time to remove the Incomplete tag yet? 199.27.128.66 03:14, 19 November 2013 (UTC)

Please do your adds at the bottom. Otherwise it looks like as the first discussion here and everybody will ignore your comment.
My answer is: NO. We still have to figure out if Randall is wrong or just using an algorithm nobody does understand right now.--Dgbrt (talk) 21:10, 19 November 2013 (UTC)

---

Someone said there's no indication that Randall used Wolfram, and that double-precision IEEE numbers in mostly any language would cause the same error. This is not true: IEEE double precision numbers (binary64) are stored internally in binary. Converting them to octal would give at most 18 nonzero significant (octal) digits, and from that point on all additional digits would be zeros (remember that an octal digit is equivalent to three bits). What Wolfram does is rounding to a decimal number, which is not round in octal.

I think the previous is an indication that Randall did indeed use Wolfram. Added to that, he used Wolfram in several what-if's, and in one case he used it so heavily that his IP got temporarily banned from Wolfram. This leaves little or no doubts in me that Wolfram is the source of Randall's mistake.

Also, I still would like to know why everybody is interpreting "200 digits" as "2008 digits" and pretending that's equal to "31010 digits" instead of "12810 digits".

And out of curiosity, what happened with 287 and floating point numbers? The explainxkcd for 287 says nothing about floating point.

173.245.53.145 22:09, 19 November 2013 (UTC)