# Possibility of reopening a question

Sometimes it happens that my questions get closed immediately after posting them, but then with a little effort and explaining they get opened again. I'm posting this in the hope that this will be the case for my latest question.

My question is the longest period iterating quine, which has been closed as a duplicate of Quit Whining, Start Quining!, because that question also involves iterating quines. However, I hope with a bit of effort I can convince 5 or more of you that despite the similar topic the challenges are really quite fundamentally different, and that my question is therefore worthy of being given a chance.

The "quit whining" challenge is a straight up . It has a spec, and the winner is the shortest program to meet the spec.

In contrast, my challenge is a based on optimising an objective function, subject to a restriction on code length. In that respect it is more similar to Paint Starry Night, objectively, in 1kB of code than it is to the supposed duplicate. This is by design. In fact, this new question is somewhat purer than the Starry Night one, because it boils down to something reminiscent of Scott Aaronson's who can name the bigger number?, but in code form. You could say (in quite a strong sense) that it's a busy beaver problem in disguise.

Again, this is by design. I've thought for a long time that a good busy beaver type question would be a neat thing to have on the site. The busy beaver problem is the kind of challenge I like: it sounds nice and simple, and it's easy to make progress at first, but then later on it turns out to be literally one of the hardest problems that exists. There's really no limit to the amount of cleverness that people can draw on to produce competitive answers.

So from a competition design perspective, the busy beaver problem would be a nice thing to base a challenge on. But the problem is, how do you convert the concept of steps taken by a Turing machine into something nice and language-agnostic, suitable for this site? Execution time wouldn't work in any practical sense and nothing else presented itself, so for a long time I gave up on the idea.

