User talk:Sbiis Saibian

Welcome
Hi, welcome to ! Thanks for your edit to the User:Sbiis Saibian page.

Please leave a message on my talk page if I can help with anything! -- FB100Z (Talk) 05:14, January 12, 2013

I've finally decided to join the googology wiki. I see that there is an aweful lot of inactive members. Since this is basically the only social hub for large numbers, I figured I might as well join. -- Sbiis Saibian

Oh my! It's E100# himself! I want more clouds! 12:27, January 14, 2013 (UTC)

Hi, Cloudy176. I think this site was a great idea. It's a great place for googologist's to collaborate. It's also a great way to establish what's cannon, and catalog everything. It's difficult to keep track of all the various systems around and how they relate. I can't keep up with all the salad numbers people come up with on a daily basis, but even the more professional stuff is difficult to keep straight. Sbiis Saibian (talk) 15:34, January 14, 2013 (UTC)

Last digits of Mega
Hi, Sbiis Saibian.

I saw your article about Mega on your site and developed a better method than you used:

Firstly, consider \(256[3]_1\). It is \(256^{256} = 2^{2048} = ...30656\) Then \(256[3]_2 = (2^{2048})^{(2^{2048})} = 2^{2048 \times 2^{2048}} = 2^{2048 \times ...30656} = 2^{...83488}\)

Then we need to compute last digits of \(2^{83488}\). For this I suggest to drop \(2^{83488}\) into factors of "powers of powers" of 2: \(2^{83488} = 2^{65536} \times 2^{16384} \times 2^{1024} \times 2^{512} \times 2^{32} \). Find last digits of \(2^{2^n}\) by the following way:

Let stage 1 = 4 stage 2 = 16 stage 3 = 256

stage 4 = 65536

stage 5 = ...67296

stage 6 = ...51616

In general, we can obtain the last digits of "stage x" if we take last digits of "stage x-1" and square it.

Then \(2^{2^n}\) = stage n.

Therefore, we can get last digits of each factor of \(2^{83488}\) fairly easy, and hence, of \(2^{83488}\) (if we multiply them). Specifically, using this, I found that \(256[3]_2 = ...65056\)

Now look at \(256[3]_3 = (2^{...83488})^{(2^{...83488})} = (2^{...83488})^{...65056} = 2^{...83488 \times ...65056} = 2^{...33568}\). You can see the pattern. I showed it only at 5 digits, but as number of digits grows, number of calculations don't grows exponentially, and, if you still interested to find more digits of Mega, you can write the program based on my algorithm.

Ikosarakt1 (talk) 11:22, January 14, 2013 (UTC)

Hi, Ikosarakt1

I noticed your comment on this method on the Mega article talk page. It is an intriguing alternative, and I did actually attempt using it once on paper to obtain ...656 as the last 3 digits of Mega. However I'm not entirely sure this gets completely around the issues I encountered when trying to compute the last 14 digits of Mega. Since this method depends on squares, a table of squares needs to be constructed, and one needs to know how long it takes to return to the starting value. Unless this is known in advance you would actually need to carry out to Stage n, and that could well be impossible if n>E20. While the method works, it would still rely on the problem of memory vs. computation that I encountered. You can reduce the amount of computation by loading up the memory, but that can quickly get used up when we get to around 10-14 digits of accuracy, because of the very long cycle times. Even with my 3GB ram laptop, I wasn't able to get past 12 digits without overloading the memory. One can go the other extreme and compute everything, but every digit seems to increase the computation time about 5 fold, so that within just a few digits you go from minutes, to hours, to days, to weeks, to months of computation. At that point it becomes impractical for me to run the program that long. I would have to break it up into sessions, and the results would be difficult to verify.

None the less, I like your method, I might well try to implement it and see what benefits it offers. It was my intention to get more than 14 digits. I wanted to at least reach 16 digits which was the maximum I could achieve with my programs current configuration. I was originally going to run a program to get the 15th digit, but the way it was set up it was going to take me about a month to compute, broken up into nightly run sessions. I actually ran it for a night or two, but I stopped because I had thought of a better way that would reduce the run time considerably to perhaps a few days. I never got around to implementing it though.

