The solution for this example should be 9. The number in question ends with digits ...2573646449.

The solution has a mistake. For example, it yields this error:

'Testing last_digit(10088986397463155518674926935007128287092795598171379587207, 82249490759468694934922134868661852028930188590920879674): 1 should equal 9'

The solution should indeed be 1

This is not optimized for Haskell

I'm having some issues with JavaScript random tests that appear to have BigInt inputs and expect BigInt results because returning a Number yields:
lastDigit(5143600, 0: expected 1 to equal {}

If I convert the results to BigInt when the inputs are BigInt, this error is thrown:
TypeError: Do not know how to serialize a BigInt at JSON.stringify

Seems to be related to this issue with JSON.stringify and BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/BigInt_not_serializable, so maybe a test issue rather than a problem with my solution?

Please look at the last example in description, and try to apply some common sense. Does it look like you can calculate such result, possibly 100 of times, in under 12 seconds? Very unlikely. You need a different approach altogether. (Ask yourself, why would this be 5kyu if your code worked?)

It's too simple.

why i get Execution Timed Out
for this code in python:
return (n1**n2)%10

i think there is no Simpler code than i wrote?

Issue is with your skill, not the kata.

The algorithm you've written is way too inefficient for a problem like this. The tests are deliberately written to fail solutions like these. Once you optimize your solution, it should pass in ~2 seconds. You're probably testing with small values on Visual Studio - the tests on Codewars will try massive numbers.

C#, Execution Timed Out but all works good in Visual Studio with same numbers..
c# tests in not optimised..

Ok Thanks

This is literally what this challenge asks you to figure out :)

You can try to write some small values on paper and see if some patterns emerge.

If my understanding is correct, when the 2nd parameter ("b", in your case) is 2 or 3, the expected value of n3 should be equal to n2, but n3 is actually set to 0 by your code.

I've had a quick look, but can't say why yet. I did notice the code fails perhaps consistently when a is a larger number and b is either 2 or 3. Hope that helps.