# Can we still ban built-ins for $\pi$?

I recently posed a challenge about computing a function of $$\\pi\$$. It was closed for being unclear and received a number of criticisms. One of the main ones I think was that banning built-ins for $$\\pi\$$ is not clear as there are always other equivalent built-ins one hasn't thought of.

Looking at old questions I see that banning built-ins for $$\\pi\$$ is quite common however. Take for example:

and so on.

# Edit

I have now changed the question to make it easier.

• To be clear, the first two questions you've linked there were closed due to being unclear (and then reopened). The 3rd one is so old that we don't recommend taking advice from back then. When you have non-observable requirements, you leave it up to opinions as to whether the question is clear or not. – Nathan Merrill May 22 '19 at 21:15
• The most recent post we've had about this did ban non-observables, but still allows built-ins, if I'm reading properly. As to whether "Pi" is a built-in in this scenario is up to the close voter's opinion. – Nathan Merrill May 22 '19 at 21:19
• To me, the main problem with that challenge is the fact that the digits must be output forever (that is, sequentially). As was commented there, that introduces an unnecessary complication. It would have been better to ask for the first n digits, n being an input – Luis Mendo May 22 '19 at 21:22
• What are you trying to achieve by banning built-ins for pi? The other questions have computing pi as the core of the challenge, so I can see them wanting to ban something the trivializes most of the task. But yours is about computing pi^(1/pi) to arbitrary precision -- do you think it's too easy to do this once you have pi? – xnor May 23 '19 at 1:18
• @xnor given that the mathmatica solution is essentially print(digit) for digit in scan_digits(pi^(1/pi)), I'd say yes, it quite obviously trivializes the question. – primo May 23 '19 at 10:51
• @primo I don't it is a good idea to mold challenges around whether one particular language trivialises them. I think the vast majority of languages used on this site could not produce such an answer. In my opinion the challenge is much better if you allow builtins and just accept that there will be a boring Mathematica answer. – FryAmTheEggman May 23 '19 at 18:43
• For me it is ok, only are few the languages has big float digits precision customizable (and I not see other way of build such function that would return pi^(1/pi) with n digit precision) – user58988 Jun 9 '19 at 4:47

# There are a few issues

One of them was the thing about banning built-ins for pi. On top of that, you also banned all trigonometric functions - sure, this is still reasonably well-defined and observable. However, you later also added that gamma was banned as well, after Luis Mendo mentioned that gamma(0.5) ** 2 can be used. How far from standard pi computational methods do you need to go before it's not disallowed by your rules? The current rules at any point are well-defined; however, as the rules are constantly changing, when will it stop?

Secondly, your output method is unusual, and forcing people to use that method doesn't actually make the challenge any more interesting, on top of making it impossible for some languages and adding an enormous penalty to others arbitrarily for no particular reason. Besides, with this method, you get arbitrary length precision error blocks (as mentioned by Stewie Griffin), which means that your output method actually doesn't even make sense given the computational requirement (as Shaggy brought up as well).

Finally, since you require infinite output, you need to give some assumption basis such as infinite memory or time (though the latter is obvious) as Stewie mentioned. This one is less significant since usually code-golf problems allow you to consume as much memory as you want as long as the solution is theoretically valid given infinite resources.

Also, to address your comment, nobody is hating on your challenge. To put it bluntly, if you can't write a clear challenge and it gets closed for being unclear, that's your own fault. Addressing close-voters as "haters" gets you nowhere in fixing your question and makes you look oversensitive and one who cannot take legitimate criticism. None of the comments are hating on either you or your post, all of them are asking legitimate questions or giving legitimate criticisms or suggestions regarding your question, which, for the reasons I've listed above, remain unclear.

• 1. A reasonable interpretation of the question, as written is "do no use any built-ins which trivialize the calculation." 2. I agree that output format should not have been restricted. I disagree with your analysis, entirely. What is requested is simply to not emit a newline between digits. 3. You counter your own point, why bring it up? 4. In my opinion, the challenge would have been fine tagged as a code-challenge, as is. – primo May 23 '19 at 11:28