Pi to the power y, for small y's

19

4

Input

This task takes no input.

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.

Here are the answers:

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

Anush

Posted 2019-11-04T09:55:12.987

Reputation: 3 202

Answers

19

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

Adám

Posted 2019-11-04T09:55:12.987

Reputation: 37 779

1Shouldn't ⎕PP←34 and ⎕FR←1287 be part of the byte-count? – Kevin Cruijssen – 2019-11-04T14:22:07.157

3@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 – 2019-11-04T15:00:42.200

Ah ok, that makes sense. Thanks for clarifying. – Kevin Cruijssen – 2019-11-04T15:03:52.223

19

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()

Arnauld

Posted 2019-11-04T09:55:12.987

Reputation: 111 334

I see what you have done... very nice :) – Anush – 2019-11-04T11:03:14.707

1Apologies.. the last digit of Pi in the example should have been a 4. – Anush – 2019-11-04T11:13:51.187

1@Anush No worries. Updated. – Arnauld – 2019-11-04T11:15:00.880

Nice! I made a similar solution in C. – S.S. Anne – 2019-11-07T15:51:35.217

15

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)

Nahuel Fouilleul

Posted 2019-11-04T09:55:12.987

Reputation: 5 582

Ahh... I am always very happy with a bash answer! Thank you. – Anush – 2019-11-04T15:35:41.460

Could you add some explanation please for the non-bc gurus here. – Anush – 2019-11-04T16:09:12.580

1Untypically, this kolmogorov question doesn't demand some exact output, it only asks for 20 correct digits. So you can do without cut. – Christian Sievers – 2019-11-04T16:27:21.083

1

Or forget bash and just do it all in bc for 28: https://codegolf.stackexchange.com/a/195298/11259

– Digital Trauma – 2019-11-04T19:28:04.837

@DigitalTrauma, :), i didn't know bc was on tio. – Nahuel Fouilleul – 2019-11-04T20:17:47.743

1@DigitalTrauma, thanks for the solution, i didn't notice your first comment – Nahuel Fouilleul – 2019-11-07T08:11:07.877

15

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

gggg

Posted 2019-11-04T09:55:12.987

Reputation: 1 715

1Very glad for a Julia answer. I had no idea you could define BigFloats so compactly! – Anush – 2019-11-04T16:38:09.870

1It seems that you can save 1 byte with big(1) instead of big(1.). – Robin Ryder – 2019-11-04T22:44:25.083

Thanks. I swear I tested that, but clearly left with the wrong answer. – gggg – 2019-11-04T23:23:33.897

2@.π^(1/big(1:12)) Saves another byte – TimD – 2019-11-05T15:00:00.067

My other now-bountied question might be another good place to show Julia’s abilities. – Anush – 2019-11-07T07:40:25.030

1The current solution doesn't work as expected (it outputs π^n rather than π^(1/n)). TimD's suggestion, does however work for 18. – primo – 2019-11-13T04:49:20.503

i fixed it again. – gggg – 2019-11-13T22:10:30.057

9

Wolfram Language (Mathematica), 22 20 19 bytes

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

Pi^(1`11/Range@12)&

Try it online!

Galen Ivanov

Posted 2019-11-04T09:55:12.987

Reputation: 13 815

1This 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 – 2019-11-04T16:04:02.580

@79037662 More precision is ok as long as it matches the given output when correctly truncated. – Anush – 2019-11-04T16:06:11.210

@Anush Thanks for the clarification, that wasn't totally clear to me and I misunderstood. – 79037662 – 2019-11-04T16:08:08.127

1If 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 – 2019-11-04T20:12:09.803

1

Also you can save two bytes by replacing range with [..] like that: N[Pi^(1/[1..12]),25], also PoC here.

– game0ver – 2019-11-04T20:16:41.727

2@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 – 2019-11-05T07:21:12.673

@GalenIvanov yes it's special for wolfram alpha, that's why I provided a link there. – game0ver – 2019-11-05T09:54:01.487

1WolframAlpha 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^(1\11/Range@12)&` – LegionMammal978 – 2019-11-05T13:30:33.103

8

05AB1E (legacy), 47 43 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.

Kevin Cruijssen

Posted 2019-11-04T09:55:12.987

Reputation: 67 575

I really like this answer. It's very clever. – Anush – 2019-11-04T15:06:55.600

143 by using instead of base compression. – Grimmy – 2019-11-06T14:01:23.420

@Grimmy Ah, didn't realize that would be shorter in this case. Should have known since they're all 5 digits.. Thanks! :) – Kevin Cruijssen – 2019-11-06T14:26:45.007

