• expected and actual are swapped in random test case assertions.
• The solution function should have been static
• Reference solution can give wrong results on integer overflow (i.e. when dragons > Integer.MAX_VALUE / 2)
• Please always show inputs for 8kyu kata.
• As hobovsky said please use JUnit 5

Fixed everything btw.

Approved

Then this kata should be reranked...

There is a differnce between a coding performance constraint and a basic mathematical transformation. I won't say very basic, but really quite basic.

I voted 7, and I think coding performance constraints start at 5, not 6 ( 6 is for algorithmic complexity ).

but 7 is not appropriate with perf constraint...

Majority of votes were split between 6 and 7 kyu, which seems appropriate for this task.

The kata requires better than O(n) ( O(sqrt n), O(log n), O(1) ). You can't count up to 1e9 in time, let alone up to 1e18.

It's not up to the kata author to decide on the rank! Beta solvers vote on that. ( And they knew the performance it required when they voted. )

"n" means you are in trouble because you cannot solve it normally (like two "for" cycles and here we go) and you need to create something different.

What is your solution's OBig?

LC translation

this translation modifies the description ( again .. :/ ) ( it includes below dashes though )

it may need forking for merge conflict, because the description was changed during creation

it may be harder than in other languages, because division is expensive ( fortunately, divisors can be small )

Valid suggestion, changed to dash (—)

It seems the author of the question has solved this kata with fixing their mistake, so closing this question~

Basically the "n" at the end of the number allows to convert it to the BigInt type — more information about it you can read here

The - in the description (e.g. Z(N) - sum of all S(i)) is unfortunate as separator since it looks like, well, minus.