Short and sweet, but not best practices. I think this is a cute and clever solution for a simple string, but not efficient if the input was 100s or 1000s of characters long. I'd prefer a solution that returned false as soon as a lowercase character was found. In this case this solution is O(n) yet always the worst case, meaning that it always has to reach the last item (ALL characters must be uppercased) before it can determine the boolean value. This is more of a JS like solution than an Elixir solution. Elixir has better "tools" for working with strings.

This is very clever!!!

No, it is not the precision. You need to do the integer division - so, not n / x, but div (n, x).

I'm not entirely sure, but it must be more expensive to concatenate with the longer string on the end. Even the one that passes takes about 6 seconds. The docs mention that there are often performance costs associated with working with strings and that it may be adventageous to work directly with binaries. Let me know if you're able to optomize it (I may take a crack at it later). Maybe a line could be added to the description warning of the high cost of String operations in Elixir.

To generate 1_000_000 numbers

acc <> Integer.to_string(round(:rand.uniform))     # fastest   379.2ms
acc <> Integer.to_string(:rand.uniform(2) - 1)     # fast      533.9ms
"#{acc}#{Integer.to_string(round(:rand.uniform))}" # slow      1797.8ms
Integer.to_string(round(:rand.uniform)) <> acc     # slowest   37525.1ms

I tried with Integer.to_string(:rand.uniform(2) - 1) <> acc, and it timed out. Do you know why the order matters?

Need to pass the test... it was the precision causing the problem.

Like this solution!

Cool. Thanks... I was wondering how cold this be done in a nicer way.

|> (&(&1 -- ids)).()

can be replaced as

|> Kernel.--(ids)

Looks better this way :)