1-3 from a simple inversion of the loop – Grimmy – 2019-11-06T16:54:58.587

@Grimmy Ah, smart. Thanks! – Kevin Cruijssen – 2019-11-06T17:15:11.837

7

Python 3, 61 69 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

Eric Duminil

Posted 2019-11-04T09:55:12.987

Reputation: 701

2sympy is cool :) – Anush – 2019-11-05T09:19:37.263

1This 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 – 2019-11-05T12:49:59.823

@Seb: Unpleasant but excellent comment, thanks. – Eric Duminil – 2019-11-05T13:03:05.323

4

You can save the hassle with Rational by initiating i as E/E: Try it online!

– Jitse – 2019-11-05T13:24:13.363

1@Jitse Brilliant, wish I had thought of it. – Seb – 2019-11-05T14:19:52.873

1Full credits to @flornquake for this trick. – Jitse – 2019-11-05T14:20:45.000

6

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

Jitse

Posted 2019-11-04T09:55:12.987

Reputation: 3 566

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 – 2019-11-04T11:07:33.827

@Anush Pi starts as 3.14159265358979323846, so ~385 should be correct, no? You may want to check your examples. – Jitse – 2019-11-04T11:09:18.440

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 – 2019-11-04T11:12:17.347

2@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 – 2019-11-04T11:14:09.757

I've changed the wording to make it clearer. – Anush – 2019-11-04T11:17:39.417

@EricDuminil sympy is definitely allowed. – Anush – 2019-11-05T07:29:19.730

1@EricDuminil Thanks, but feel free to post it as a separate answer. I like to stick to the standard libraries. – Jitse – 2019-11-05T07:57:23.693

@Jitse: Done

– Eric Duminil – 2019-11-05T09:15:45.120

-1 byte but this relies on undocumented cross-imports: Try it online!

– flornquake – 2019-11-05T12:31:59.013

5

bc -l, 28

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

Try it online!

Digital Trauma

Posted 2019-11-04T09:55:12.987

Reputation: 64 644

5

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!

Value Ink

Posted 2019-11-04T09:55:12.987

Reputation: 10 608

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 – 2019-11-05T07:40:05.400

3

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.

Christian Sievers

Posted 2019-11-04T09:55:12.987

Reputation: 6 366

Thank you. I was hoping you might be interested in my now-bountied question too. – Anush – 2019-11-04T16:08:28.537

3

C (gcc -lm), 171 131 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

S.S. Anne

Posted 2019-11-04T09:55:12.987

Reputation: 1 161

3

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.

John

Posted 2019-11-04T09:55:12.987

Reputation: 171

The output is not correct. Compare it with the output in the question. – Anush – 2019-11-06T19:18:43.253

@Anush I noticed that just now. Strange, it appears r's built-in pi constant is not precise to 20 decimals. – John – 2019-11-06T19:22:14.450

You might need Rmpfr. – Anush – 2019-11-06T19:39:39.380

@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 – 2019-11-06T19:52:26.243

Even the value of pi outputted by your code is wrong. If you use Rmpfr you can start with slightly more precision than you need to get the right result in the end. Look at the other answers to this question. – Anush – 2019-11-06T19:59:00.983

@Anush I am aware. My point is that it doesn't matter if I do Const("pi",3333)^(1/1:12), it's still wrong to 20 digits by the time it gets to Const("pi",3333)^(1/3), and is therefore wrong for the remaining numbers. I can't give you a TIO link as it involves a library, but just take my word for it. – John – 2019-11-06T20:18:40.933

