Agreed. The recursion has to be killing their time. My code is about 35% faster than theirs. I don't understand bitwise operators yet. My code and yours run neck and neck.

It seems like you should be able to shave some time off of yours by changing your for loop to somehow account for the actual bit size of 'n' instead of using 32 bits regardless of 'n'. A little above my grasp thus far in my coding journey.

neat, but not a best practice at all, which thankfully the votes have reflected haha

Why?

bad practice

very neat

its not nesesarelly as mission of any function is provide back a result of task it was created to do.

This is one of the most elegant solutions, though might not be the most performat one. Consider tail call optimization for this.

Frankly speaking, I doubt that your code is called with wrong arguments. trace is unreliable here, because of shrinking: after finding [27,15,15] QuickCheck tries to find a smaller counter-example, invoking tests with [27,15,14] and, I suppose, some other combinations. That is why you see [27,15,14] in trace output.

test lastDigit [x, y, z]
✘ Falsifiable (after 69 tests and 5 shrinks): 
expected: 3
 but got: 7
NonNegative {getNonNegative = 27}
NonNegative {getNonNegative = 15}
NonNegative {getNonNegative = 15}

Looking at this actually seems to reveal the issue, as logging the input arguments (with trace + show) shows that my code is called with [27, 15, 14] (which ends in 7) instead of [27, 15, 15] (which ends in 3).

Could you please show full test log? I cannot reproduce the issue. Definitely, lastDigit [7,11,2] should be 7.

The following Haskell test case fails for me: lastDigit [7,11,2], expected 3 but got 7. However, checking 7^(11^2) in Wolfram Alpha shows that the last digit is, indeed, 7.