But then this past week I hit upon the idea of iterating quines. The nice thing about quines is that the iterations are really well-defined, in any language. And of course, quines are fun, and anything that adds fun is a bonus. (That is what we're here for, right?)

So I was happy to have had a thought that would finally let me implement my old idea. Of course the first thing I did was check through the previous question, and of course I noted that there was already one based on iterating quines. But after carefully examining it it was clear that this question wasn't designed to encourage the same deep mathematical reasoning as mine, and I was reasonably confident that although this might not be obvious to every reviewer straight away, at least there were enough other obvious differences (e.g. vs. ) that it wouldn't be leapt upon and closed prematurely.

So, I spent some time on a rainy Saturday to make the question seem clear and simple, and to have a low barrier to entry for initial participants. Because again, that's the kind of challenge I like. The kind that seems simple to start with, but then later on turns out to be really quite mathematically deep, and to require really very non-trivial solutions indeed. That's the kind of thing I find fun.

(As a concrete example, someone points out in the comments that it's easy to reach a score of 2^(2^64). But of course, I expected that score to be reached early on. The whole point of the challenge is that 2^(2^64) is a really, really small number compared to the busy beaver numbers, so there's a huge amount of space above that for more competitive answers to occupy.)

But of course, putting effort into making something look simple runs the risk that people will assume it is simple. I think that based on a casual read-through, it's too easy to get the feeling that this is kind of a bit different from the "stop whining" question, but not really that different. The differences are not immediately apparent, and while that is also by design, perhaps it is a design flaw, at least in terms of the practicality of having the challenge exist on this site, and so I'd appreciate pointers on how to avoid this situation in future.

So to be clear, I have two objectives in posting this:

1. That five kind souls (or one kind moderator) will read and understand what I wrote above, and cast reopen votes on my question;

2. That we can have a civil discussion about how to post deceptively simple questions, perhaps based on similar ideas to old questions that lack the same challenge structure, without them being closed. I'm here to have fun, and a conversation about how to do that effectively would be nice.

One thing I would prefer to avoid if I can though, is too much argument or discussion about whether my question really is a duplicate or not. I'm sorry, but that just isn't the kind of thing I find fun. If you think it should be closed, just wait until it's reopened (or not), and then cast a close vote if you must. That's how the system's supposed to work - let's not spoil our fun by fighting instead.

• "I've thought for a long time that a good busy beaver type question would be a neat thing to have on the site." Just for the record, we even have a busy-beaver tag. (Not saying, we can't have more busy beaver challenges. I've got a couple I'm planning to post myself in the future...) Aug 27 '16 at 13:27
• I haven't really formed an opinion on this specific case yet, but I've noticed that your challenges have seen a mixed reception in the past and I assume your own experience with posting them hasn't been all pleasant either. I just wanted you to know that I (and hopefully some others) do appreciate that you put a lot of thought into very well-specified challenges, but since you like to tiptoe the lines of our scope (or of what we consider duplicates) that can sometimes result in down- or close votes. Whichever way this one goes, I hope you do keep writing challenges and pushing the boundaries. Aug 27 '16 at 13:39
• One thing that might help improve your experience though would be sandboxing your challenges for a few days before posting them. That lets you get feedback for your idea before it's susceptible to closing and rep loss, and changes to the idea are still possible to make it more suitable (whereas changes once it's on main are often more cosmetic, because substantial changes after a challenge was posted are also frowned upon). Aug 27 '16 at 13:41
• Hi Martin. I wouldn't say exactly that I "like to tiptoe around the lines of [your] scope" but rather that I like to try new things, and that I'm often surprised that something I really thought would be in scope turns out not to be. I can understand people thinking my question sounds similar to the proposed duplicate, but I truly can't fathom their continuing to think so after my explanation in the comments. That's not hyperbole, I really mean I don't get it. It just feels like a solid impenetrable wall of un-logic. Aug 27 '16 at 14:12
• I definitely don't think that it's a duplicate of the one it's closed as a dupe of, but I'm less sure about the one Peter linked. I'm not convinced yet that there are viable approaches that are not based on "generate the largest number possible (likely as a base-256 string) and use it to modulo a counter" plus some overhead for the generalised quine you wrap around it. Aug 27 '16 at 14:15
• @MartinEnder well, part of the broader issue here is that in my view it should be the answers to the question that would convince you of that, rather than anything I say as the challenge poser, otherwise I would be spoiling the fun. But if the question is closed then there will be no answers and hence you will never be convinced. But in this case I can just give you the hint that the 10th busy beaver number is far greater than anything that would fit in a base-256 string, and 100 chars is more than enough to implement a 10 state Turing machine. Aug 27 '16 at 14:20
• An additional hint: I was very deliberate about making the 100 byte limit apply only to the initial program, and not to any of the other programs that get printed. If I did restrict all the programs to that length then the maximum possible score would be 2^800. If you were wondering where the infinite tape would come from in implementing a Turing machine using quines, there is your answer. Aug 27 '16 at 14:28
• sorry, my base-256 comment was a bit misleading. My point is that any busy beaver techniques will likely just generate a very large number, which is the exact same thing you'd do for the other challenge. It's just that here you use that number to reset a counter in your generalised quine whereas there you just output it. Aug 27 '16 at 14:31
• @MartinEnder well, a busy beaver function typically doesn't work by generating a huge number and then iterating over it. But I can see the point. They have a strong similarity. Maybe mine is different enough to be interesting, and maybe it isn't - I don't know how to tell, or what rules are used to determine this. It certainly seems to me there is far more difference between them than between two typical "output this parameterised ascii graphic" challenges, but I can understand others might have a different view. The main question in my mind is, what's really gained by not giving it a chance? Aug 27 '16 at 14:39
• (To be clear, I think it's a good thing that minor variations on challenges are generally allowed, that's how we converge on the good ones. I'm saying there should be more leeway for it when it comes to more 'unusual' challenges, not that we should have only one kolmogorov-complexity question.) Aug 27 '16 at 14:52
• I like your challenge. I think it has at least the potential to have solutions that cannot be beaten by trivial edits to solutions to past challenges, which makes me believe it is not a duplicate. I haven't voted to reopen, because I'm expecting a debate here on meta and I'd rather see that play out first that go into a cycle of closing and reopening. I'm also expecting reasons both ways here on meta that go over my head, so I want to read up and understand those before making a final decision. Aug 27 '16 at 16:47
• I'm not really a fan of busy-beaver type questions that allow any programming language to be used. Since the answers use far too much memory to ever run on a real computer, it becomes about writing not programs that can be executed by, e.g., a Python interpreter, but programs for some Platonic ideal of Python. I would rather see them with some tightly specified language that is well defined for arbitrarily large memory. Aug 28 '16 at 11:52
• @feersum I'm sympathetic to that view, but my understanding is that questions here are generally required to be language-agnostic. (I wonder if there's some way to make a challenge that's about writing a program to output a program in an idealised language, or something like that. I'll have to think about it.) Aug 28 '16 at 12:07

First and foremost, I agree with you that your challenge is not a duplicate of Quit Whining; Start Quining; the interesting part of your challenge – make the chain as long as possible while staying within a byte limit – is not covered at all by that challenge.

That being said, I think it's a duplicate of Largest Number Printable. While printing a large number and making a large quine cycle don't seem to be that related, a rather trivial modification to the accepted answer of that challenge would turn it into a valid submission and highly competitive submission to your challenge.

In GolfScript (which the accepted answer happens to use), you can straightforwardly turn

<code to generate huge number>


into

0{\)<code to generate huge number>%\'.~'}.~


