Fixed. Added note in description to say that they can be equal.

.

Now the tests handle wrong return types. Fixed the situation where if a test failed it threw an error. Now tests only throw if the user solution itself throws it. Also fixed the detection code for oscillators

I'll fix this. And another thing - I just realized my code for oscillator detection doesnt quite work, Imma change that too

Ah, you beat me to it :D This whole thing looks AI generated to me.

retired

done!

retired

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.

retired

Noted! May you please provide any feedback on how to improve.

That would make sense if the additional performance were actually required, and mapping individual modpows over the list would timeout. Is it, and does it?

You're absolutely right. This kata expects the user not to use pow() or **.
I'll make this restriction more explicit in the kata description, and update the tests if needed to catch such usage.

Thanks for your suggestion! However, this kata is intentionally designed to take a list of triplets instead of a single triplet.
It focuses on batch-processing modular exponentiations efficiently, which is slightly different from single-case handling.