# Output

Your code should compute and print (or return)
$$\\pi^y\$$ for all $$\y = \frac11, \frac12, \frac13, \frac14, \frac15, \frac16, \frac17, \frac18, \frac19, \frac1{10}, \frac1{11}, \frac1{12}\$$. The first 20 digits of the output (truncated and without any rounding) should be correct in each case.

3.1415926535897932384
1.7724538509055160272
1.4645918875615232630
1.3313353638003897127
1.2572741156691850593
1.2102032422537642759
1.1776640300231973966
1.1538350678499894305
1.1356352767378998683
1.1212823532318632987
1.1096740829646979321
1.1000923789635869829

• @Jitse Not if that is less than 20 digits. One point of this challenge is how to get a higher precision output than your language has built in. Which language are you using? – Anush Nov 4 at 10:52
• Ah, I see. I'm using Python 3, which gives ~15 decimals precision. But if the point of the challenge is explicitly to get a high precision value, then it's fine. It currently looks like just an arbirtrary cutoff. – Jitse Nov 4 at 10:56
• "One point of this challenge is how to get a higher precision output than your language has built in" so basically "use an obvious built-in" or "hardcode the effectively pseudorandom output" or "actually implement high precision math and inevitably lose the challenge anyway" depending on the language? Your previous question, posted yesterday, has already produced enough negative feedback in comments, and this one is even worse, with a higher precision requirement. – my pronoun is monicareinstate Nov 4 at 11:37
• @someone I would object that it's not that much of a problem for a kolmogorov-complexity challenge. Mathy languages are going to win here, just like Canvas or Charcoal are likely to win in 2D-based KC challenges. – Arnauld Nov 4 at 11:54
• I can't even represent 3.1415926535897932384 as a __float128. I get only 15 digits after the decimal. After that, there's divergence. The output from GCC is 3.14159265358979311599. Remember that IEEE 754 doesn't specify decimal precision: it specifies binary precision. These are very different things. – Cody Gray Nov 5 at 18:21

# JavaScript (ES7), 121 bytes

Computes as many digits as the precision of IEEE 754 allows and hardcodes the other ones.

_=>[32384,60272,2630,7127,[n=0]+593,2759,3966,4305,8683,2987,9321,69829].map(v=>(Math.PI**(1/++n)+'').slice(0,~(n==2))+v)


Try it online!

### Commented

_ =>                          // input is ignored
[ 32384, 60272, 2630, 7127,   // hard-coded digits for n=1 to n=4
[n = 0] + 593,              // initialize n to 0, and set this entry to '0593' (n=5)
2759, 3966, 4305, 8683,     // hard-coded digits for n=6 to n=9
2987, 9321, 69829           // hard-coded digits for n=10 to n=12
].map(v =>                    // for each entry in the above array:
(Math.PI ** (1 / ++n) + '') //   increment n; compute π**(1/n) and coerce it to a string
.slice(0, ~(n == 2))        //   remove the last 2 digits if n=2,
//   or only the last digit otherwise
+ v                         //   append the hard-coded digits
)                             // end of map()

• I see what you have done... very nice :) – Anush Nov 4 at 11:03
• Apologies.. the last digit of Pi in the example should have been a 4. – Anush Nov 4 at 11:13
• @Anush No worries. Updated. – Arnauld Nov 4 at 11:15
• Nice! I made a similar solution in C. – JL2210 Nov 7 at 15:51

# APL (Dyalog Extended), 9 8 bytesSBCS

(⍳12)√○1


Try it online! (⎕PP←34 is Print Precision: 34 digits; ⎕FR←1287 is Float Representation: 128-bit decimal)

○1$$\π×1\$$

()√ take the following roots of that:

⍳12ɩndices 1 through 12

• Shouldn't ⎕PP←34 and ⎕FR←1287 be part of the byte-count? – Kevin Cruijssen Nov 4 at 14:22
• @KevinCruijssen ⎕PP←34 certainly not, as it is just the print precision, not the actual precision of the returned (allowed by OP) value. ⎕FR←1287 can be set as a system default (so it doesn't need to be set by the programs), making it no worse than a "compiler" flag. – Adám Nov 4 at 15:00
• Ah ok, that makes sense. Thanks for clarifying. – Kevin Cruijssen Nov 4 at 15:03

# Bash + bc + coreutils, 51, 40, 39, 36 bytes

following @ChristianSievers comment |cut -c -21 could be removed.

-3 bytes thanks to @DigitalTrauma.

echo "e(l(4*a(1))/"{1..12}");"|bc -l


Try it online!

Some explanations

• bc -l define math functions and set scale to 20, see man bc for more details
• a() atan function, so 4*a(1) is pi
• e() exp function
• l() log function, so e(l(x)/y) is x^(1/y)
• Ahh... I am always very happy with a bash answer! Thank you. – Anush Nov 4 at 15:35
• Could you add some explanation please for the non-bc gurus here. – Anush Nov 4 at 16:09
• Untypically, this kolmogorov question doesn't demand some exact output, it only asks for 20 correct digits. So you can do without cut. – Christian Sievers Nov 4 at 16:27
• Or forget bash and just do it all in bc for 28: codegolf.stackexchange.com/a/195298/11259 – Digital Trauma Nov 4 at 19:28
• @DigitalTrauma, thanks for the solution, i didn't notice your first comment – Nahuel Fouilleul Nov 7 at 8:11

# Julia 1.0, 18 bytes

@.π^(1/big(1:12))


Try it online!

(1./big(1:12)) divides a BigInt 1 by each of 1 thru 12, then π.^ raises pi to each of those values. So long as there is one BigInt or BigFloat involved in each computation, it will calculate the result at that precision. The @. macro transforms the code to add dots to every function call (thus the dots that appear in my explanation that don't appear in the code snippet), this causes it to "broadcast" which for this purpose means do it all elementwise.

20->19 thanks to Robin Ryder

19->18 thanks to TimD

• Very glad for a Julia answer. I had no idea you could define BigFloats so compactly! – Anush Nov 4 at 16:38
• It seems that you can save 1 byte with big(1) instead of big(1.). – Robin Ryder Nov 4 at 22:44
• Thanks. I swear I tested that, but clearly left with the wrong answer. – gggg Nov 4 at 23:23
• @.π^(1/big(1:12)) Saves another byte – TimD Nov 5 at 15:00
• The current solution doesn't work as expected (it outputs π^n rather than π^(1/n)). TimD's suggestion, does however work for 18. – primo Nov 13 at 4:49

# Wolfram Language (Mathematica), 2220 19 bytes

-2 bytes thanks to game0ver -1 byte thanks to LegionMammal978

Pi^(111/Range@12)&


Try it online!

• This seems to calculate more precision than OP specified, and furthermore it rounds instead of truncates. I don't know Mathematica either so I don't know a good way of fixing this problem. – 79037662 Nov 4 at 16:04
• If you change ,20 inside N to e.g. 25 it will produce results that approach the OP's data in the 19th floating point digit. – game0ver Nov 4 at 20:12
• Also you can save two bytes by replacing range with [..] like that: N[Pi^(1/[1..12]),25], also PoC here. – game0ver Nov 4 at 20:16
• @game0ver Thank you! Is this syntax [x..y] for Range special for WolframAlpha? (It doesn't work in TIO, as well as in Wolfram Cloud) – Galen Ivanov Nov 5 at 7:21
• WolframAlpha syntax ≠ Wolfram Language syntax. The two are totally separate, and WolframAlpha doesn't have any notion of pure text output. Also, since snippets aren't valid, you'd want to end it with an & to make it a function. The precision can also be specified in the 1 constant. All of these create a 19-byte solution runnable on TIO: Pi^(111/Range@12)& – LegionMammal978 Nov 5 at 13:30

# 05AB1E (legacy), 4743 40 bytes

•u¬Œo¡õ≠ÎĆζw1Á4¼©éßw–xùó1O•5ôεžqN>zm16£ì


-7 bytes thanks to @Grimy.

Try it online.

Uses the legacy version, because for some reason the new version outputs $$\1.0\$$ for $$\\pi^{\frac{1}{1}}\$$.. :S

Explanation:

•u¬Œo¡õ≠ÎĆζw1Á4¼©éßw–xùó1O•
# Push compressed integer 323846027232630971275059342759739669430598683329877932169829
5ô          # Split it into parts of size 5:
#  [32384,60272,32630,97127,50593,42759,73966,94305,98683,32987,79321,69829]
ε            # Then map each integer to:
N>        #  Take the 0-based map-index, and increase it by 1
z       #  Calculate 1/(index+1)
žq   m      #  Then calculate PI the power of this
16£   #  Only leave the first 16 characters (including decimal dot)
ì  #  And prepend it before the current integer we're mapping
# (after which the mapped result is output implicitly)


See this 05AB1E tip of mine (sections How to compress large integers?) to understand why •u¬Œo¡õ≠ÎĆζw1Á4¼©éßw–xùó1O• is 323846027232630971275059342759739669430598683329877932169829.

• I really like this answer. It's very clever. – Anush Nov 4 at 15:06
• 43 by using 5ô instead of base compression. – Grimmy Nov 6 at 14:01
• @Grimmy Ah, didn't realize that would be shorter in this case. Should have known since they're all 5 digits.. Thanks! :) – Kevin Cruijssen Nov 6 at 14:26
• -3 from a simple inversion of the loop – Grimmy Nov 6 at 16:54
• @Grimmy Ah, smart. Thanks! – Kevin Cruijssen Nov 6 at 17:15

# Python 3, 6169 63 bytes

Variant of Jitse's answer, who wants to stick to standard libraries. As mentioned by @Seb & @Jitse, Rational or E/E are needed because 1/i isn't precise enough as float.

from sympy import*;i=E/E
while i<13:print(N(pi**(1/i),99));i+=1


Try it online!

As a bonus, sympy allows to output 99 decimals with the same byte count as for 20 decimals:

3.14159265358979323846264338327950288419716939937510582097494459230781640628620899862803482534211707
1.77245385090551602729816748334114518279754945612238712821380778985291128459103218137495065673854467
1.46459188756152326302014252726379039173859685562793717435725593713839364979828626614568206782035382
1.33133536380038971279753491795028085330936622381810425845370748286670076101723561496824589105670695
1.25727411566918505938452211411044829390616631003965817353418162262716270074393519788994784267497245
1.21020324225376427596603076175994353105276255513631810467305643780646240044814351479113420061960303
1.17766403002319739668470085583704641096763145003350008756991802723553566109741289228117335907046316
1.15383506784998943054096521314988190017738887987082462087415032873413337243208073328092932090341440
1.13563527673789986837981146453309184806238366027985302804182074656192075351096762716281170420998022
1.12128235323186329872203095522015520934269381296656043824699758762377264153679046528721553289724806
1.10967408296469793211291254568401340513968966612239757917494488030006513039871082996506101420959919
1.10009237896358698298222864697784031503277459309498017808547779493972810083028975298933600450861044

• sympy is cool :) – Anush Nov 5 at 9:19
• This output is incorrect for all lines after the second, from about the 16th digit. The Python float 1/i is preventing you from getting the precision you need. Replacing it with Rational(1,i) solves this issue at the cost of 8 bytes. – Seb Nov 5 at 12:49
• You can save the hassle with Rational by initiating i as E/E: Try it online! – Jitse Nov 5 at 13:24
• @Jitse Brilliant, wish I had thought of it. – Seb Nov 5 at 14:19
• Full credits to @flornquake for this trick. – Jitse Nov 5 at 14:20

# Python 3, 91 bytes

import fractions as f;p=f.Decimal('%s2384'%f.math.pi);i=p/p
while i<13:print(p**i**-1);i+=1


Try it online!

-23 bytes thanks to flornquake

• It doesn't quite give the right answer. Your first output ends 385 for example. In general, compare the last digits of your answers to the outputs in the question. – Anush Nov 4 at 11:07
• @Anush Pi starts as 3.14159265358979323846, so ~385 should be correct, no? You may want to check your examples. – Jitse Nov 4 at 11:09
• There was a mistake in the example but.. the spec says " The first 20 digits of the output should be correct in each case. The first 20 digits of the output should be correct in each case.". So the last digit should be 4. – Anush Nov 4 at 11:12
• @Anush I will argue that the first 20 digits are correct, since rounding is a proper way to cut off digits. If you don't allow rounding, please update your question to specifiy exactly what you want to want to see. – Jitse Nov 4 at 11:14
• @EricDuminil Thanks, but feel free to post it as a separate answer. I like to stick to the standard libraries. – Jitse Nov 5 at 7:57

# bc -l, 28

for(;i<12;)e(l(4*a(1))/++i)



Try it online!

# Ruby-rbigdecimal/math, 65 50 bytes

Conveniently, even though BigMath.PI(9) only guarantees precision up to 9 digits, it actually is precise up to 26, which is enough to calculate the exponents, which use the builtin Rational fractions instead of floats to ensure the precision is still good enough. (Also, making a Rational saves a byte over dividing it normally, since Ruby uses integer division if both arguments are integers, necessitating the use of 1.0 somewhere in the code.)

-15 bytes from histocrat!

1.upto(12){|i|puts BigMath.PI(9).**(1r/i).to_s ?F}


Try it online!

• Great to see Ruby here. I don’t know if it helps but you don’t need to truncate as long as the first 20 digits are correct. – Anush Nov 5 at 7:40

# Pari/GP, 20 bytes

vector(12,n,Pi^n^-1)


Try it online!

(TIO needs some supporting code, but this works as is in the REPL.

• Thank you. I was hoping you might be interested in my now-bountied question too. – Anush Nov 4 at 16:08

# R + Rmpfr, 80 bytes

Requires package Rmpfr.

mpfr("1.00000000238982476721842284052415179434",30 *log2(10))^(479001600/(1:12))


Gives the following, with truncations mine and some minor formatting

12 'mpfr' numbers of precision  99   bits
3.1415926535897932384...
1.7724538509055160272...
1.4645918875615232630...
1.3313353638003897127...
1.2572741156691850593...
1.2102032422537642759...
1.1776640300231973966...
1.1538350678499894305...
1.1356352767378998683...
1.1212823532318632987...
1.1096740829646979321...
1.1000923789635869829...


See below for why simpler versions don't work. Direct calculation using exponents 1/N for N=1,12 returned inaccurate value fairly early. I figured that was probably due to R or Rmpfr rounding 1/3 early, so whole number exponents would be preferred. So I calculated pi^(12!) (12!=479001600) using Mathematica, then raised it to the power of 12!/N, which would always be a whole number. I had to further tune it by passing the number to Rmpfr as a character vector (so R wouldn't round it), and by using an arbitrarily high precision in both Mathematica and Rmpfr so it would truncate accurately. Because of those arbitrary additions, I can probably shave off a few bytes, but I'm good with it as is.

# R, 29 bytes

This only works if R value for pi is accurate, which it isn't. Even reassigning the variable pi to a more accurate representation does not improve accuracy, as it rounds or something around 17 decimals.

format(pi^(1/1:12),nsmall=20)


Try it online

Or, for 30 bytes

options(digits=20);pi^(1/1:12)


There's a package that gives a more accurate value for pi and other floating point numbers, Rmpfr, which you'll find referenced in questions about pi in R. One might expect the following to give the desired output.

library(Rmpfr)
Const("pi",20 *log2(10))^(1/1:12)


It doesn't. It gives

12 'mpfr' numbers of precision  66   bits
[1] 3.1415926535897932385  1.7724538509055160273  1.464591887561523232
[4] 1.3313353638003897128 1.2572741156691850754 1.2102032422537642632
[7]  1.177664030023197386 1.1538350678499894305 1.1356352767378998604
[10] 1.1212823532318633058 1.1096740829646979353 1.1000923789635869772


This is wrong on all counts by rounding or being a few off in the last digits (sidenote: the rnd.mode flag for mpfr does not fix this). Now one might think if we went up to many digits (say 100), then it would surely be correct to the first 20 digits. Nope

12 'mpfr' numbers of precision  332   bits
[1] 3.1415926535897932384...
[2] 1.7724538509055160272...
[3] 1.4645918875615232319...
[4] 1.3313353638003897127...
[5] 1.2572741156691850753...
[6] 1.2102032422537642631...
[7] 1.1776640300231973859...
[8] 1.1538350678499894305...
[9] 1.1356352767378998603...
[10] 1.1212823532318633058...
[11] 1.1096740829646979353...
[12] 1.1000923789635869771...


(Truncations mine). These don't all match OP or the other responses.

• The output is not correct. Compare it with the output in the question. – Anush Nov 6 at 19:18
• @Anush I noticed that just now. Strange, it appears r's built-in pi constant is not precise to 20 decimals. – John Nov 6 at 19:22
• You might need Rmpfr. – Anush Nov 6 at 19:39
• @Anush Unfortunately, no. That gives a highly precise output for any arbitrary digits of pi, but once you start manipulating the number, it loses accuracy. For Const("pi",68)^(1/3) it gives 1.4645918875615232319, which is off. – John Nov 6 at 19:52
• Firstly, you need to list this as R + Rmpfr, since it doesn’t work on just base R. Secondly, the reason your first Rmpfr solution didn’t work is that you need the fractions to have sufficient accuracy. Try library(Rmpfr);Const("pi",70)^(mpfr(1,70)/1:12) rdrr.io/snippets/embed/… 47 bytes – Nick Kennedy Nov 6 at 22:50

# C (gcc -lm), 171131 122 bytes

Shaved off 40 49 bytes thanks to ceilingcat.

i;p(){for(;i<12;)printf("%.14f%d ",pow(acos(~fesetround(1024)),1./++i),L"纀罶𗭧얡꜇𒃮𗁡𘅻胛𓗙𑃅"[i]);}


Try it online!

Output:

3.1415926535897932384 1.7724538509055160272 1.4645918875615232630 1.3313353638003897127 1.2572741156691850593 1.2102032422537642759 1.1776640300231973966 1.1538350678499894305 1.1356352767378998683 1.1212823532318632987 1.1096740829646979321 1.1000923789635869829


# C (gcc) with libquadmath, 107

• 2 bytes saved thanks to @ceilingcat.

This uses __float128 to get the required precision.

#import<quadmath.h>


Try it online!

I was curious to try this using the GNU MPFR library too:

# C (gcc) with libmpfr, 123

• 13 bytes saved thanks to @ceilingcat.
#include<mpfr.h>
i;main(){MPFR_DECL_INIT(p,99);for(;i<12;){mpfr_const_pi(p,99);mpfr_root(p,p,++i,MPFR_RNDN);mpfr_printf("%.19Rf\n",p);}}


Try it online!

• Really pleased to see a C answer! – Anush Nov 7 at 17:43
• Nice one with libquadmath. Now there's two C solutions that technically count as different languages. – JL2210 Nov 7 at 20:40
• Could you link to an HTML version of that doc so it can be viewed on mobile more easily? – JL2210 Nov 7 at 20:42
• The libmpfr solution can be fixed by just changing .19 to .21. There is no need to truncate the answer yourself. (The rounding is not down. That's why the second line was outputted as 273 instead of 272.) – Anush Nov 7 at 20:46
• libquadmath 107 bytes; mpfr 123 bytes – ceilingcat Nov 8 at 2:45

# Canvas, 30 bytes

６«｛“≥αｙＨT.─Ｃ¹„1.0000ŗ┤“^m„┘÷＾］


Don't try it here! It'll take a while to calculate all those digits (it took ~15 minutes to run for me). Rather, here's a version of the same code, only outputting the last 3 items.

Computes C ^ (27720/N) where C is the hard-coded constant pi^(1/27720) = 1.000041297024626834690309 and N is looped over from 1 to 12. The big number library decided to expand the amount of significant digits for successively bigger N, making the code take unreasonable amounts of time to run.

# cQuents, 268 bytes

#1&"3.1415926535897932384
1.7724538509055160272
1.4645918875615232630
1.3313353638003897127
1.2572741156691850593
1.2102032422537642759
1.1776640300231973966
1.1538350678499894305
1.1356352767378998683
1.1212823532318632987
1.1096740829646979321
1.1000923789635869829"


Try it online!

There is no way to get more precision out of floats in cQuents, so the values must be hardcoded as strings.

# cQuents, 11 bytes

#12&p^(1/\$


Try it online!

Does not reach the required precision levels.

• It doesn't look like the output is to the right precision. – Anush Nov 4 at 21:52
• @Anush fixed, don't have higher-precision floats so have to hardcode it – Stephen Nov 5 at 2:04

# Octave, 23 bytes

vpa(pi,22).^(1./(1:12))


Try it online!

Declares a variable precision arithmetic (VPA) pi. Octave then cleverly infers that the double constant pi actually means pi, not whatever the double constant contains.

• The output isn't quite right. See the output in the question. Maybe you are rounding? – Anush Nov 5 at 18:14
• @Anush yep. Needed two extra digits instead of just one. Edited now. – Sanchises Nov 5 at 18:25
• “cleverly infers that the double constant pi actually means pi”. I wonder if it really does this cleverly or just has π hard-coded as a special case... – ceased to turn counterclockwis Nov 6 at 14:07
• @ceased It infers multiples of pi as well. But yes, probably hardcoded, for example, it does not infer pi+1 – Sanchises Nov 6 at 20:48

# Java 10, 316299268 259 bytes

v->Math.PI+"2384 1.7724538509055160272 1.4645918875615232630 1.3313353638003897127 1.2572741156691850593 1.2102032422537642759 1.1776640300231973966 1.1538350678499894305 1.1356352767378998683 1.1212823532318632987 1.1096740829646979321 1.1000923789635869829"


-40 bytes by just hard-coding the output instead of calculating it.. >.>
-9 bytes thanks to @ceilingcat.

Try it online.

Old 299 291 bytes answer with actual calculations..

v->{var P=new java.math.BigDecimal(Math.PI+"2384");var x=P;for(int i=0;++i<13;System.out.println(x)){var p=P;for(x=P.divide(P.valueOf(i),21,5);x.subtract(p).abs().compareTo(P.ONE.movePointLeft(22))>0;)x=P.valueOf(i-1).multiply(p=x).add(P.divide(x.pow(i-1),21,5)).divide(P.valueOf(i),21,5);}}


Not entirely precise, but good enough to have the first 20 digits correct.

Try it online.

Explanation:

Most bytes come from the fact that BigDecimal doesn't have a builtin for BigDecimal.pow(BigDecimal) nor the $$\n\$$th root, so we'll have to calculate this manually..

v->{                         // Method with empty unused parameter and no return-type
var P=new java.math.BigDecimal(Math.PI+"2384");
//  Create a BigDecimal for PI
var x=P;                   //  Create a BigDecimal to print after every iteration
for(int i=0;++i<13;        //  Loop i in the range [1,12]:
System.out.println(x)){//    After every iteration: print x to STDOUT
var p=P;                 //   Create a BigDecimal to save the previous value
for(x=P.divide(P.valueOf(i),
//   Set x to PI divided by i
21,5);    //   (with precision 21 and rounding mode HALF_DOWN)
//   Continue an inner loop as long as:
x.subtract(p).abs()  //   The absolute difference between x and p
.compareTo(P.ONE.movePointLeft(22))>0;)
//   is larger than 1e-22
x=                     //    Set x to:
P.valueOf(i-1)       //     i-1
.multiply(p=x)      //     Multiplied by x (and store the previous x in p)
P.divide(          //      PI divided by
x.pow(i-1),21,5)) //      x to the power i-1
.divide(P.valueOf(i),21,5);}}
//     Divided by i

• Looks like I should have asked for 15 roots in the end! I was worried about Java from the beginning. – Anush Nov 5 at 15:51
• You can compute the 1/5, 1/7,1/8,1/9,1/11 th roots. All the other ones can be made from these using multiplication and division which I assume BigDecimal supports. – Anush Nov 5 at 19:54

# Python 3, 146 bytes

import math
for i in range(1,13):print(str(math.pi**(1/i))[:~(i==2)]+str([32384,60272,2630,7127,'0593',2759,3966,4305,8683,2987,9321,69829][i-1]))


Try it online!

This uses a similar method to Arnauld's JavaScript solution, by using the inbuilt pi value with the extra precision added to the end.

• -2 bytes by using range(12) over range(1,13): Try it online! – Value Ink Nov 5 at 7:51

# Jelly, 46 bytes

12İ€ØP*×ȷ19Ḟ+“Ṿẏ⁽)¬ọƓỴ³ɲỊUị&ıİḣl’ḃ4ȷ¤_2ȷD;"€”.


Try it online!

Similar to some other answers, but encodes the difference between the Jelly answer and the correct answer (with big integer arithmetic). Full explanation to follow.

• jelly 46 bytes? Is this a software suite? – George Menoutis Nov 6 at 17:48
• @GeorgeMenoutis Jelly is a programming language linked to through the title of my post. It’s designed for CodeGolf so has many one character built-ins. It also uses its own 8-bit code page. – Nick Kennedy Nov 6 at 17:50
• ah Nick, you didn't catch my joke. Jelly answers are usually <10 bytes; so, with 46 bytes, the program developed must be a suite... – George Menoutis Nov 6 at 22:40
• Oh I see! Sorry for missing the joke... 😀 – Nick Kennedy Nov 6 at 22:41

# T-SQL, 75 bytes

declare @ float set @=1while @<=12begin select power(pi(),1/@)set @=@+1 end
`

Not exact, but it works :)

• Could you give the output of the code? I don't know how to test it. – Anush Nov 5 at 19:46
• ---------------------- 3.14159265358979 ---------------------- 1.77245385090552 ---------------------- 1.46459188756152 ---------------------- 1.33133536380039 ---------------------- 1.25727411566919 ---------------------- 1.21020324225376 ---------------------- 1.1776640300232 ---------------------- 1.15383506784999 ---------------------- 1.1356352767379 ---------------------- 1.12128235323186 ---------------------- 1.1096740829647 ---------------------- 1.10009237896359 – JuanCa Nov 5 at 20:46
• That's not what is required unfortunately. Take a look at the outputs in the question. – Anush Nov 5 at 20:48
• Part of the question is that the output has to have exact precision for at least 20 digits. Can you either fix your answer or delete it? – Jo King Nov 7 at 22:13