Nice kata, thanks.

Thank you all for the thoughtful feedback!

Regarding the batch input format, you're absolutely right to question whether this provides meaningful differentiation. The idea here is to simulate realistic scenarios where multiple modular exponentiations are needed at once (such as in cryptographic systems or batch computations). While the function could technically map over a single-triplet version, the goal is to encourage writing a solution that directly handles structured batch input, which is not the focus in the kata Mauro referenced (https://www.codewars.com/kata/52fe629e48970ad2bd0007e6).

To address this more clearly:

I’ll revise the example solution to highlight why handling the list directly matters.

I’ll also make the performance test case more explicit to show where a naive ** or Math.pow solution might fail under extreme inputs.

In short: yes, the performance cost of mapping may not always expire, but the design constraint is intentional, to push users to think in terms of scalable solutions.

Again, thank you! These comments really help polish the kata and its clarity for future users.

I also fail so see the difference from single-case handling in the example solution. If the batch processing is a design choice, the example solution should showcase that difference.

Duplicate of (at least) https://www.codewars.com/kata/52fe629e48970ad2bd0007e6

Let's approve this one. Now you can focus on the harder kata.

Great kata of the graph series, well done.

I too suggest using approximate comparisons. The description should openly state that while using decimal.Decimal is a best practice in financial calculations to minimize error, it cannot always eliminate it.

In my opinion, this kata is an example of financial planning, where the modeling assumptions -- e.g., the assumption of a time-invariant interest rate and a lack of intermediate rounding, as in this kata -- result in a level of inaccuracy that easily dwarfs any issues of round-off errors. However, it's these very modeling assumptions that allow for mathematically elegant solutions that teach us something about the underlying economics. It's only in accounting-like applications where I would insist on absolute lack of round-off error.

For this reason, I would be willing to see a translation in Javascript using ordinary floating-point arithmetic. This would yield more round-off error, but again, it's a minor inaccuracy compared to the underlying, well-intentioned modeling assumptions.

Only one solution possible in Python, currently the kata does not provide any alternative to learn about.
The upper bound is too strict, especially for a 6kyu kata.

Approved, thanks for another translation.

Java Translation

Approved, thanks for translating.

Lua translation

great kata:)

72 bytes