Have you actually tried testing that claim? I've tested 5 solutions (mine, the linq solution commented on, yours and two others from this comment thread). Only one commenter I tested in this thread (zokeer) has a solution that actually runs faster than the Linq solutions (though at least all the solutions run in linear time against varying string lengths and varying unique character amounts). Both yours and Zub_Son's are slower than the Linq solutions despite commenting on the alleged slowness of it.

Not only are the Linq solutions easier to write and read, this shows that most people trying to make faster/more optimized solutions end up slower than the naive Linq one. Add in that such optimizations aren't really necessary unless the method is an a hot path and I'll prefer a competently written short Linq solution 90% of the time.

I did the solution with over 40 lines of code and time complexity was still O(N log (n) ), so looking at this solution is embarrasing

tbh yeah TC is O(nLog(n)) and SC is O(n) when it can be done with nested loops with TC of O(n^2) and SC of O(1) but seems like less code

raise it to a positive(?) exponent

I think it is a bit more complex than that.

Things are even better! By e^iπ = -1, you can have a positive number, raise it to a positive(?) exponent, and get a negative result! How cool is that!

Well, kinda. All it takes is some... imagination.

Check this: https://en.wikipedia.org/wiki/Complex_number

Try to run your solution locally in your IDE for n=60 and see how it works fails with your debugger.