which increments a counter modulo huge number, using the standard GolfScript quine. This produces an iterating quine with period huge number.

Likewise, any submissions to this challenge that beat the aforementioned modification of @PeterTaylor's lifetime of a worm would most likely also outscore that answer in the other challenge. I therefore see no value in leaving both challenges open simultaneously.

One thing I would prefer to avoid if I can though, is too much argument or discussion about whether my question really is a duplicate or not. I'm sorry, but that just isn't the kind of thing I find fun. If you think it should be closed, just wait until it's reopened (or not), and then cast a close vote if you must. That's how the system's supposed to work - let's not spoil our fun by fighting instead.

Forgive me for ignoring your request, but if you start a discussion on meta with the hopes of getting a question of yours reopened, we're going to have to discuss whether it should be reopened or not.

The alternative is not bringing this matter to meta in the first place, vote to reopen your own question (at the moment, this privilege is obtained with 250 reputation), and just let the community pile on four more reopen votes in case it agrees with you.

• I agree that what you propose would be a valid answer to my question, and I agree that the cycle length would be huge. However, I disagree that it would be a particularly competitive answer. Rather, it seems to me an easy "low hanging fruit" that would be quickly outcompeted by answers more closely tailored to the constraints of the problem. Those would, of course, have even more huge cycle lengths. The fact that it's easy to get moderately high scores has no real bearing on how much challenge will be involved in competing for the top place. Aug 28 '16 at 5:27
• Also: does GolfScript use unlimited precision integers? (Genuine question.) If not then the cycle length of your proposal will not be very long at all. I guess I should clarify that in the question - I will do so now. Aug 28 '16 at 5:31
• GolfScript uses Ruby's BigNum which,(afaik) supports integers up to 2^2^n, where n is the number of bits in a long. Memory is going to become an issue long before that. Aug 28 '16 at 6:11
• Ok, so I guess that would limit cycles using this method to around length 2^2^64. (Assuming infinite memory is OK - I already clarified the spec to make that explicit.) Also, would that code eventually loop back to exactly the original code, or is it more like a quine generator, outputting a quine with a long period rather than actually being one itself? If it's the latter I didn't intend that to be valid, so I'll update the spec to make that explicit as well. Aug 28 '16 at 6:59
• @Nathaniel it will loop back around to itself. As for our first comment, what both Dennis and I are trying to say is that if someone beats this approach then the resulting approach could still be easily turned into a program which produces a huge number equal to the cycle length. Aug 28 '16 at 8:03
• @MartinEnder technically, that's true of course, but not necessarily in less than 100 characters, which means that a competitive answer to my challenge could probably not be converted into a valid answer to the other challenge. I feel like you're imagining that this "generate a huge number and then iterate that many times" approach is the only way to solve the quine challenge I posted, but in fact it's only one way to approach it out of many others that are possible. Aug 28 '16 at 8:51
• @Nathaniel No that's not what I meant. I'm saying regardless of which approach you take it shouldn't be hard to ditch the quine part and count the cycles in order to generate a huge number. Aug 28 '16 at 9:45
• @MartinEnder yes, and I'm saying you won't necessarily be able to do that inside 100 characters, as required for it to be an answer to the other challenge. Aug 28 '16 at 9:46
• @Nathaniel I'll be genuinely impressed if you manage to implement any sort of computation in fewer bytes by doing it with a quine than without. But it's currently looking like that challenge is going to be reopened soon, so I guess we'll see if anyone manages to pull that off. Aug 28 '16 at 9:48
• @MartinEnder you might be right about that actually. In that case my challenge is probably strictly harder than the other one. Still, adding something extra to the challenge is no bad thing, at least in my opinion. Aug 28 '16 at 9:50