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.

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

Still too much code repetition, imo ;)

Thank you! I randomized the tests.

@author: are you happy with the current constraints of n and k for this kata?

show us the number

We (Me and mednoob) discussed about the "harder" version and oh boy, it was crazy. 10 minutes for a single number. The problem turned from being too easy to might be impossible to fit in the time range.

1e-6 now instead of 1e-9, is it ok?

Fixed.

Your solution passes all non performance tests now on submit.

You are right, the ref sol was 1 off in some edge case. In this example, it mistakenly thought it would make the view. Fixed

done

I found the bug in reference solution. I retested with each of the current submissions. Thanks for pointing this out.