@John part of this challenge is working around the precision issues of your language, since the double-precision floating point numbers used by most languages only goes up to 15 digits of accuracy. See the JavaScript answer for an example of how someone has worked around the accuracy issue even though it doesn't have a higher-precision decimal type.

– Value Ink – 2019-11-06T21:23:40.457

@ValueInk Thanks, I am aware. Clearly I didn't expect R to have that flaw when I submitted. – John – 2019-11-06T21:29:35.543

@Anush Please see my most recent edit for an improved answer using Rmpfr – John – 2019-11-06T21:30:06.933

It really looks like a bug that ought to be reported! – Anush – 2019-11-06T21:30:57.407

2

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) https://rdrr.io/snippets/embed/?code=library(Rmpfr)%0AConst(%22pi%22%2C70)%5E(mpfr(1%2C70)%2F1%3A12) 47 bytes

– Nick Kennedy – 2019-11-06T22:50:49.727

@NickKennedy So, like I said. prec' – John – 2019-11-07T01:21:04.300

3

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!

Digital Trauma

Posted 2019-11-04T09:55:12.987

Reputation: 64 644

Really pleased to see a C answer! – Anush – 2019-11-07T17:43:13.423

Nice one with libquadmath. Now there's two C solutions that technically count as different languages. – S.S. Anne – 2019-11-07T20:40:42.620

Could you link to an HTML version of that doc so it can be viewed on mobile more easily? – S.S. Anne – 2019-11-07T20:42:33.860

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 – 2019-11-07T20:46:13.607

Looks good to me – Anush – 2019-11-07T21:23:24.807

It would be great to see a C/C++ where to my other bountied question too... – Anush – 2019-11-07T21:24:56.927

1

libquadmath 107 bytes; mpfr 123 bytes

– ceilingcat – 2019-11-08T02:45:14.443

@ceilingcat - Thanks! – Digital Trauma – 2019-11-08T15:24:20.733

2

Canvas, 30 bytes

6«{“≥αyHT.─C¹„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.

dzaima

Posted 2019-11-04T09:55:12.987

Reputation: 19 048

2

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.

Stephen

Posted 2019-11-04T09:55:12.987

Reputation: 12 293

It doesn't look like the output is to the right precision. – Anush – 2019-11-04T21:52:47.847

@Anush fixed, don't have higher-precision floats so have to hardcode it – Stephen – 2019-11-05T02:04:28.700

2

Java 10, 316 299 268 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`

Kevin Cruijssen

Posted 2019-11-04T09:55:12.987

Reputation: 67 575

Looks like I should have asked for 15 roots in the end! I was worried about Java from the beginning. – Anush – 2019-11-05T15:51:35.460

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 – 2019-11-05T19:54:24.060

2

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.

Sanchises

Posted 2019-11-04T09:55:12.987

Reputation: 8 530

The output isn't quite right. See the output in the question. Maybe you are rounding? – Anush – 2019-11-05T18:14:04.787

@Anush yep. Needed two extra digits instead of just one. Edited now. – Sanchises – 2019-11-05T18:25:31.457

“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 – 2019-11-06T14:07:11.687

@ceased It infers multiples of pi as well. But yes, probably hardcoded, for example, it does not infer pi+1 – Sanchises – 2019-11-06T20:48:31.880

1

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.

Matthew Jensen

Posted 2019-11-04T09:55:12.987

Reputation: 713

1

-2 bytes by using range(12) over range(1,13): Try it online!

– Value Ink – 2019-11-05T07:51:06.627

1

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.

Nick Kennedy

Posted 2019-11-04T09:55:12.987

Reputation: 11 829

1jelly 46 bytes? Is this a software suite? – George Menoutis – 2019-11-06T17:48:08.813

@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 – 2019-11-06T17:50:30.317

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 – 2019-11-06T22:40:50.733

Oh I see! Sorry for missing the joke... – Nick Kennedy – 2019-11-06T22:41:23.853

1

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.

DeathIncarnate

Posted 2019-11-04T09:55:12.987

Reputation: 916