When I get a chance to revisit the topic I'll see if I can get more digits. There might be a method to reduce the exponential run time, but even so it would still be problematic to reach 100 digits because of the limited data-types I have to work with. The largest integer I can use is a 64-bit integer which is still way too small (It would be roughly E19 I think). To get around that limitation I would have to write my own routine, probably in something like C#. I'm sure it can be done but I need to learn more programming first.

Keep Counting

Sincerely,

Sbiis Saibian (talk) 15:23, January 14, 2013 (UTC)

Now I created program which finds d digits of Mega. I found that the best way to operate very long numbers as strings. So I created functions: addition, multiplication with taking last d digits, compute last d digits of \(2^{2^n}\), compute last d digits of \(2^n\). If can also post full code if it necessary.

By this program, I reach 20 digits as well: Mega = ...49731993539660742656. Amazingly, It takes only about 40 minutes to calculate. These 20 digits is not a limit for this program, and I recently run it for obtain 30 digits. When I compute it, I'll tell you.

Ikosarakt1 (talk) 13:26, February 11, 2013 (UTC)

30 digits are reached: Mega = ...910112922449731993539660742656. Ikosarakt1 (talk) 15:55, February 11, 2013 (UTC)

The last 500 digits of Mega are:

6146012204572531578518642573646126803479402168065879078658624752476487\

2803902837976103376819650464339061415489976640723044576837710810075626\

3982195355801774063924007257742013488430294905857763290919346930985668\

8868217817416338344379863716514120701492959969787943943004677723133132\

5642730394610854006632923911301838502897561606601450696228009791206968\

1514011641515692019692265965864251890278286738700271908166330741936373\

8852401235410918111746805967171505714587704474989491011292244973199353\

9660742656

Took about 10 seconds on Mathematica. You guys are making things much harder than they need to be. Just use modular exponentiation.Deedlit11 (talk) 14:54, February 28, 2013 (UTC)

Deedlit, I used modular exponentiation, and computed 255 digits before you (see Talk:Mega), but... my string type is restricted to maximal length 255. Btw, thanks, you verified the trueness of that. Ikosarakt1 (talk) 15:01, February 28, 2013 (UTC)

Ah, I see. No biggee. Anyhow, since computing digits of the Mega is so easy, I would say the true challenge is finding more last digits of the Moser. We've found 4, and more could be found with a computer program to analyze all the patterns. Sbiis, are you up for the challenge? Deedlit11 (talk) 15:13, February 28, 2013 (UTC)

When I was working on the 14 digits of Mega, I found that my methods were very ad hoc. This is part of the reason I left off. I wanted to find more general methods and I wanted to understand what was going on with the "cycles" I was discovering. At some point I'm going to have to get back to the issue, and see how to get more digits of ''mega. How is it that you ''over came the cycle problem Ikosarakt1? As I understood it, without cycles, the calculation would become prohibitively long. At some point I will probably try and see how to get terminating digits for Moser, especially when it's time to write my own article on the number (I have one planned). Is it any more difficult to get digits for Moser than it is for mega?

Sbiis Saibian (talk) 15:24, February 28, 2013 (UTC)

Cycles aren't a problem - just evaluate the power using modular exponentiation. Perhaps you're thinking that a^b requires b-1 multiplications to evaluate - if that were the case, then computing the last 500 digits would take about 10^500 multiplications! So that certainly would be prohibitive. But you can do it much quicker by using a^(2b+1) = a^(2b) * a for odd exponents, and a^(2b) = a^b * a^b for even exponents. That reduces the number of multiplications to between log_2 b and 2 log_2 b, a much more palatable number. So modular exponentiation is quick, and since you just need to do it 256 times, it's faster than computing the last d digits of Graham's number for large d. One could do a million digits with an optimized program, I would think.

