Untitled posts[]
I want to try to disassemble the program and figure out its value. Based on Meows' FGH comparison, it looks like it's at least on the tetrational array level. FB100Z • talk • contribs 00:18, March 11, 2013 (UTC)
Can we determine the order type of D(n)? Ikosarakt1 (talk ^ contribs) 12:38, April 3, 2013 (UTC)
- Calculus of constructions is incredibly strong system. Theoretically, we can do it with every function. Practically, I think we don't have notations able to comprehend that ordinal. LittlePeng9 (talk) 13:13, April 3, 2013 (UTC)
- I believe this is the fastest growing computable function ever defined, even faster than Bird's H(n). However, to comprehend its growth rate, I need to know first few terms of sequence. Do you know them? Ikosarakt1 (talk ^ contribs) 13:37, April 3, 2013 (UTC)
- This function seems to have pretty slow start. D(99) is roughly power tower of height 30000, so calculating values of D(1), D(2) should be easy with loader.c with modified return value. Slow start is due to how program checks statements in CoC - it looks at statements with binary value <n, so length is \(< log_2(n)\).
- I tried running program for different inputs in MS Visual C++. For D(<8) it returned negative values. I got D(8)=496 and D(9)=2031616. D(10) and larger cause stack overflow. LittlePeng9 (talk) 13:46, April 3, 2013 (UTC)
- I believe David Moews showed that D(99) >= E(30416) = 2^^30416. Note the greater than or equals sign - I think that D(99) is probably much greater than 2^^30416. I tried running the program using Gnu C, for some reason I got D(2) = 65536, D(4) = 496, D(5) = 2031616, and negative values for other values of n. LittlePeng9's results are probably more accurate.
- @Ikosarakt1: I believe we can do better than the Calculus of Constructions by diagonolizing over a strong set theory like ZFC. For example, we can let \(f(n) = \sum_1^n g_i(n)\), where \(g_i(n)\) is the \(i\)th provably recursive function of ZFC. To compute \(f(n)\), we can search through all proofs of ZFC until we find a proof that a certain recursive function is total, set \(g_1\) to that function, and evaluate \(g_1\) at \(n\). Then repeat the procedure until we find \(n\) different functions, and sum all of them at \(n\). The resulting \(f(n)\) should grow faster than \(D(n)\). Deedlit11 (talk) 02:49, April 5, 2013 (UTC)
- Your results probably are wrong, because, if I understand definition correctly, D is monotonic. I must admit I had to modify loader.c a bit, because Visual C++ doesn't handle two functions reffering to each other very well. If you ask, I had to directly compute Apply within Subst function. LittlePeng9 (talk) 13:05, April 5, 2013 (UTC)
- I ran the program for higher values, and I also got D(8) = 496 and D(9) = 2031616, with "Segmentation fault" for D(10) and above. I guess the program just doesn't work properly for n < 8. It's interesting, though, that you get the same values for D(4) and D(5) as for D(8) and D(9). Deedlit11 (talk) 00:40, April 6, 2013 (UTC)
BB(160;7) vs. Loader's number[]
to Deedlit11: I wrote that BB(160,7) more than Loader's number based on the your comment in LittlePeng's blog "Random Turing machines". Question of ikosarakt1: "Also notice that your machine is very probably not a busy beaver, so BB(160,7) can be incredibly large. So, is it true that BB(160,7)>>Loader's number?" Your answer: "@Ikosarakt1 Yes, I am pretty certain of it." Konkhra (talk) 05:08, May 6, 2013 (UTC)
- But we are not sure. It might be a case that my machine is best Busy Beaver (not probable, but still). If we could compute D(n) in reasonable number of states, we would be sure. LittlePeng9 (talk) 12:48, May 6, 2013 (UTC)
- Yeah, sorry for the confusion. My above answer was my personal opinion on the growth rate of the busy beaver (in fact, I believe that even BB(100,2) > Loader's number). But we shouldn't put it in the article unless we have proof that it is the case. Deedlit11 (talk) 22:34, May 6, 2013 (UTC)
Winner[]
Congratulations! Loader! Your number are larger the BIGG —Preceding unsigned comment added by 220.255.2.149 (talk • contribs)
- Again, why all the hate towards Hollom? FB100Z • talk • contribs 04:29, May 30, 2013 (UTC)
- No? This number is bottom the bigg in the list. 220.255.2.155 04:44, May 30, 2013 (UTC)
- It's only our best guess. -- ☁ I want more clouds! ⛅ 13:35, May 30, 2013 (UTC)
- Loader.c uses powerful and complex, but computable, system. I guess it is that large, though it still is guess. LittlePeng9 (talk) 18:29, May 30, 2013 (UTC)
- Would this make it greater than Meameamealokkapoowa Oompa?82.41.206.83 19:41, November 7, 2015 (UTC)
- Meameamealokkapoowa Oompa is not well-defined, so it can't be compared with other, well-defined numbers. LittlePeng9 (talk) 19:55, November 7, 2015 (UTC)
- Would this make it greater than Meameamealokkapoowa Oompa?82.41.206.83 19:41, November 7, 2015 (UTC)
- Loader.c uses powerful and complex, but computable, system. I guess it is that large, though it still is guess. LittlePeng9 (talk) 18:29, May 30, 2013 (UTC)
- It's only our best guess. -- ☁ I want more clouds! ⛅ 13:35, May 30, 2013 (UTC)
- No? This number is bottom the bigg in the list. 220.255.2.155 04:44, May 30, 2013 (UTC)
S function loses, still, because i see the SCG grows faster still, and the BIGG is below the SCG in the list. Jiawhien (talk) 11:20, May 31, 2013 (UTC)
- BIGG is impressive because it's based on an array notation, and it reaches pretty far (we think). I mean, Buchholz hydras and subcubic graphs are really cool, but array notations reaching that far would be truly glorious. FB100Z • talk • contribs 16:43, May 31, 2013 (UTC)
- I found that there exist two types of recursive functions: combinatorial (like SCG(n)) and explicit (like Bird's S(n)). The combinatorials are usually easy to define, but hard to solve. For example, proving even that \(n(3)\geq 64\) requires some effort, while value of S(3) can be quite easily in the FGH. Ikosarakt1 (talk ^ contribs) 19:25, May 31, 2013 (UTC)
More Readable Code[]
I've been working on making the code of the program a bit more readable (it couldn't really be any less readable in the original version). This is where I've got to (download link for txt file containing the code): loader_dot_c_readable_version.txt. This should make it a lot easier to analyse if you can actually see what it's doing! I've tested it for the values that actually work and I got the same as before the edit, so it should do the same thing.DrCeasium (talk) 18:45, June 1, 2013 (UTC)
- Do you really understand how D(n) evaluates? If yes, maybe you can explain it less formally? Ikosarakt1 (talk ^ contribs) 19:34, June 1, 2013 (UTC)
- Loader.c is actually standard, read-able program which was later mechanically compressed to 512-bit form. Here is full Loader's entry, containing every part of program, assembled one and compressed one, as well as README file being full explantation of how everything works. LittlePeng9 (talk) 19:55, June 1, 2013 (UTC)
Theta function extensions[]
We can define \(\theta_{\alpha+1}(0,\beta) = \theta_{\alpha}(\Omega_{\beta})\) and adopt the normal rules for theta function to higher order theta functions, then limit ordinal of all this will be the first alpha: \(\theta_{\alpha}(0) = \alpha\). Is there a chance that \(f_\alpha(n) \approx D(n)\)? Ikosarakt1 (talk ^ contribs) 13:19, June 18, 2013 (UTC)
Nope, no chance. _Much_ stronger ordinal notations have been defined without going near the ordinal for higher order arithmetic. Deedlit11 (talk) 23:40, June 18, 2013 (UTC)
Because the CoC can define second-order arithmetic, does that mean the proof-theoretic ordinal of CoC is larger than that of second-order arithmetic? --Ixfd64 (talk) 00:04, June 19, 2013 (UTC)
- I don't think "CoC can define second-order arithmetic" is quite right - what is true is that CoC can define all provably recursive functions of second-order arithmetic. Since a type theory like CoC is quite different from the usual set theories for which proof theoretic ordinals are defined, we may need a different definition of "proof theoretic ordinal" for type theories. However, what we are concerned with are the definable functions of CoC, and since this contains all provably recursive functions of higher order arithmetic, we need to surpass all provably recursive ordinals of higher ordinal arithmetic to get to the level of D(n). Deedlit11 (talk) 01:01, June 19, 2013 (UTC)
- Does that mean that its practically impossible to reach CoC level using an array notation or countable ordinal notation that uses only recursion and similar methods? DrCeasium (talk) 17:39, June 22, 2013 (UTC)
- Maybe the very, very sophicticated array notation with complex 100 rules or so, can reach it, but since we haven't the recursive notation for Loader's ordinal, I can't be sure. Ikosarakt1 (talk ^ contribs) 09:00, June 23, 2013 (UTC)
- It's not theoretically impossible, but professional mathematicians, who have stronger guiding principles to work with, have not been able to reach it, so I don't think it's likely that one of us will. Of course, if the notations become strong enough it may become difficult to tell. Deedlit11 (talk) 10:21, June 24, 2013 (UTC)
- It is so hard to understand. Ikosarakt1 (talk ^ contribs) 16:09, June 24, 2013 (UTC)
Values[]
I ran the program through manually for D(1), and I think the reason we,be been getting strange results is that even this is (just) overflowing the storage for an int: the way the pair function works is pretty powerful in comparison to the size of an int.
Another reason why it may be broken is that I can't see anywhere where accumulate is actually given a value, until it is defined as pair(some stuff,accumulate), either I'm too used to Java, or that won't work properly. DrCeasium (talk) 08:47, June 23, 2013 (UTC)
How high the max value of your int type? I guess that 2147483647. Ikosarakt1 (talk ^ contribs) 09:00, June 23, 2013 (UTC)
Using unsigned int we can reach 2^32-1, but by using unsigned long long int we can reach up to 2^64-1. LittlePeng9 (talk) 09:11, June 23, 2013 (UTC)
Just checked: I actually meant D(0) overflowed the int value, as it was at least 16 billion. D(1) was > 10^10^10, and I don't think there are any ints that big.
There is still the problem of the undefined accumulate, as that could probably change the output too. (This isn't just me with the undefined accumulate is it?) DrCeasium (talk) 10:12, June 23, 2013 (UTC)
Just ran the program in debug, and I found that D(0) just about worked and outputted 2013265921. D(1) had a final value of pair(1006632960,2013265921) = 2013265921*(2^(1006632960)).
Also, if D(k) just adds up all of the bit strings of binary value k or lower (assuming a bit string is a string of bits eg10110, and its binary value is its value in binary, in this case 2+4+16 = 22), that really doesn't sound that powerful, and even if instead of adding you just stick them on the end of each other, so for example 1011+1001 = 10111001, that still doesn't sound like 'biggest computable number ever' big. I'm not saying it's not the biggest computable number ever, but the description doesn't make it sound that big at all. DrCeasium (talk) 18:14, June 23, 2013 (UTC)
If I'm not mistaken Loader's program works like this: it takes lambda expression with value less than k, normalises it (reduces to normal form, which may be represented by large integer) and sums all these normalised forms. If we translate CoC to higher order logic, Loader explains how large approximately it gets: "Let N be the base 2 log of the argument of Derive. Suppose that Higher Order Arithmetic can prove a closed Sigma^0_1-arithemetic statment "Exists(x) phi(x)", with a proof not longer than N. Then "Derive(N)" returns a number larger than the smallest x such that phi(x)." LittlePeng9 (talk) 18:30, June 23, 2013 (UTC)
- Bun even first order arithmetic has level \(\omega_\omega^\text{CK}\), so how D(n) can be computable? Ikosarakt1 (talk ^ contribs) 18:34, June 23, 2013 (UTC)
- The uncomputable functions are strange, because they are, in a sense, computable, because we can work out the lower values by going through every possible start and applying intelligence, which would suggest that a sufficiently powerful, and almost intelligent computer could work them out too. In fact, it is easy to cycle through all possible start values for most of these things, the hard part is just picking out the infinities. Maybe this is just an uncomputable function without any infinities that need removing, and so is sort of computable. DrCeasium (talk) 18:58, June 23, 2013 (UTC)
- Uncomputable functions are uncomputable, no worry about it. But every finite subset of values is computable. In fact, given any finite ordered multiset of numbers {a1,a2,...,an} there is polynomial such that p(x)-ax. As far as Church-Turing thesis is true, we can't compute uncomputable function in finite time.
- Point with higher order logic in CoC is that CoC captures recursive part of HOL, by which I mean every provably recursive (i.e. computable) function in HOL is expressible in CoC. This is how Derive(n) is computable. LittlePeng9 (talk) 19:04, June 23, 2013 (UTC)
\(\Sigma(160) >\) Loader's number[]
Even though it seems reasonable, I haven't seen the proof for the statement above. Can anyone point me on that? Ikosarakt1 (talk ^ contribs) 19:02, September 26, 2013 (UTC)
We don't have a proof, this is a statement we once concluded to be very likely, while discussing my bound of BB(160,7)>>Bird's N. I think this should be deleted. LittlePeng9 (talk) 19:30, September 26, 2013 (UTC)
More Values[]
In the section above I found D(0) = 2013265921 and D(1) = \(2013265921 \cdot 2^{1006632960}\). Can we find more values. Also, I think we should put these values in the article. Wythagoras (talk) 16:05, October 20, 2013 (UTC)
Everyone can try to find these values. But I think there is something wrong here - if D(n) uses strings with binary values at most n, then only string for D(0) would be 0, which almost certainly codes no proof. Same goes with D(1). I did not analyse program carefully enough to be sure, but it sounds a bit silly that D(0) codes proof giving number about 2 billion. LittlePeng9 (talk) 16:30, October 20, 2013 (UTC)
- I'm also a bit skeptical about these values. I think the numbers obtained by Deedlit11 and LittlePeng9 are more accurate. --Ixfd64 (talk) 22:43, October 20, 2013 (UTC)
Programs[]
If CoC is indeed the programming language, then if we want to be sure that f(n) [<] D(n), we just write down the program for f(n) on CoC. Some sort of ruleset is presented here, but I can't extract even how to make f(n) = n+1 from such rules. Ikosarakt1 (talk ^ contribs) 05:48, June 24, 2014 (UTC)
- I wouldn't call CoC a programming language, but it still can be thought of as one. Creating "simple" functions in this system is, I believe, in principle the same as in full lambda calculus, except it's a bit more work to get types right (I'm not an expert though). LittlePeng9 (talk) 10:44, June 24, 2014 (UTC)
Date[]
What's the date of Bignum Bakeoff? Ikosarakt1 (talk ^ contribs) 12:25, July 12, 2014 (UTC)
- December 2001, source. LittlePeng9 (talk) 12:51, July 12, 2014 (UTC)
- More precisely, it began on Dec 10 and ended on Dec 31. -- ☁ I want more clouds! ⛅ 12:53, July 12, 2014 (UTC)
- Thanks. I wonder why it wasn't in the scope of googology until 2013. Ikosarakt1 (talk ^ contribs) 13:03, July 13, 2014 (UTC)
To vel! : Says the "List of googological Functions" page.
\(\ Antares.H \) 07:17, March 23, 2015 (UTC)
- Not quite, the list of googological functions page states that the function is lower-bounded by f_whatever(n) whereas the article states a specific growth rate. (To say nothing of the fact that the choice of fundamental sequence systems is not specified) -- vel! 08:02, March 23, 2015 (UTC)
- I believe we should suppose standard FS-es unless otherwise specified. Ikosarakt1 (talk ^ contribs) 09:24, March 23, 2015 (UTC)
- There are no "standard" FS's for ordinals that large, or at least I'm not aware of existence of such. LittlePeng9 (talk) 10:40, March 23, 2015 (UTC)
- In that case, I think it's fair to say that Loader's function is above all so-far defined functions in FGH. Ikosarakt1 (talk ^ contribs) 06:01, March 24, 2015 (UTC)
- FGH has been extended to \(\omega_1^\text{CK}\) and even further, so I guess it's too much to say that Loader's function beats all of it. LittlePeng9 (talk) 14:11, March 24, 2015 (UTC)
BB(106) isn't enough[]
I compiled loader.c and this is the output ASM file: http://pastebin.com/R1X24EM5
It takes 514 instructions in ASM, so I don't see how a busy-beaver with only 106 instructions could go faster than this. I think the value for which BB(n) start outgrowing D(n) is much higher than 106 =/ Fluoroantimonic Acid (talk) 07:39, June 29, 2015 (UTC)
- As I have told you on the chat, this isn't any kind of proof. I am willing to agree that 106 states (which amounts to 312, not 106 instructions of a TM) might not be enough, basing that just on the number of instructions compared to the ASM code tells us nothing. It might be the case that a TMs can use what they have in more effective way, so they can give larger outputs with less instructions. This is most likely the case for small number of instructions - I don't know how large input you can get with 14 instructions in ASM, but 14 instructions in TM are enough for \(10\uparrow\uparrow 5\). LittlePeng9 (talk) 07:55, June 29, 2015 (UTC)
- With 312 instructions, it's very likely that we can define Universal Turing machines... 109.94.79.14 14:20, November 8, 2015 (UTC)
- There are 2-color Turing machines with as few as 15 states, or 30 transitions. LittlePeng9 (talk) 14:42, November 8, 2015 (UTC)
Growth rate[]
How can \(D(n)\) grow so fast? Are there any lower bounds for it and can it be compared to the FGH?Boboris02 (talk) 09:55, October 30, 2016 (UTC)
What is the difference between Turing machines and C programs?
Loader's number and its properties[]
I factored the result numbers of Deedlit11 and LittlePeng9 and managed to get this:
D(8) = 496 = 16 * 31 = 2^^3 * 31;
D(9) = 2031616 = 65536 * 31 = 2^^4 * 31.
Conjecture 1: all following values of D function are divisible by 31 and result after dividing D(n) by 31 is some tetration of 2. Therefore, Loader's number ends in 6.
Conjecture 2: D(n) >= 2^^(n-5) * 31.
It would be interesting to compute D(10) and verify these conjectures. Tetramur (talk) 11:39, January 17, 2020 (UTC)
- If conjecture 1 is true, then that would imply that the last 20 digits of Loader's number are ...57,067,335,956,421,410,816. Assuming conjecture 2, D(10) > 31*2^^5 ~ 6.2109*10^19729, which would explain why that's where other users here ran into problems. Of course, there has been disagreement over the values of the D function (for instance, another user obtained 2013265921 or 15*2^27 + 1 as the value of D(0) and D(1) ~> 2^10^9. Allam948736 (talk) 22:22, January 17, 2020 (UTC)
Proposal[]
Well, this article includes so many unsourced descriptions. If nobody adds sources of them, then I will create a separated section for made-up descriptions from this wiki, because many people have ever believed those unsourced descriptions (and frequently claim that Loader's number is the strongest). Even if some of those descrition might occasionarily include correct facts, but this wiki is a place to collect sources, but not a place to irresponsibly spread personal studies without sources. We should be responsible for what we have written.
p-adic 04:54, 9 September 2021 (UTC)
- Well, Is there any proof of this number (D5(99)) is larger than other computable functions? ARsygo (talk) 05:24, 9 September 2021 (UTC)
- That is the point. People claim such statements as obvious facts or proved facts, but many of us have never seen the source. So, even if they are correct, we need an accessible reliable source. (If they are just made-up fakes, the situation is worse.)
- p-adic 05:36, 9 September 2021 (UTC)
- I have found that in the comments to the BIGNUM BAKEOFF, David Moews writes "It is possible to simulate the computation of D(99) and prove that D(99) >= E(30419)" (note that E(x)=\(2\uparrow\uparrow x\)). They also site the article "The Expressiveness of Simple and Second-Order Type Structures" by Fortune et al. for defining (and necessarily proving totality of) functions of strength \(f_{\varepsilon_0}\) in a subset of CoC (which is technically itself subset of the system used), and reason that \(f_{\varepsilon_0+\omega^3}(1000000)\) are overcomed. So it looks like this is where some of the claims of their values came from. Naruyoko (Talk) 10:59, 9 September 2021 (UTC)
- Thank you. I have several questions.
- > David Moews writes
- It does not imply that David Moews proved it, does it? Usually, such a statement just ensures "David Moews stated that it is possible to prove it but there is no written proof accessible up to now" or something like that. For example, many members in this wiki have ever said "it is easy to prove blah-blah" but it does not mean that they have ever proved the statement.
- > in a subset of CoC (which is technically itself subset of the system used)
- If I correctly understand, the relation between D and "diagonalisation of CoC" is also unsourced. Or is it obvious for you or other people who understand CoC?
- p-adic 11:14, 9 September 2021 (UTC)
- > It does not imply that David Moews proved it, does it?
- No, it does not. I am just pointing out the fact that he wrote it. For the value of D(99), it can be computed (though obviously not directly) in a reasonable amount of time; perhaps there is some test program. I was able to verify the value on my implementation of the functions (D(99)>\((2\uparrow)^{30417}8646911284551352321\). Though I have the exact value, it is too long to put it here), so I don't have a reason to believe otherwise.
- > the relation between D and "diagonalisation of CoC" is also unsourced.
- I think that's right. However, from what I read from this blog post, Loader's original program, and from messing around with it, I believe it is doing something in order of this (Encoding proofs using binary numbers and iterating through all of them up to a certain point).
- Naruyoko (Talk) 12:45, 9 September 2021 (UTC)
- > D(99)
- Perhaps I am misunderstanding what you wrote. In order to understand your intention, I write Japanese sentences and Google translation of them.
- Japanese: D(99)の計算プロセスが現実的な時間で実行可能ということを主張しているのですよね？ それならその値がテトレーションオーダーを超えてしまうのはおかしくないでしょうか？ またテストプログラムとなるよこさんの実装は、D関数と全く同じ動きをすることが想定されているという認識であってますか？ それともBBのテストプログラムのように、探索範囲を制限した亜種の実装でしょうか？
- Google translation: You insist that the calculation process of D (99) can be executed in a realistic time, right? In that case, isn't it strange that the value exceeds the titration order? Also, do you recognize that Yoko-san's implementation, which is a test program, is supposed to behave exactly the same as the D function? Or is it an implementation of a variant that limits the search range, such as the BB test program?
- (EDIT: Who is Yoko-san?)
- > CoC
- The actual issue is that this wiki is a place for collecting sources. I am not stating that the description is false, but am stating that we need to mark unsourced descriptions even if they are believed to be correct and warn the reader to notice the possibility that they are made-up by this wiki. If the method in the blog post is well-known to expert, then there should be a reliable source... What do you think about the descriptions? Should we keep them in the current way?
- p-adic 12:59, 9 September 2021 (UTC)
- > それならその値がテトレーションオーダーを超えてしまうのはおかしくないでしょうか？
- > isn't it strange that the value exceeds the titration order?
- Japanese: 正確には、D(99)の計算プロセスを数値型でないものに対応・変換させることで、機能を変えることなく計算量とデータ量を極めてへらすことで求めました。D関数で使われている値(整数型)は、一部の例外を除いて二分木としての機能を持ちます。圧縮前のプログラムではそのときTREEと書かれています。これは\((x,y)\leftrightarrow(2x+1)2^y\)と対応され、そのように置き換えるとなされている計算はすべて二分木に対する基本的な演算によって構成されます。また、変換式からも読み取れる通り、整数としては非常に大きな値となってもほとんどはそれほど大きくない木に変換されます。実際に(a=0のとき)D(99)は深さが3万ほど、葉の数は35万ほどの木となり、これを整数に変換しなおすことでD(99)を具体的に求めることができました。というわけで、私の実装はD関数と同等の動きをすることが想定されているということになります。
- English: To be more exact, I evaluated the value by mapping the numerical values and operations to some other values, conserving its functions while saving a lot in time and space complexities. In Loader's D function, almost all of the values of type integer act as binary trees. To note this, the type is written as TREE instead of int in the uncompressed program. They are mapped by \((x,y)\leftrightarrow(2x+1)2^y\), and by replacing the operations to those on trees, the expressions (as in those written in C) will be composed of basic operations on trees. Also, as it can be read from the mapping function, a very large value when represented as in integer would often translate to a much smaller binary tree. Accordingly, when D(99) is evaluated (provided a=0), it outputs a tree with a depth of around 30000 and contains about 350000 leaves, which can now be translated back to integers to obtain the value of D(99). In conclusion, I expect my implementation to behave equivalently to the D function.
- > > CoC
- I think I understand now. In that case, I think it makes sense to have some kind of precautions. As in a reliable source, I don't think there is one, especially specific to Loader's number. There should be some resources out there regarding CoC and its strength given its use outside of googology, however technically nobody proved that Loader's program functions as intended. Using the same implementation I used above, I was able to find that \(D(2.73122\times10^{468})>2\uparrow\uparrow2\uparrow\uparrow257\), which I posted to Discord. Maybe I could write something up to rigorously prove its correspondence to a bare system, but I don't think I have the capacity to do it.
- Naruyoko (Talk) 14:44, 9 September 2021 (UTC)
- Thank you for the details. So, could you correct the article and add the explanation on the current situation where we can write more bout citations? (Say, "David Moews has shown" should be replaced by "David Moews stated that he or she had shown ... but there is no accessible proof." Also, if you write a valid source of the actual proof, you can cite it. The same for other descriptions.)
- p-adic 22:31, 9 September 2021 (UTC)
- THANK YOU!!!! HMHMHM!!!!
- p-adic 06:25, 11 September 2021 (UTC)
- Someone worked out D(0),D(1),D(2),D(3) and D(9) on https://tieba.baidu.com/p/6279969685#/ Mika2005CN (talk) 22:54, 20 July 2023 (UTC)
I got an exact value of D(1)[]
#CompressedInt.py
class CompressedInt: # b*2^e+r
def __init__(self, b=0, e=0, r=0):
self.b = b
self.e = e
self.r = r
if self.b and not (self.e or self.r):
if isinstance(self.b, int) and (self.b not in (-1, 0, 1)):
u = self.b
depth = 0
cur_zero_len = 0
max_zero_len = 0
cur_one_len = 0
max_one_len = 0
final_zero_depth = 0
final_one_depth = 0
recent = 0
while u not in (0, -1):
if u & 1:
if recent == 0:
if cur_zero_len >= max_zero_len:
max_zero_len = cur_zero_len
final_zero_depth = depth
cur_zero_len = 0
recent = 1
cur_one_len += 1
else:
if recent == 1:
if cur_one_len >= max_one_len:
max_one_len = cur_one_len
final_one_depth = depth
cur_one_len = 0
recent = 0
cur_zero_len += 1
depth += 1
u = u >> 1
if cur_zero_len >= max_zero_len:
max_zero_len = cur_zero_len
final_zero_depth = depth
if cur_one_len >= max_one_len:
max_one_len = cur_one_len
final_one_depth = depth
if self.b > 0:
if max_zero_len > max_one_len: # ...000000000xxx...00000000...00xxx
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
elif max_zero_len == max_one_len:
if final_zero_depth > final_one_depth:
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
else:
self.r = self.b | (-1 << final_one_depth)
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
else: # ...000000000xxx...1111111111...11xxx
self.r = self.b | (-1 << final_one_depth)
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
else:
if max_zero_len > max_one_len: # ...111111111xxx...00000000...00xxx
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
elif max_zero_len == max_one_len:
if final_zero_depth > final_one_depth:
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
else:
self.r = self.b | (-(1 << final_one_depth))
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
else: # ...111111111xxx...11111111...11xxx
self.r = self.b | (-1 << final_one_depth)
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
if self.r and (not self.b): # (0,e,r)->(r,e,0)
self.b = self.r
self.e = 0
self.r = 0
if e and not (b or r): # (0,e,0)->(0,0,0)
self.e = 0
if isinstance(self.e,int) and (self.e < 0):
self.b = self.b >> (-self.e)
self.e = 0
if self.r and (not self.b): # (0,e,r)->(r,e,0)
self.b = self.r
self.e = 0
self.r = 0
if self.b and not (self.e or self.r):
if isinstance(self.b, int) and (self.b not in (-1, 0, 1)):
u = self.b
depth = 0
cur_zero_len = 0
max_zero_len = 0
cur_one_len = 0
max_one_len = 0
final_zero_depth = 0
final_one_depth = 0
recent = 0
while u not in (0, -1):
if u & 1:
if recent == 0:
if cur_zero_len >= max_zero_len:
max_zero_len = cur_zero_len
final_zero_depth = depth
cur_zero_len = 0
recent = 1
cur_one_len += 1
else:
if recent == 1:
if cur_one_len >= max_one_len:
max_one_len = cur_one_len
final_one_depth = depth
cur_one_len = 0
recent = 0
cur_zero_len += 1
depth += 1
u = u >> 1
if cur_zero_len >= max_zero_len:
max_zero_len = cur_zero_len
final_zero_depth = depth
if cur_one_len >= max_one_len:
max_one_len = cur_one_len
final_one_depth = depth
if self.b > 0:
if max_zero_len > max_one_len: # ...000000000xxx...00000000...00xxx
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
elif max_zero_len == max_one_len:
if final_zero_depth > final_one_depth:
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
else:
self.r = self.b | (-1 << final_one_depth)
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
else: # ...000000000xxx...1111111111...11xxx
self.r = self.b | (-1 << final_one_depth)
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
else:
if max_zero_len > max_one_len: # ...111111111xxx...00000000...00xxx
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
elif max_zero_len == max_one_len:
if final_zero_depth > final_one_depth:
self.r = self.b & ((1 << final_zero_depth) - 1)
self.b = self.b >> final_zero_depth
self.e = final_zero_depth
else:
self.r = self.b | (-(1 << final_one_depth))
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
else: # ...111111111xxx...11111111...11xxx
self.r = self.b | (-1 << final_one_depth)
self.b = (self.b >> final_one_depth)+1
self.e = final_one_depth
while (self.b not in (0, -1)) and (self.b % 2 == 0):
self.b = self.b >> 1
self.e = self.e + 1
if (self.e < (1 << 16)) and (abs(self.r) >> int(self.e)):
self.b += self.r >> self.e
self.r = self.r & ((1 << self.e)-1)
if isinstance(self.e, int) and (self.e < 0):
self.b = self.b >> (-self.e)
self.e = 0
if self.r and (not self.b): # (0,e,r)->(r,e,0)
self.b = self.r
self.e = 0
self.r = 0
def __str__(self):
b_str = ""
e_str = ""
r_str = ""
if (isinstance(self.b, int) and (self.b == 0)):
return "(0)"
elif (isinstance(self.b, int) and (self.b == 1)):
b_str = "("
elif (isinstance(self.b, int) and (self.b == -1)):
b_str = "(-"
else:
b_str = "("+str(self.b)+"*"
if (isinstance(self.e, int) and (self.e == 0)) or (isinstance(self.e, CompressedInt) and (self.e.b == 0) and (self.e.r == 0)):
return "("+str(self.b)+")"
else:
e_str = "2^"+str(self.e)
if (isinstance(self.r, int) and (self.r < 0)):
r_str = "-" + str(-self.r) + ")"
elif (isinstance(self.r, int) and (self.r == 0)) or (isinstance(self.r, CompressedInt) and (self.r.b == 0) and (self.r.r == 0)):
r_str = ")"
else:
r_str = "+" + str(self.r) + ")"
return b_str+e_str+r_str
def __int__(self):
return (int(self.b) << int(self.e)) + int(self.r)
def __mod__(self, other):
if other in (2, CompressedInt(1, 1, 0)):
if self.e == 0:
return self.b % 2+self.r % 2
else:
return self.r % 2
else:
int_ot = int(other)
be_rem = self.b % int_ot
base_num = 2
exp_num = self.e
while exp_num > 1 and base_num > 1:
if exp_num % 2:
be_rem = (be_rem * base_num) % int_ot
base_num = (base_num * base_num) % int_ot
exp_num = exp_num >> 1
be_rem = (be_rem * base_num) % int_ot
return (be_rem + self.r) % int_ot
def __eq__(self, other):
if isinstance(other, int):
other = CompressedInt(other)
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (1 << 16):
return int(self) == int(other)
else:
if self.b == other.b and self.e == other.e and self.r == other.r:
return True
else:
return False
def __bool__(self):
if self.b == 0 and self.r == 0:
return False
else:
return True
def __neg__(self):
return CompressedInt(-self.b, self.e, -self.r)
def __ne__(self, other):
return not (self == other)
def __gt__(self, other):
if isinstance(other, int):
other = CompressedInt(other)
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (1 << 16):
return int(self) > int(other)
else:
if isinstance(self.e, int) and isinstance(other.e, int) and max(self.e, other.e) < (1 << 16):
e_small = min(self.e, other.e)
index_self = self.b << (self.e-e_small)
index_other = other.b << (other.e-e_small)
if index_self > index_other:
return True
elif index_self == index_other:
return (self.b > other.b) or ((self.b == other.b) and (self.r > other.r))
else:
return False
else:
if isinstance(self.e, int):
self.e = CompressedInt(self.e)
if isinstance(other.e, int):
other.e = CompressedInt(other.e)
if self.e > other.e:
return True
elif self.e == other.e:
if self.b > self.b:
return True
elif self.b == self.b:
return self.r > self.r
else:
return False
else:
return False
def __ge__(self, other):
return (self == other) or (self > other)
def __lt__(self, other):
return not (self >= other)
def __le__(self, other):
return not (self > other)
def __invert__(self):
return CompressedInt(-self.b, self.e, -self.r-1)
def __and__(self, other):
if self < (1 << 63) and other < (1 << 63) and self > (-1 << 63) and other > (-1 << 63):
return int(self) & int(other)
if isinstance(self, CompressedInt) and isinstance(other, CompressedInt):
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (1 << 16):
e_small = min(self.e, other.e)
res_b = (self.b << (self.e - e_small)) & (other.b << (other.e - e_small))
res_r = self.r & other.r
return CompressedInt(res_b, e_small, res_r)
else:
if self.e > other.e:
return self.r & other.r
elif self.e == other.e:
return CompressedInt(self.b & other.b, other.e, self.r & other.r)
else:
return self.r & other.r
elif isinstance(self, CompressedInt) and isinstance(other, int):
return self.r & other
def __or__(self, other):
if self < (1 << 63) and other < (1 << 63) and self > (-1 << 63) and other > (-1 << 63):
return int(self) | int(other)
if isinstance(self, CompressedInt) and isinstance(other, CompressedInt):
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (1 << 16):
e_small = min(self.e, other.e)
res_b = (self.b << (self.e - e_small)) | (other.b << (other.e - e_small))
res_r = self.r | other.r
return CompressedInt(res_b, e_small, res_r)
else:
if self.e > other.e:
return CompressedInt(self.b, self.e, CompressedInt(other.b, other.e, self.r | other.r))
elif self.e == other.e:
return CompressedInt(self.b | other.b, other.e, self.r | other.r)
else:
return CompressedInt(other.b, other.e, CompressedInt(self.b, self.e, self.r | other.r))
elif isinstance(self, CompressedInt) and isinstance(other, int):
return Compressed(self.b, self.e, self.r | other)
def __xor__(self, other):
if self < (1 << 63) and other < (1 << 63) and self > (-1 << 63) and other > (-1 << 63):
return int(self) ^ int(other)
if isinstance(self, CompressedInt) and isinstance(other, CompressedInt):
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (1 << 16):
e_small = min(self.e, other.e)
res_b = (self.b << (self.e - e_small)) ^ (other.b << (other.e - e_small))
res_r = self.r ^ other.r
return CompressedInt(res_b, e_small, res_r)
else:
if self.e > other.e:
return CompressedInt(self.b, self.e, CompressedInt(other.b, other.e, self.r ^ other.r))
elif self.e == other.e:
return CompressedInt(self.b ^ other.b, other.e, self.r ^ other.r)
else:
return CompressedInt(other.b, other.e, CompressedInt(self.b, self.e, self.r ^ other.r))
elif isinstance(self, CompressedInt) and isinstance(other, int):
return Compressed(self.b, self.e, self.r ^ other)
def __add__(self, other):
if isinstance(other, int):
other = CompressedInt(other)
if isinstance(self.e, int) and isinstance(other.e, int):
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (1 << 16):
e_small = min(self.e, other.e)
res_b = (self.b << (self.e - e_small)) + (other.b << (other.e - e_small))
res_r = self.r + other.r
return CompressedInt(res_b, e_small, res_r)
else:
if self.e > other.e:
return CompressedInt(self.b, self.e, CompressedInt(other.b, other.e, self.r + other.r))
else:
return CompressedInt(other.b, other.e, CompressedInt(self.b, self.e, self.r + other.r))
else:
if self.e > other.e:
return CompressedInt(self.b, self.e, CompressedInt(other.b, other.e, self.r + other.r))
else:
return CompressedInt(other.b, other.e, CompressedInt(self.b, self.e, self.r + other.r))
def __sub__(self, other):
if isinstance(other, int):
other = CompressedInt(other)
if isinstance(self.e, int) and isinstance(other.e, int):
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (
1 << 16):
e_small = min(self.e, other.e)
res_b = (self.b << (self.e - e_small)) - (other.b << (other.e - e_small))
res_r = self.r - other.r
return CompressedInt(res_b, e_small, res_r)
else:
if self.e > other.e:
return CompressedInt(self.b, self.e, CompressedInt(-other.b, other.e, self.r - other.r))
else:
return CompressedInt(-other.b, other.e, CompressedInt(self.b, self.e, self.r - other.r))
else:
if self.e > other.e:
return CompressedInt(self.b, self.e, CompressedInt(-other.b, other.e, self.r - other.r))
else:
return CompressedInt(-other.b, other.e, CompressedInt(self.b, self.e, self.r - other.r))
def __mul__(self, other):
if isinstance(other, int):
other = CompressedInt(other)
if max(self.b, other.b) < (1 << 63) and min(self.b, other.b) > (-1 << 63) and max(self.e, other.e) < (1 << 16):
return CompressedInt(self.b*int(other), self.e, self.r*int(other))
else:
return CompressedInt(self.b * other.b, self.e + other.e, CompressedInt(self.r * other.b, other.e, CompressedInt(other.r * self.b, self.e, self.r * other.r)))
def __lshift__(self, other):
return CompressedInt(self.b, self.e + other, self.r >> other)
def __rshift__(self, other):
return CompressedInt(self.b, self.e - other, self.r >> other)
def __abs__(self):
if self >= CompressedInt(0, 0, 0):
return self
else:
return CompressedInt(-self.b, self.e, -self.r)
# Test2.py
import sys
sys.setrecursionlimit(2147483647)
from CompressedInt import CompressedInt
a=0
def P(x,c=0):
global r,a
if isinstance(x,int) and (x>>32)==0 and isinstance(c,int) and c<32:
print("P -->",x-~x<<c)
return x-~x<<c
else:
if isinstance(x,int):
print("P -->",CompressedInt(2*x+1, c, 0))
return CompressedInt(2*x+1, c, 0)
else:
print("P -->", CompressedInt(CompressedInt(x, 1, 1), c, 0))
return CompressedInt(CompressedInt(x, 1, 1), c, 0)
def Z(x):
global r,a
if isinstance(x,int):
r=0 if x%2 else 1+Z(x>>1)
print("Z -->",r)
return r
elif isinstance(x, CompressedInt):
print("Z -->",Z(x.r) if x.r else x.e)
return Z(x.r) if x.r else x.e
def L(x):
global r,a
if isinstance(x, int) and (x >> 32) == 0:
print("L -->",x>>1+Z(x))
return x>>1+Z(x)
else:
print("L -->", (x.r>>1+Z(x.r)) if x.r else x.b)
return (x.r>>1+Z(x.r)) if x.r else x.b
def S(x,c,t,u):
global r,a
f,d=L(u),r
print("S -->",A(S(x,c,t,L(d)),S(x,c,t,Z(d))) if f in (2,CompressedInt(1,1,0)) else P(f,P(S(x,c,t,L(d)),S(x+2,c,S(4,4-8,13,t),Z(d)))) if f<2 else u-(f>x)*c if f-x else t)
return A(S(x,c,t,L(d)),S(x,c,t,Z(d))) if f in (2,CompressedInt(1,1,0)) else P(f,P(S(x,c,t,L(d)),S(x+2,c,S(4,4-8,13,t),Z(d)))) if f<2 else u-(f>x)*c if f-x else t
def A(x,c=0):
global r,a
if isinstance(x, int) and (x >> 64) == 0 and isinstance(c, int) and c < 64:
print("A -->", 5<<P(x,c) if L(x)-1 else S(4,4,c,Z(r)))
return 5<<P(x,c) if L(x)-1 else S(4,4,c,Z(r))
else:
print("A -->", CompressedInt(5,P(x,c),0) if L(x)-1 else S(4,4,c,Z(r)))
return CompressedInt(5,P(x,c),0) if L(x)-1 else S(4,4,c,Z(r))
def vallist(x,c,t,u,a):
print("x =", x)
print("c =", c)
print("t =", t)
print("u =", u)
print("a =", a)
def D(x,c=0,t=7,u=14):
global r,a
if x:D(x-1)
x=x>>1
if ~x%2:
a=P(P(t,P(u,P(x,c))),a)
print(f"a =", a)
return a
d,f,x=L(L(D(x))),L(r),L(r)
print("d, f, x =",L(L(D(x))),L(r),L(r))
vallist(x, c, t, u, a)
if c-r:
if not(L(u)or(L(r)-f)):
x=x>>1
vallist(x, c, t, u, a)
if x%2:u=S(4,4,d,r);t=A(t,d)
print("u, t =", u, t)
vallist(x, c, t, u, a)
if f>>1:
x=x>>1
if x%2:c=P(d,c);t=S(4,4-8,13,t);u=S(4,4-8,13,u)
vallist(x, c, t, u, a)
print("u, t =", u, t)
if c:
x=x>>1
if x%2:
x=x>>1
q=~u&2|x%2
vallist(x, c, t, u, a)
if q:u=1<<P(L(u),u)
vallist(x, c, t, u, a)
t,c=P(u if q else q,P(L(c),t)),r
vallist(x, c, t, u, a)
x=x>>1
if u>>1&x%2:c=P(t,c);u=S(4,4-8,13,t);t=9
vallist(x, c, t, u, a)
print("u, t =", u, t)
final = D(x,c,t,u)
print(f"D({x},{c},{t},{u}) =",final)
return final
inputed=int(input("Your number is: "))
print(f"D({inputed}) =", D(inputed))
I used my CompressedInt class and modified code(Test2.py, modified from https://codegolf.stackexchange.com/a/197173)
/data/user/0/com.hipipal.qpy3/files/bin/qpython3-android5.sh /storage/emulated/0/py/.last_tmp.py && exit
orage/emulated/0/py/.last_tmp.py && exit <
Your number is: 1
P --> 1
P --> 58
P --> (15*2^58)
P --> (((2^4-1)*2^59+1))
a = (((2^4-1)*2^59+1))
P --> 1
P --> 58
P --> (15*2^58)
P --> (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))
a = (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))
D(1) = (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))
#[QPython] Press enter to exit ...
D(1)=(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))
But when calculating D(2), I get an segmentation fault
/data/user/0/com.hipipal.qpy3/files/bin/qpython3-android5.sh /storage/emulated/0/py/.last_tmp.py && exit
orage/emulated/0/py/.last_tmp.py && exit <
Your number is: 2
P --> 1
P --> 58
P --> (15*2^58)
P --> (((2^4-1)*2^59+1))
a = (((2^4-1)*2^59+1))
P --> 1
P --> 58
P --> (15*2^58)
P --> (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))
a = (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))
P --> 1
P --> 58
P --> (15*2^58)
P --> (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1))))
a = (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1))))
P --> 1
P --> 58
P --> (15*2^58)
P --> (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))))
a = (((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))))
L --> ((2^4-1)*2^59+1)
Z --> 0
L --> 0
Z --> 0
Segmentation fault
139|:/ $
Mika2005CN (talk) 15:39, 6 October 2024 (UTC)
Mika2005CN (talk) 16:00, 6 October 2024 (UTC)
D(1)=(((2^4-1)*2^59+1)*2^(((2^4-1)*2^59+1)))=8646911284551352321*2^8646911284551352321=9869...187425792(2602979666495323675 digits, about 2600000 trillion digits, it will take about 2.26 EiB or 2.6 EB)≈9.869...*10^2602979666495323674≈e2.6e18
Exact values of derive 0..5[]
Exact initial values of the function derive from https://codegolf.stackexchange.com/questions/176966/golf-a-number-bigger-than-loaders-number/274634#274634
derive 0 = 0^1 = 1
derive 1 = 1^3 = 1
derive 2 = 2^27 = 134217728
derive 3 = 3^2066242608
derive 4 = 4^247414087295344046339985076631418479092405781012737132134692026995766375938702232780800000000000000
derive 5 = 5^418704636727814634621376320694611031462772665125895370867301734738655024608766430243296268592829841824026355506445507518831688560865143242934410527807098504824766443579854901458097527810044993646611363245352300406635494470615551765637636779794278675080011075204246300990316873833629567294464317217056991950962272977522819271055872286367006568642979084006016273926522462214924861569349725008399292686638384718881122252281593713328075355874245624098259053493992489555450004305736588597101902868703151789141646214369876444595406780625870928961367367573099836898012004265913460437855541952734292000415822324086992662066161289081103648060130605661235643464682924302868467189362806118955607837547446887287806829956292277034465397155669409072723611273755091248553767454551248008239632626514977971944777402469386452360176752280260184017764156787798479268911582585737864031760197009583435543747920545533766714001071704686973803527923416210720318398710790575888114941207160676334491351163622205189170957226057051196398884574432923993558498689093189171399411320636956579237386587745579179028549015253286326953123782072038547963897377620862684886457831919942282776466983017896075833181867327575885325542577608584440989768585571201938493014430745962970016361687550968066026128412298000008856164307134617477737359270355531556600652384298275208452791183404638736842997596116018814516972852730864306321758682987333634979847421324931652617927537603477761561949120392178906974709950232366858905179161073154263253655378809432393901763567021000748852706221463341191005913106977884844226483500877449515888682634128826998167857725770427181140822992369671494767891509388177840672805992865669737768047477861664990269577232137113922242299918445619621910775051568739242041694618797908998437570352414623085213719152109776326298754385845575397173801386706292584653860187032789889567183611659529843331224655610951796730061882745241145459176080466851001495394320031300506737418844523300638443468188130943226872024236603474250692288655681794886967576986565653702456150350137578167796244560055213965059970553299815138661220613459741639282592674270521647898720879639970515700371535933598604698366916510948150017711298593744107777708320752016163734606970497782165940316687295619884108962393723217035536852388172234651030347949519646568466660137181228964357107719377159257038185405282513450629151291816969788673706720339460898924780672006869167330265583234390854397949965629764791412572979475496438496046002558350889280717337223809890828877956989503734886790784671652345450762851626292413301455981433865127709076463406076617162090495055438690530068359097012935027307496902409650261704564554849659628255940456801437989093997629376885225567345213974005487575884918635684231905736508676546966694814124894635780368458502511310639374673783017940933161607005814281881953445364757632162376328841311884764055761301703342723776211525935912383817264468938774815455696493335475124889023968405464049913508639262160727840703325529193597556701107362748661013577644494279649291924753595775874542073816969637673051288563142294619090283585971428922391615615093999037067003767798450957308476535055208049720838278464981534002117247396851143657541236377745945976885778985456116398266900237977651003952258964882835189412279692933151084651850200572067239787571803278462456350229376965403698386813627989856399154187549855977821685554907331437370138597437468648129424998976556158564481862937979720365425955332990933584138531874836921417380866421679845827532696885621865379426504590121566302238848617478176983453237563707215617229763492851912357768434185176361023905472486343710553675258914091826776971101185909408042537611430050868030362099122245393168816683451604111630979377375332282581198006811370862295091104136868583527122009975014669583380620799138124982276997751565871724348677918960485301017789607614055596217769179312929447662273628158806554551486759980507061788526365998513984006736807914905784321684592038379841078911296038376827041764843712139987772991457699100401830202665190576403819161954226173732939886404267253403233770925576505851743088110750896806354974942380479038864463201743254563426034524855186073346493111237919233567781837005127680000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
derive 6 = 6^<number_with_tens_of_millions_of_digits>
Can you show me your code? Mika2005CN (talk) 15:26, 13 October 2024 (UTC)
Just follow the "Haskell port" link from the codegolf.stackexchange webpage above to CoC.hs JohnTromp (talk) 16:07, 13 October 2024 (UTC)
And, what is your iteration? Is x0=8646911284551352321, and xN=2xN-18646911284551352321, and D0=x0, D1=x1, D2=x134217728? Mika2005CN (talk) 01:18, 14 October 2024 (UTC)
My program uses a function called derive which differs significantly from Loader's D(). Which is why the above 6 initial values look completely different. Only their growth rate is similar. JohnTromp (talk) 18:24, 19 October 2024 (UTC)