Reading back this fork, I realise that the pretty-printing leaks the expected number of elements. I don't know whether that's a good idea.

Yeah I'll have some trouble remembering what I was thinking three years ago, so I don't remember why I did it that way.

There are indeed two possibilities:

• Use a fixed length integer type and limit the input values
• Use a bignum type

I went with the first one for some reason; someone could change the translation to the second if it seems like a good idea.

Woops the formatting is botched, my bad

I only saw your reply when I posted mine and the page refreshed. At least you got a second confirmation.

Is 44 your answer or the expected answer ? Because 39 seems correct to me.

• First do step 1, 2 and 4 (takes 13 minutes)
• Then do step 6 in the background (will last for 21 more minutes)
• Do steps 3 and 5 while the carrots boil (doesn't take time as step 6 is longer)
• Finish with steps 7 and 8 (takes 5 minutes)

13 + 21 + 5 = 39

In assert_eq!(...), when the two values compare unequal, the macro needs to print them and does so with the Debug trait.

You can take a look at the signature of assert_failed in core::panicking.

The point of this kata is not to write a function boolean isDiv5(String s), but to create a regular expression that will match all strings that represent in binary a number divisible by five and only these strings.

For example, this regular expression should match "101", "0" and "1111" because they represent 5, 0 and 15.
But it should not match "111", "10000" nor "1" as they represent 7, 16 and 1.

You mad genius

You are doing WAY too much work generating all the permutations. Let's take the example in the description :

The whole list of permutations of "abc" is ["abc", "acb", "bac", "bca", "cab", "cba"], and the answer is "bac".

Do you really need to know that "abc" comes before "acb" to determine the middle permutation ? No you don't.
Do you even need to generate them ? Once again, no you don't. After all, 'a' is the very first letter in order, so there's not much chance for it to be the middle permutation's first letter.

It's really quite simple, actually : look at the fork.

Edit : similar solution (except that I used 128 instead of 1000)

Without leading zeros. k is 2 for d=3.

You may find the range patterns useful ;-)

By rethinking how to approach this problem.

Do you actually need to count from 1 to a million to know that there are indeed a million integers from one to a million? You could, sure, but I really hope you didn't answer yes.

Now think about the intervals [0, 10] and [5, 15]: they can be reduced to [0, 15], but why ?