Nice problem, thanks!

Minor suggestions:

It would be would be helpful to have an example, either in the description or the sample tests, where upgrading as soon as possible is not part of the solution.

Display the parameter values for each random test. It helps with debugging, and saves the user having to print them out.

Include what "cpc" stands for.

Explain what n refers to in "The reference solution executes with O(log n) taking less than 1s."

It's not clear why "numpy" is included in the tags. Maybe either explain why or remove it.

Great. Ty again for the help!

Seems fixed

Right, I did that and republished just now. Now outputs are no longer "truncated". I'll come back in a short while to make sure outputs are still correct and mark as solved if that's the case.

I noticed our solutions produce different outputs, so I'll check wether that's a mistake in mine or yours and send an update when done.

Thanks again.

I don't think it is resolved, I am now getting many results like this:

4394760810501401835469614985864712016711067361490760 should equal 4394760810501401835469614985000000000000000000000000

You probably need to set Decimal.getcontext().prec to be much higher.

Excuse me, I overlooked it. I unflagged my response since it doesn't really represent a relevant spoiler to the solution, at least in my opinion.

I cannot see your comment since I cannot solve the kata. You could come to the Discord (see link on the left menu) and we can discuss there. Otherwise if you want a reference you can click "view solution" under my comment to see what I think should be a correct solution.

You're right: employing decimal.Decimal instead of float fixed the precision issue and confirmed your output (at least for the test case you presented).

Reference solution has been updated and tests have been slightly adjusted to take into account the small execution time increment caused by the improved precision.

Thank you very much for pointing that out! Please confirm that the problem is now fixed so i can mark the issue as solved.

I suspect you might have precision issues in your reference solution. For example with inputs: up=2, goal=2020450000000000000000, I calculate that we should be upgrading 126063 times, which should result in total clicks of 10684790872762699, but your tests expect 1 less at 10684790872762698.

As the inputs get larger, the discrepency grows too.

Done: cut down tests to a third of the former amount, resulting in an execution time of 3.5s (see updated "Performance" paragraph in the description).

The tests' upper bound for the goal parameter has also been reduced, since it didn't really provide harder test cases - only bloated the tests amount.

Thank you for your input!

Hi,

The reference solution executes with constant time complexity O(1) taking at most 9s.

If you actually have a O(1) solution, there is no need to make the user wait the result for 9s. Just use big enough inputs, a 2s computation time should be WAY more than enough to prune out any undesired implementation. But make sure the inputs are big enough (better to have less tests with bigger inputs than the opposite)

Fixed.

Short and sweet!

I can't tell if my code is somehow finding the gas prices wrong for some cases, but I am getting an error with some of the random cases and it seems like there are at least sometimes random tests where there is a tie so two sets of alterations have the same cost and same length.

fork was approved