5
\$\begingroup\$

The question largest number printable is broken in many ways: it has a huge number of source restrictions and a strange scoring function.

Many of the other largest number challenges are like this in one way or another.

I was wondering if we should create a canonical question that fits the modern conventions of this site: perhaps just "output the largest number possible within 100 bytes" with no constraints beyond standard loopholes.

| |
\$\endgroup\$
  • 1
    \$\begingroup\$ I think we should allow snippets and decrease the byte count to 50; that way we can make solutions testable while still allowing languages like Java. \$\endgroup\$ – Esolanging Fruit Jun 19 '17 at 7:30
  • 1
    \$\begingroup\$ @Challenger5 probably still impossible to test (e.g., in languages where Ackerman is a built-in) \$\endgroup\$ – k_g Jun 19 '17 at 7:31
  • \$\begingroup\$ You'd have to make it so the program will stop, otherwise while(true) print 1 \$\endgroup\$ – Okx Jun 19 '17 at 8:32
  • 1
    \$\begingroup\$ @Challenger5: I think either 100 or 256 would be more interesting than 50; there are plenty of interesting very-large-number-generating problems that probably can't be implemented in 50 bytes even in something like Jelly. \$\endgroup\$ – user62131 Jun 19 '17 at 10:35
  • 1
    \$\begingroup\$ I'd contend that any byte-count larger than about 32 will result in meta-code-bowling: that is, how many times can the language recursively call a function without terminating (i.e. who can make the biggest callstack). Slowest Growing Function basically dead-ended when answers hit the point where merely computing the size of the stack verged on impossible. I gave up after the interpreted size of the program exceeded 7*10^10^10^10^10^10^8.57 characters. \$\endgroup\$ – Draco18s no longer trusts SE Jun 20 '17 at 21:03
  • 2
    \$\begingroup\$ @Draco18s that's kind of the point of the question as I see it, create a function that has some interesting recursive or iterative behavior and uses that to output a large number \$\endgroup\$ – k_g Jun 20 '17 at 21:35
  • \$\begingroup\$ @k_g so how do you prove it? \$\endgroup\$ – Stephen Jun 22 '17 at 0:09
  • 2
    \$\begingroup\$ @StephenS proving it is half the work. But checking a proof should be easy \$\endgroup\$ – k_g Jun 22 '17 at 3:08
  • 3
    \$\begingroup\$ Instead of trying to guess the most interesting code length limit in advance, we could define the winners as everyone on the Pareto frontier of output size vs. code length, which effectively makes this a separate competition for each code length. Maintaining such a leaderboard might end up being too much work, though. \$\endgroup\$ – Anders Kaseorg Jun 22 '17 at 22:47
6
\$\begingroup\$

Write a new canonical one

As k_g suggests, let's sandbox and post a clean, modern largest number question without source restrictions and no score modifier. Then, let's close the old one as a dupe of it

| |
\$\endgroup\$
  • \$\begingroup\$ 1. Should "with source restrictions" say "without source restrictions"? 2. And do what with the answers to the existing question? \$\endgroup\$ – Peter Taylor Jun 23 '17 at 6:21
  • 2
    \$\begingroup\$ Yes, I meant without, thanks. I wouldn't do anything with the existing answers. I expect most answers will be different when they are allowed digits and arithmetic. If someone wants to copy over an existing answer or update it to the new spec (with credit if someone else's), I think that's OK. \$\endgroup\$ – xnor Jun 23 '17 at 6:37
1
\$\begingroup\$

Create the slowest growing function you can in under 100 bytes effectively functions as a largest number question, as per the comment:

An effective strategy is to write a fast-growing function and take its inverse, i.e. find the smallest input to it that produces at least the required value. Perhaps this is a dupe? – xnor Jun 8 at 18:59

It also lacks the source code restrictions etc.

| |
\$\endgroup\$
  • 3
    \$\begingroup\$ I guess it's kind of similar, but it also relies on inputs, requires the creation of a function, etc. \$\endgroup\$ – k_g Jun 20 '17 at 23:42
-4
\$\begingroup\$

I stumbled across this related question, which I'd forgotten about. I am sandboxing a proposed revision which doesn't remove all of the restrictions you don't like but does deal with one of them.

| |
\$\endgroup\$
  • 4
    \$\begingroup\$ It fixes one small issue, but unfortunately not all the other issues. If we want to fix this problem, I think we should fix it properly by getting rid of the somewhat arbitrary source restrictions \$\endgroup\$ – k_g Jun 21 '17 at 23:37
  • 6
    \$\begingroup\$ I would much rather a new challenge be written from scratch without the restrictions lest this cause better future largest-number challenges to be closed as dupes of it. \$\endgroup\$ – xnor Jun 22 '17 at 0:44
  • 1
    \$\begingroup\$ I agree with @xnor. We should simply post a new challenge with no source restrictions (beyond the length limit). \$\endgroup\$ – Gryphon Jun 22 '17 at 22:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .