# 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


# 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? Nov 4, 2019 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.
Nov 4, 2019 at 15:00
• Ah ok, that makes sense. Thanks for clarifying. Nov 4, 2019 at 15:03

# 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 :)
– user9207
Nov 4, 2019 at 11:03
• Apologies.. the last digit of Pi in the example should have been a 4.
– user9207
Nov 4, 2019 at 11:13
• @Anush No worries. Updated. Nov 4, 2019 at 11:15
• Nice! I made a similar solution in C. Nov 7, 2019 at 15:51

# 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.
– user9207
Nov 4, 2019 at 15:35
• Could you add some explanation please for the non-bc gurus here.
– user9207
Nov 4, 2019 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. Nov 4, 2019 at 16:27
• Or forget bash and just do it all in bc for 28: codegolf.stackexchange.com/a/195298/11259 Nov 4, 2019 at 19:28
• @DigitalTrauma, thanks for the solution, i didn't notice your first comment Nov 7, 2019 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!
– user9207
Nov 4, 2019 at 16:38
• It seems that you can save 1 byte with big(1) instead of big(1.). Nov 4, 2019 at 22:44
• Thanks. I swear I tested that, but clearly left with the wrong answer.
– gggg
Nov 4, 2019 at 23:23
• @.π^(1/big(1:12)) Saves another byte
– TimD
Nov 5, 2019 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. Nov 13, 2019 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. Nov 4, 2019 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. Nov 4, 2019 at 20:12
• Also you can save two bytes by replacing range with [..] like that: N[Pi^(1/[1..12]),25], also PoC here. Nov 4, 2019 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) Nov 5, 2019 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)& Nov 5, 2019 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.
– user9207
Nov 4, 2019 at 15:06
• 43 by using 5ô instead of base compression. Nov 6, 2019 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! :) Nov 6, 2019 at 14:26
• -3 from a simple inversion of the loop Nov 6, 2019 at 16:54
• @Grimmy Ah, smart. Thanks! Nov 6, 2019 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 :)
– user9207
Nov 5, 2019 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, 2019 at 12:49
• You can save the hassle with Rational by initiating i as E/E: Try it online! Nov 5, 2019 at 13:24
• @Jitse Brilliant, wish I had thought of it.
– Seb
Nov 5, 2019 at 14:19
• Full credits to @flornquake for this trick. Nov 5, 2019 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.
– user9207
Nov 4, 2019 at 11:07
• @Anush Pi starts as 3.14159265358979323846, so ~385 should be correct, no? You may want to check your examples. Nov 4, 2019 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.
– user9207
Nov 4, 2019 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. Nov 4, 2019 at 11:14
• @EricDuminil Thanks, but feel free to post it as a separate answer. I like to stick to the standard libraries. Nov 5, 2019 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.
– user9207
Nov 5, 2019 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.
– user9207
Nov 4, 2019 at 16:08

# 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.

#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. – user9207 Nov 4, 2019 at 21:52 • @Anush fixed, don't have higher-precision floats so have to hardcode it Nov 5, 2019 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? – user9207 Nov 5, 2019 at 18:14 • @Anush yep. Needed two extra digits instead of just one. Edited now. Nov 5, 2019 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... Nov 6, 2019 at 14:07 • @ceased It infers multiples of pi as well. But yes, probably hardcoded, for example, it does not infer pi+1 Nov 6, 2019 at 20:48 # 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. – user9207 Nov 6, 2019 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, 2019 at 19:22 • You might need Rmpfr. – user9207 Nov 6, 2019 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, 2019 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 Nov 6, 2019 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> s[9];main(i){for(;i<13;puts(s))quadmath_snprintf(s,36,"%.99Qf",expq(logq(M_PIq)/i++));}  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! – user9207 Nov 7, 2019 at 17:43 • Nice one with libquadmath. Now there's two C solutions that technically count as different languages. Nov 7, 2019 at 20:40 • Could you link to an HTML version of that doc so it can be viewed on mobile more easily? Nov 7, 2019 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.) – user9207 Nov 7, 2019 at 20:46 • Looks good to me – user9207 Nov 7, 2019 at 21:23 # 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. # 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! Nov 5, 2019 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? Nov 6, 2019 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. Nov 6, 2019 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... Nov 6, 2019 at 22:40 • Oh I see! Sorry for missing the joke... 😀 Nov 6, 2019 at 22:41 # 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) .add( // And add: 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. – user9207 Nov 5, 2019 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. – user9207 Nov 5, 2019 at 19:54 # Perl 5, 72 bytes $n=1;print substr(Math::BigFloat->bpi()**(1/$n++),0,21).$/ while(\$n<13);


Even using $$\\pi\$$ from BigFloat, it doesn't seem to exactly match the given outputs. I'm sure it's truncated properly, though.

Try it online!

• A Perl bug maybe?
– user9207
Aug 12, 2020 at 6:18

# Fortran (GFortran), 48 bytes

print*,(acos(-1._16)**(1/real(i,16)),i=1,12)
end
`

Try it online!

Just an implicit loop with quad-precision vars. Not transferable, but works with GCC.