The Moser is a much different kettle of fish. The are umpteen exponentiations, so we can just crank it out like the Mega, and it doesn't stabilize like Graham's Number. So I suspect it could be a difficult intellectual challenge. (I suspect that in any case we're not going to get more than about 10 digits or so.) Deedlit11 (talk) 15:36, February 28, 2013 (UTC)

@Sbiis I actually improved my algorithm, using. Suppose we want to calculate d digits of \(2^{1000}\). Turn 1000 into binary form: 1111101000, initialize base=2 and result=1. Follow these rules until exponent becomes empty:


 * If the last symbol is 1, then multiply base by result and take d digits.
 * Square the base, take last d digits and remove last symbol in the exponent.

Below is the table that illustrates how to calculate last 8 digits of \(2^{1000}\).

That is, \(2^{1000}\) has last digits 68069376. You can verify it on that calculator. By the way, this calc is much more powerful than one which you commonly use. I recommend it. Ikosarakt1 (talk) 16:02, February 28, 2013 (UTC)

First digits of Mega
It seems creepy to think that leading digits of Mega (and other tetrational-class numbers) is unobtainable. Has anyone ideas to calculate them? Ikosarakt1 (talk) 17:22, February 28, 2013 (UTC)
 * Scientific notation: \(a^b = 10^{b \log_{10} a} = 10^{\text{frac}(b \log_{10} a) + \lfloor b \log_{10} a \rfloor} = 10^{\text{frac}(b \log_{10} a)} \times 10^{\lfloor b \log_{10} a \rfloor}\). The leading digit of \(a^b\) would be \(\lfloor 10^{\text{frac}(b \log_{10} a)} \rfloor\) if my calculations are correct.
 * I fear, however, that this will break down once we get to tetration. FB100Z &bull; talk &bull; contribs 18:19, February 28, 2013 (UTC)
 * The leading digits of \(^ba\) are therefore \(10^{\text{frac}(^{b - 1}a \log_{10} a)}\). The problem breaks down to finding \(^{b - 1}a \log_{10} a \pmod{1}\). Since \(\log_{10} a\) is irrational (otherwise the leading digit would be trivial to compute) and \(^{b - 1}a\) is gigantic, I fail to see any easy way out. FB100Z &bull; talk &bull; contribs 19:07, February 28, 2013 (UTC)

Thus, we need to calculate some arbitrary digits of irrational number. I know that exists, but works only with binary and hexadecimal digits, and has linear time complexity. We need to have methods with constant time complexity, and works with decimals. I hope that such algorithm is possible, but so far is unknown. Ikosarakt1 (talk) 21:23, February 28, 2013 (UTC)
 * Actually, we need to compute the fractional part of the product of a power tower and an irrational number.
 * I just noticed that \(^{b - 1}a \log a = {}^{b - 1}a \cdot a^{(\log \log a)/(\log a)} = a^{(\log \log a)/(\log a) + {}^{b - 2}a}\) and we might be able to compute that modulo 1, but I'm not very optimistic about it. FB100Z &bull; talk &bull; contribs 22:30, February 28, 2013 (UTC)


 * You guys are echoing my thoughts on the subject.  Computing arbitrary digits of an irrational number in constant time is impossible - if you solve a problem in constant time, there can only be finitely many computations over all inputs, and you will get a repeating sequence of digits, i.e. a rational number rather than an irrational number.  If the answer depends on the full value of the input, even reading in the input takes time O(log n).
 * Let's take a relatively small number like 2^^7.  As FB100Z has observed, computing the first digits of 2^^7 is equivalent to computing the fractional part of 2^^6 (log 2), which is equivalent to computing the binary digits of log 2 starting from the 2^^5 + 1st place.  This is completely unfeasible unless we have an algorithm that computes the nth binary digit of log 2 in time O(log n).  Mathematicians have been studying constants and how to compute them for centuries, and we have never found an algorithm like that.  The BBP algorithm was startling and remarkable, but as Ikosarakt1 noted, it's still a linear time algorithm.  Finding a logarithmic time algorithm for computing a constant would be a completely new level of startling, and I don't think it will happen, so I don't think we will ever compute the first digits of 2^^7.  And even if an O(log n) algorithm for computing log 2 were found, you would need an O(log log n) algorithm for 2^^8, an O(log log log n) algorithm for 2^^9 and so on.  You don't even have time to read the input!
 * Of course, there could be some crazy reason why log b is easier to compute at the b^^nth place, but I don't believe it.  Deedlit11 (talk) 22:47, February 28, 2013 (UTC)
 * *sob*
 * On the bright side, at least we know the leading digit of googolplex. FB100Z &bull; talk &bull; contribs 05:20, March 1, 2013 (UTC)

Nonetheless, maybe it is possible to discover an algorithm that works with O(log*n) (iterated logarithm of n) time, if constant time is so hard. It would solve this problem. Ikosarakt1 (talk) 10:03, March 1, 2013 (UTC)
 * But even then O(log n) is insufficient for really big power towers. FB100Z &bull; talk &bull; contribs 17:08, March 1, 2013 (UTC)

I mean log*n, not log(n). log*n is the of n, which is equal to number of applications of common logarithm that need to apply to n to obtain value less of equal than 1.

For example:

log*2=1, since log(2)<1.

log*4=1, since log(4)<1.

log*16=2, since log(log(16))<1.

log*65536=2, since log2(65536)<1.

log*265536=3, since log3(265536)<1.

Ikosarakt1 (talk) 17:15, March 1, 2013 (UTC)

Paper
A while ago I happened across a philosophical/metamathematical paper that may be of interest to you (and other GWikians): Warning Signs of a Possible Collapse of Contemporary Mathematics. It's certainly relevant to googology, and in particular our discussion on Talk:Xi function. FB100Z &bull; talk &bull; contribs 00:06, February 7, 2013 (UTC)

I find his lack of faith in the hyper-operators ... disturbing. Seriously though I gave it a preliminary read through and felt that some of the things said were similar to my own concerns with the infinite, but I only skimmed his closing argument. I'll have to give this a more thorough readthrough later Sbiis Saibian (talk) 20:15, February 8, 2013 (UTC)

HELP ME!!!
HELP!!! I was exploring your web page, and I fell into an infinite loop! I am stuck on the page, so please come and rescue me! &mdash; I want more clouds! 09:15, February 7, 2013 (UTC)

Delete "/infinite_numbers_infinitely" and you back to the normal list. Where the problem? Ikosarakt1 (talk) 09:24, February 7, 2013 (UTC)

lol, looks like you guys found my "secret page". That was just a joke to make a point: I like the open-ended philosophy over the Cantorian completion philosophy. As a kid I was actually of the latter philosophy, comfortable with the idea of treating "infinity" as a number, and even going so far as to imagine an "end" even to infinite numbers (I knew nothing of Cantorian transfinites, but I had very similiar ideas. At the time I thought my ideas about infinite infinities would probably be frowned upon by my teachers so I mostly kept them to myself). The problem with that idea, even as I understood it as a kid, was that if even infinite numbers could be represented by finite lengths (given the appropriate "scale"), and one could always zoom out "more" then how could there be a "last number" of any kind (finite or infinite). If any segment represented "zero" to the "Last infinity", then you could just imagine zooming out just a little more and discovering a larger infinity.

As an adult thinking of these ideas critically, rather than platonically and assuming they have meaning outside my head, I've come to the opposite conclusion. That the whole idea of a "last number" is antithetical to the idea of "infinity". It's just an example of a mathematician being "double minded" and wanting both "freedom" and "completeness" at the same time. You can't have both. Given the choice, I've chosen "freedom". I find this turns googology from an oppressive subject (I'm NEVER going to reach infinity, it's hopeless so why even bother), to an opportunity to explore without fear of bumping into any limitations (There is always more to discover... curiousity is the only driving force necessary, without some predetermined goal).

As to which view is "correct", it's basically a philosophical question, and one can certainly attempt to build mathematical systems based on either premise. However because I'm skeptical of "completed infinities", I'm sticking with the open-ended philosophy until completed infinities can be demonstrated to be conceptually sound (The God of philosophers can be thought of as a completed infinity, but again how can we know that?).

I suspect that I lose nothing by discarding completed infinities, because even if "infinity" or the "completed set of integers" doesn't exist, I see no reason why I couldn't construct an arbitrarily large finite subset of the integers. So what "numbers" have I really lost in the process. I could never name all the numbers to begin with, so the question as to whether they all exist as a completed whole seems purely speculative. I admit that it's splitting philosophical hairs trying to make a distinction between completed infinities and potential infinities, but I just find it difficult to imagine the "whole of infinity". The concept itself seems self-contradictory. That's my working philosophy for the site, if you couldn't tell from my jibes at infinity on my home page Sbiis Saibian (talk) 15:45, February 7, 2013 (UTC)

I think the better way to conceptualize infinity as a line, or 1-D world. 2 infinities is 2 lines, infinity^2 is a square (2-D world), infinity^3 is a cube (3-D world), etc. It makes more sense than suppose something like infinity^2+infinity+6 as a quantity instead of dimensions. Ikosarakt1 (talk) 12:00, February 8, 2013 (UTC)

That's pretty much what array spaces are : ) Sbiis Saibian (talk) 20:15, February 8, 2013 (UTC)

Is 1E+(1E+64) bigger than Thrugold? Jiawheinalt (talk) 09:09, February 28, 2013 (UTC)

Umm ... 1E+(1E+64) is really really small. It's only E64#2 < E100#2 = googolplex << E100#100 = grangol << E100#100#100 = E100##3 = greagol <<< E100##100 = gugold <<< E100###100 = throogol << E100###100##100 = ''thrugold. 1E+(1E+64) barely taps into the power of two-argument Hyper-E Notation! Sbiis Saibian (talk) 15:24, February 28, 2013 (UTC)''

Twin primes
In The Small Primes, you say "Primes seperated by 2 are known as twin primes, and it was proven that there are an infinite number of them." Where was it proven? Wikipedia, MathWorld, and the Prime Glossary all tell me it's an unsolved problem, but widely believed to be true. FB100Z &bull; talk &bull; contribs 21:12, March 25, 2013 (UTC)


 * Yes, it's a very famous conjecture known as the Twin Prime Conjecture. It is considered to be very difficult, perhaps out of reach of current understanding. If it were solved it would be huge news, you would definitely hear about it. Deedlit11 (talk) 04:20, March 26, 2013 (UTC)


 * At the time I was aware that the goldbach conjecture was unproven, but I thought that the twin prime conjecture was already proven. On the surface it seems like an innocent enough assertion, until you spend a few moments trying to come up with a proof for the "obvious".


 * Most of the material in Section I is from the sites early days and is very "out of date" now. I've been giving some thought to how Section I should be retooled. It also is rather "thin" in content (for example the orginal version of Section I only talked about 3 numeration systems: egyptian hieroglyphic numerals, roman numerals, and modern decimals). In the interm I'll correct the error, but honestly that whole article could do with a rewrite. I think an article on large primes somewhere on my site would be interesting and certainly relevant. Maybe I'll make that my next project. Right now however I'm working on a new article for Section III.


 * Sbiis Saibian (talk) 15:54, March 26, 2013 (UTC)

Make
Make a all 4.1 pages NOW! Aarex (talk)
 * He's probably busy in real life. Let's just wait. --I want more clouds! 23:48, April 1, 2013 (UTC)
 * Give the guy a break, his site's pretty cool anyway and we're not paying him for it. Go study metamathematics and try to beat Rayo(n) or something :P FB100Z &bull; talk &bull; contribs 04:42, April 2, 2013 (UTC)

Mega in the megagon
So, (anyone who got read this,) do you think that Megagon(mega) or mega in the megagon is bigger than godgahlah? $Jiawhein$\(a\)\(l\)\(t\) 12:31, April 11, 2013 (UTC)

Any number can be expressible (or upper-bounded) in Steinhaus-Moser notation can't get even close to godgahlah. Recall a[b]c as a in c b-gons. Godgahlah is larger than expressions like 2[2[2[2[2...[2[5]]...]]] (with 2[2[2[2[2...[2[5]]...]]] (with 2[2[2[5]]] []'s) []'s). The last number is actually around {3,5,1,2} in BEAF, while godgahlah is around {100,101,99,99,...,99,99,99} (98 99's) Ikosarakt1 (talk ^ contribs) 12:38, April 11, 2013 (UTC)