Skip to main content
Code Golf

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

7
  • 2
    \$\begingroup\$ Brilliant and 25 bytes less than my own best attempt without peeking... The log trick is super! \$\endgroup\$ Commented Aug 26, 2020 at 8:05
  • 1
    \$\begingroup\$ Although a nice approach, I'm afraid it fails for test case 4913 due to floating point inaccuracies (2.9999999999999996 is not an integer). I've just looked in the meta, and apparently you have to work around this if your language supports an accurate decimal type. I don't know R, so I don't know if this applies to it, but I was about to port your approach to Java to golf my about to post answer, but that apparently wouldn't be allowed unless I use java.math.BigDecimal instead of regular doubles.. :/ \$\endgroup\$ Commented Aug 26, 2020 at 8:48
  • \$\begingroup\$ @KevinCruijssen I assumed this was OK, as it would work with a theoretical infinite-precision computer. I am probably not aware of the meta consensus you referred to, could you link to it? \$\endgroup\$ Commented Aug 26, 2020 at 9:06
  • \$\begingroup\$ @RobinRyder Ah, I thought I added a link. Here it is. \$\endgroup\$ Commented Aug 26, 2020 at 9:09
  • 1
    \$\begingroup\$ @DominicvanEssen While you were commenting, I made a similar change: I don't need …^(3*n) but simply …^n, which gains 4 bytes (but fails for any moderately large input). \$\endgroup\$ Commented Aug 26, 2020 at 9:58