# 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

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?